Pattern 34 (Static Partial Join for Multiple Instances)
Within a given process instance, multiple concurrent instances of a task (say m) can be created. The required number of instances is known when the first task instance commences. Once n of the task instances have completed (where n is less than m), the next task in the process is triggered. Subsequent completions of the remaining m-n instances are inconsequential, however all instances must have completed in order for the join construct to reset and be subsequently re-enabled.
Examine 10 samples from the production line for defects. Continue with the next task when 7 of these examinations have been completed.
The Static Partial Join for Multiple Instances pattern is an extension to the Multiple Instances with a priori Runtime Knowledge pattern which allows the process instance to continue once a given number of the task instances have completed rather than requiring all of them to finish before the subsequent task can be triggered.
The general format of the Static Partial Join for Multiple Instances pattern is illustrated in Figure 52. Transition A corresponds to the multiple instance task. In terms of the operation of this pattern, once the input place i1 is triggered for a case, m instances of the multi-instance task A are initiated concurrently and an "active" status is recorded for the pattern. These instances proceed independently and once n of them have completed, the join can be triggered and a token placed in output place o1 signalling that the thread of control can be passed to subsequent tasks in the process model. Simultaneously with the join firing, the token is removed from the active place allowing the remaining n - m tasks to complete. Once all m instances of task A have finished, the status of the pattern changes to "ready" allowing it to be re-enabled.
Figure 52: Static partial join implementation for multiple instances
There are two variants to this pattern which relax some of the restrictions associated with the form of the pattern described above. First, the Cancelling Partial Join for Multiple Instances pattern removes the need to wait for all of the task instances to complete by cancelling any remaining task instances as soon as the join fires. It is illustrated in Figure 53.
The second, the Dynamic Partial Join for Multiple Instances pattern allows the value of m (i.e. the number of instances) to be determined during the execution of the task instances. In particular, it allows additional task instances to be created "on the fly". This pattern is illustrated in Figure 54.
There are two context conditions associated with this pattern: (1) the number of concurrent task instances (denoted by variable m in Figure 52) is known prior to task commencement and (2) the number of tasks that need to be completed before subsequent tasks in the process model can be triggered (denoted by variable n in Figure 52) is also known prior to task commencement.
BPMN and XPDL both appear to offers support for this pattern via the Multiple Instance Loop Activity construct where the MI Flow_Condition attribute is set to complex and ComplexMI_FlowCondition is an expression that evaluates to true when exactly n instances have completed causing a single token to be passed on to the following task. However no detail is provided to explain how the ComplexMI_FlowCondition is specified hence this is considered to constitute partial support for the pattern.
An offering achieves full support if it provides a construct that satisfies the description and context criteria for the pattern. It achieves partial support if there is any ambiguity associated with the specification of the join condition.
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||-||Not supported. The dynamic subprocedure is specified using an array. It is only stopped after a failure or a withdraw of the complete subprocedure. There is no way to pass on control either.|
|Websphere MQ||3.4||-||Not supported. There is no direct support for multiple instance activities.|
|FLOWer||3.51||-||Not supported. Dynamic subplans can have an auto complete condition however this is only evaluated when all subplans have completed.|
|-||Multiple instance activities are not supported.|
|iPlanet||3.0||-||No support for multiple instance activities.|
|SAP Workflow||4.6c||-||Not supported. Via "dynamic processing with a multi-line container element" it is possible to create an instance for each row in a table. However, these instances are supposed to complete and there is no setting for a threshold value.|
|BPEL||1.1||-||No support for multiple activity instances.|
|Websphere Integration Developer||6.0||-||No support for multiple activity instances.|
|Oracle BPEL||10.1.2||-||No means of.|
|BPMN||1.0||+/-||Notionally supported via multiple instance task with MI Flow_Condition attribute set to complex where ComplexMI _FlowCondition is an expression that evaluates to true when exactly M instances have completed and passes on a single token to the following activity. However, it is unclear exactly how the ComplexMI_FlowCondition should be specified.|
|XPDL||2.0||+/-||Notionally supported via the multi-instance construct where MI Flow_Condition attribute is set to complex and ComplexMI_FlowCondition is an expression that evaluates to true when exactly M instances have completed and passes on a single token to the following activity. However it is unclear how the ComplexMI_FlowCondition is actually specified.|
|UML ADs||2.0||-||Not supported. A MI activity can only complete when all N instances specified in the ExpansionRegion have completed.|
|EPC (implemented by ARIS toolset 6.2)||-||Not supported.|
|jBPM||3.1.4||-||jBPM does not support this pattern.|
|OpenWFE||1.7.3||+||OpenWFE supports this pattern through the attribute count of the <concurrent-iterator>. Count defines the number of instances of the multiple instances task that need to complete before the synchronization is done and the flow can continue. The attribute remaining is set to "forget" so that threads remaining after the completion of the multiple instance task are not cancelled.|
|Enhydra Shark||2||-||Enhydra Shark does not support this pattern.|