Pattern 31 (Blocking Partial Join)

FLASH animation of Blocking Partial Join pattern


The convergence of two or more branches (say m) into a single subsequent branch following one or more corresponding divergences earlier in the process model. The thread of control is passed to the subsequent branch when n of the incoming branches has been enabled (where 2 = n < m). The join construct resets when all active incoming branches have been enabled once for the same process instance. Subsequent enablements of incoming branches are blocked until the join has reset.


When the first member of the visiting delegation arrives, the check credentials task can commence. It concludes when either the ambassador or the president arrived. Owing to staff constraints, only one instance of the check credentials task can be undertaken at any time. Should members of another delegation arrive, the checking of their credentials is delayed until the first check credentials task has completed.


The Blocking Partial Join is a variant of the Structured Partial Join that is able to run in environments where there are concurrent process instances, particularly process instances that have multiple concurrent execution threads.


Figure 49 illustrates the operation of this pattern. The Blocking Partial Join functions by keeping track of which inputs have been enabled (via the triggered input place) and preventing them from being re-enabled until the construct has reset as a consequence of receiving a trigger on each incoming place. After n incoming triggers have been received for a given process instance (via tokens being received in n distinct input places from i1 to im), the join fires and a token is placed in output o1. The completion of the remaining n-m branches have no impact on the join except that it is reset when the last of them is received.

Figure 49: Blocking partial join pattern

The pattern shares the same advantages over the Structured Partial Join as the Blocking Discriminator does over the Structured Discriminator, namely greater flexibility as it is able to deal with the situation where a branch is triggered more than once e.g. where the construct exists within a loop.


There are no specific context conditions associated with the pattern.


The approach to implementing this pattern is essentially the same as that for the Blocking Discriminator except that the join fires when n incoming branches have triggered rather than just the first. The Blocking Partial Join is partially supported by BPMN, XPDL and UML 2.0 ADs as it is unclear how the join condition is specified.


None identified.



Evaluation Criteria

An offering achieves full support if it provides a construct that satisfies the description for the pattern. If there is any ambiguity in how the join condition is specified, an offering is considered to provide partial support for the pattern.

Product Evaluation






Staffware 10 - Not supported.
Websphere MQ 3.4 - Not supported. There is no direct support for multiple instance activities.
FLOWer 3.51 - Not supported. The remaining subplan activities are forced to complete.
COSA 5.1 - Similar to WCP30, no direct support.
iPlanet 3.0 - Not supported. No ability to block activity triggerings.
SAP Workflow 4.6c - Not supported because of the structured/safe nature of SAP workflow.
FileNet 3.5 - Not supported.
BPEL 1.1 - Not supported. As for WCP30.
Websphere Integration Developer 6.0 - Not supported. As for WCP30.
Oracle BPEL 10.1.2 - Not supported. As for WCP30.
UML ADs 2.0 +/- The specific configuration of the JoinSpec condition to achieve this is unclear.
EPC (implemented by ARIS toolset 6.2) - Not supported.
jBPM 3.1.4 - jBPM does not support this pattern.
OpenWFE 1.7.3 - OpenWFE does not support this pattern.