A process that is started by another process is known as a subprocess. The way in which the life cycle of subprocesses can be managed and the versioning behavior of subprocesses depend on how these processes are modeled.
For modularity and reuse, it often makes sense to apply the programming concept of encapsulation to business process modeling, that is to implement one or more steps of the business logic as a separate process and to invoke this process from the main process. A subprocess can also start another process. This can lead to an arbitrarily deep hierarchy of process instances. When these processes are deployed, all of the process templates in the process-to-process relationship must be deployed to the same Business Process Choreographer database.
A subprocess can have a peer-to-peer relationship or a parent-child relationship with the calling process. This relationship determines the behavior of a subprocess when an action that manages the process life cycle is invoked for the calling process. The life cycle actions comprise suspend, resume, terminate, delete, and compensation. Actions that manage the process life cycle can be taken only on top-level process instances.
However, for long-running processes with a creating operation that implements a one-way interface, the value of the autonomy attribute is automatically set to peer during runtime. If the autonomy attribute is set to child, this value is ignored at runtime.
A microflow always runs as a child process. However, if there is another component between the two processes, it might prevent a parent-child relationship from being established, for example, an interface map component that is wired between the two process components.
An example of early-binding is an SCA wire. For example, if you wire a stand-alone reference to a process component, every invocation of the process using this reference is targeted to the specific version that is represented by the process component.
To apply late-binding when a subprocess is invoked, the parent process must specify the name of the subprocess template from which the valid subprocess is to be chosen at the reference partner. The valid-from attribute of the process is used to determine the subprocess template that is currently valid. Any SCA wiring is ignored.
An example of late-binding is when a new process is invoked in Business Process Choreographer Explorer. The instance that is created is always based on the most recent version of the process template with a valid-from date that is not in the future.
Last updated: Thu Apr 27 14:23:49 2006
(c) Copyright IBM Corporation 2006.
This information center is powered by Eclipse technology (http://www.eclipse.org)