Pattern 8 (Multi-Merge)
The convergence of two or more branches into a single subsequent branch such that each enablement of an incoming branch results in the thread of control being passed to the subsequent branch.
The lay_foundations, order_materials and book_labourer tasks occur in parallel as separate process branches. After each of them completes the quality_review task is run before that branch of the process finishes.
The Multi-Merge pattern provides a means of merging distinct branches in a process into a single branch. Although several execution paths are merged, there is no synchronization of control-flow and each thread of control which is currently active in any of the preceding branches will flow unimpeded into the merged branch.
The operation of this pattern is illustrated in Figure 9. Any threads of control on incoming branches to p1 should be passed on to the outgoing branch. the analogy to this in CP-net terms, is that each incoming token to place p1 should be preserved. The distinction between this pattern and the Simple Merge is that it is possible for more than one incoming branch to be active simultaneously and there is no necessity for place p1 be safe.
Figure 9: Multi-merge pattern
There is one context condition associated with this pattern: the Multi-Merge must be associated with a specific preceding Multi-Choice construct.
iPlanet allows the Multi-Merge pattern to be implemented by specifying a trigger condition for a task that allows it to be triggered when any of its incoming routers are triggered. BPMN and XPDL directly implement it via the XOR-join construct and UML 2.0 ADs have an analogue in the form of the MergeNode construct. EPCs also provide the XOR-join construct, however they only expect one incoming thread of control and ignore subsequent simultaneous triggers, hence they do not support the pattern. FLOWer is able to support multiple concurrent threads through dynamic subplans however its highly structured nature does not enable it to provide general support for the Multi-Merge pattern. Although COSA is based on a Petri Net foundation, it only supports safe models and hence is unable to fully support the pattern. For example, both A and B in Figure 9 will block if there is a token in p1. Staffware attempts to maintain a safe process model by coalescing subsequent triggerings of a step whilst it is active into the same thread of control hence it is also unable to support this pattern. This behaviour is quite problematic as it creates a race condition in which all of the execution sequences ABC, BAC, ACBC and BCAB are possible.
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 assumptions. Partial support is awarded to offerings that do not provide support for multiple branches to merge simultaneously or do not provide for preservation of all threads of control when this does occur.
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. It is not possible to trigger a step twice. Where this occurs, the second thread cancels the first.|
|Websphere MQ||3.4||-||Not supported. An activity can only be triggered once, either when one or all of the incoming connectors evaluate to true.|
|FLOWer||3.51||+/-||It is possible to have multiple concurrent threads using dynamic subplans. Therefore, there is partial support for the pattern. However, since plans are highly structured, it is not possible to have an AND-split/XOR-join type of situation, i.e., the models are essentially "safe" (1-bounded).|
|COSA||5.1||+/-||Only safe Petri net diagrams can be used.|
|iPlanet||3.0||+||Supported by specifying a trigger condition for an activity with multiple incoming routers that fires when any incoming routers is activated.|
|SAP Workflow||4.6c||-||Not supported because the block structure of SAP Workflow forces the model to be "safe" (in Petri-net terms), i.e. it is not possible to enable or activate an activity in parallel with itself.|
|FileNet||3.5||+||Directly supported, workflow waits for all active steps to finish.|
|BPEL||1.1||-||Not supported. The language is block structured and it is not possible for two threads of execution to run through the same path in a single process instance.|
|Websphere Integration Developer||6.0||-||Not supported. The language is block structured and it is not possible for two threads of execution to run through the same path in a single process instance.|
|Oracle BPEL||10.1.2||-||Not supported. The language is block structured and it is not possible for two threads of execution to run through the same path in a single process instance.|
|BPMN||1.0||+||Supported by XOR-join gateway.|
|XPDL||2.0||+||Supported by the XOR-join construct.|
|UML ADs||2.0||+||Supported by the MergeNode construct.|
|EPC (implemented by ARIS toolset 6.2)||-||Not supported. When using an XOR-join connector only one incoming folder is expected. Most papers and books on EPCs state that the XOR-join should block if multiple folders arrive. However, the ARIS simulator implements this in a slightly different way. If multiple folders arrive at exactly the same time, they are ignored. Otherwise, each folder is passed on.|
|jBPM||3.1.4||+||jBPM implements multiple merge through a Task Node to which the split (earlier in the flow) treads, possibly running in parallel, converges.|
|OpenWFE||1.7.3||-||OpenWFE does not support it, due to its structured nature|
|Enhydra Shark||2||-||Enhydra Shark does not support multiple merge. If an activity (sub-flow, in Shark solution) is used to synchronize two transitions, it is enabled once or twice depending on the completion order of the activities to be merged and the merging activity (sub-flow). See Figure 2.|