pub.prt.SubprocessModel

Important: This document type is used with the deprecated ability to dynamically invoke a referenced processes from a call activity step. If you are working with dynamically invoked callable processes, see pub.prt.SubprocessModel for more information.

WaitForSubprocess	String Flag indicating whether to wait for the child process (as done with statically invoked referenced processes) or to launch it asynchronously and not expect any return documents. Applies to all process instances started from the document type. true — Default. Wait for the child process. false — Start the child process asynchronously and do not expect any return documents.
SubprocessModelID	String The identifier of the referenced process model in the format: Project/Process.
ReturnDocuments	String List A list of document types that the parent process expects back from each child process. No value is needed here if a value of false is used for WaitForSubprocess.
SubprocessInstances	Document list A list of instances that are to be started for the specified referenced process model. For example, if you have 10 line items to process, there will be 10 documents in this list.

	Key	Description
	Inputs	Document list A list of document types that are needed to invoke the specified referenced process model. For example, if your model requires a LineItem document and a Customer document, you will need two entries in this list for that instance.

		Key	Description
		Type	String The fully qualified type of the document (for example, "MyPackage.docs:MyDocumentType").
		Document	Document An input document for the given subprocess instance, as defined by the Type key.

To enable successful execution of the dynamically invoked referenced process, you must ensure that these values are in the process pipeline prior to any activity (for example, input data mapping) that applies to the referenced step.

Suppose you have specified ReturnDocuments and a WaitForSubprocess value of true. In this case, the Process Engine waits for all instances of the child process to complete and populates the pipeline with data from each child process instance, obtained from the returned document(s). This data is now available for use.

In another example, suppose that three instances of a LineItem child process are started, and each of these instances is expected to return a LineItemPrice document. In this case, a document list named LineItemPrice is added to the pipeline and the data in it is available for use; the order of the documents in the list is the same as the order of invocation. This enables easy location of the data in the pipeline by using the return document name.