About webMethods Referenced Processes
A webMethods referenced process is any process model that can be started with a message start event, typically configured with subscription filters. When a process model contains both a message start event and a none start event and contains a global process specification, it can serve as both a referenced process and a callable process.
Important:
Although still available, the ability to invoke a referenced process from a call activity step is deprecated. You are advised to implement all of your steps that invoke another process with a call activity step that invokes a callable process.
When you invoke a referenced process with a call activity step, you are able to use other BPMN constructs such as boundary timer and error events with your referenced process. When a referenced process is invoked by a call activity, it executes in the same way as a standard webMethods process.
To call a referenced process with a call activity step, you must configure referenced process behavior for the call activity step. In addition:
The process must contain a message start event.
Upon execution of the call activity step, the parent process will wait for the child process to complete before moving to the next step in the process.
You can configure a webMethods referenced process step to use static or dynamic invocation:
Static invocation. In this implementation, the referenced process step starts an instance of a specific reference process model with a set of process properties that are defined at design time. The same process model is
always called when the call activity step is invoked, and the parent process will always wait for this child process to complete, regardless of the expectation of return data. See
About Statically-Invoked Processes. You can start multiple serial instances of the referenced process by configuring the referenced process step for looping.
Dynamic invocation. In this implementation, you can start one or more referenced processes at run time, and, if desired, multiple instances of each of those processes. Furthermore, you define which process models are to be started dynamically at run time, depending on pipeline data. You implement this by creating a document reference list of type
pub.prt:SubprocessModel, called
SubprocessModels in the pipeline. The data in this document reference list is used to invoke the desired reference process(es). For example, for orders originating in different countries, a document could start process A for one country, and process B for another country. See
About Dynamically-Invoked Processes.
Related Topics