Pattern 13 (Multiple Instances with a priori Design-Time Knowledge)
Within a given process instance, multiple instances of a task can be created. The required number of instances is known at design time. These instances are independent of each other and run concurrently. It is necessary to synchronize the task instances at completion before any subsequent tasks can be triggered.
The Annual Report must be signed by all six of the Directors before it can be issued.
This pattern provides the basis for concurrent execution of a nominated task a predefined number of times. It also ensures that that all task instances are complete before subsequent tasks are initiatied.
Similar to WCP12, the Multiple instances without Synchronization pattern, there are both sequential and simultaneous variants of this pattern illustrated in Figures 16 and 17 respectively. In both figures, task C is the one that executes multiple times.
Figure 16: Multiple instances with a priori design-time knowledge (variant 1)
Figure 17: Multiple instances with a priori design-time knowledge (variant 2)
There is one context condition associated with this pattern: the number of task instances (i.e. numinst) is known at design time and is a fixed value.
In order to implement this pattern, an offering must provide a specific construct in the process model that is able to denote the actual number of concurrent task instances that are required. Staffware, FLOWer, SAP Workflow and UML 2.0 ADs support the simultaneous variant of the pattern through the use of dynamic subprocedure, dynamic subplan, multi-line container element and ExpansionRegion constructs respectively. BPMN and XPDL support both options via the multi-instance loop task construct with the MI_Ordering attribute supporting both sequential and parallel values depending on whether the tasks should be started one-by-one or all together. Unlike other BPEL offerings which do not support this pattern, Oracle BPEL provides a <flowN> construct that enables the creation of multiple concurrent instances of a task.
Many offerings provide a work-around for this pattern by embedding some form of task invocation within a loop. These implementation approaches have two significant problems associated with them: (1) the task invocations occur at discrete time intervals and it is possible for the individual task instances to have distinct states (i.e. there is no requirement that they execute concurrently) and (2) there is no consideration of the means by which the distinct task instances will be synchronized. These issues, together with the necessity for the designer to effectively craft the pattern themselves (rather than having it provided by the offering) rule out this form of implementation from being considered as satisfying the requirements for full support.
One possibility that exists where this functionality is not provided by an offering but an analogous form of operation is required is to simply replicate the task in the process-model. Alternatively a solution based on iteration can be utilized.
Full support for this pattern is demonstrated by any offering which provides a construct which satisfies the description when used in a context satisfying the context assumption. Although work-arounds are possible which achieve the same behaviour through the use of various constructs within an offering such as task replication or loops, they have a number of shortcomings and are not considered to constitute support for the pattern.
To achieve a + rating (direct support) or a +/- rating (partial support) the product should satisfy the corresponding evaluation criterion of the pattern. Otherwise a - rating (no support) is assigned.
|Staffware||10||+||Supported using the dynamic subprocedure step.|
|Websphere MQ||3.4||-||Not supported. No construct for of designating multiple instances of an activity in the design-time model.|
|FLOWer||3.51||+||Directly supported through dynamic subplans. For a dynamic plan, the minimum and maximum number of instances can be selected and the actual number of instances may be based on some expression. This expression can be a constant, thus realizing the pattern. Multiple instance data can be passed and accessed through a so-called dynamic array.|
|COSA||5.1||-||There is no means of denoting that an activity should be executed multiple times.|
|iPlanet||3.0||-||Not supported. No means of designating that multiple instances of an activity are required.|
|SAP Workflow||4.6c||+||This pattern is supported in two ways: (1) indirectly via the use of loop construct together with a counter variable indicating how many instances are to be synchronized by the subsequent join and (2) via "dynamic processing with a multi-line container element". Based on a multi-line data element (i.e., a table), an activity or sub-process is executed as many times are there are lines in the multi-line data element (i.e. the number of rows). There is a maximum of 99 instances. Through this "dynamic processing with a multi-line container element" dynamic support is achieved.|
|BPEL||1.1||-||Not supported. No direct means of denoting multiple activity instances are required.|
|Websphere Integration Developer||6.0||-||Not supported. No direct means of denoting multiple instances are required.|
|Oracle BPEL||10.1.2||+||Supported through the use of the <flowN> construct which allows multiple concurrent instances of an activity to be created.|
|BPMN||1.0||+||Supported via multiple instance task with MI Flow_Condition attribute set to all.|
|XPDL||2.0||+||Supported by the multi-instance loop construct.|
|UML ADs||2.0||+||Supported through the use of the ExpansionRegion construct.|
|EPC (implemented by ARIS toolset 6.2)||-||Not supported. The only way to realize this is by making copies and putting them in parallel.|
|jBPM||3.1.4||-||jBPM does not support this pattern. There is a proposed implementation in Java of a node-type Node to capture this semantics. As the solution relies on java-coding we consider it outside the capabilities of the proposed jPDL language|
|OpenWFE||1.7.3||+||OpenWFE implements this pattern through the <concurrent-iterator> construct. In the on-value attribute of the <concurrent-iterator> a list of constants is defined during design time. Each of the items in this list will result in the creation of a corresponding instance. The created instances will run in parallel and synchronized after completion.|
|Enhydra Shark||2||-||Enhydra Shark does not support this pattern. Multiple instances of a task can be spawned through a loop which invokes a sub-flow in every iteration of it. However these sub-flows can not be synchronized, as the sub-flow execution setting has to be set to "asynchronous", so that the start up of the instances shall not be blocked. A work around is to replicate the numberr of instances to be created in parallel flows.|