Extending the example of Pattern 6 (Multi-choice), after either or both of the activities contact_fire_department and contact_insurance_company have been completed (depending on whether they were executed at all), the activity submit report needs to be performed (exactly once).

  Problem  The main difficulty with this pattern is to decide when to synchronize and when to merge. Generally speaking, this type of merge needs to have some capacity to be able to determine whether it may (still) expect activation from some of its branches.
Implementation

 

The two workflow engines known to the authors that provide a straightforward construct for the realization of this pattern are MQSeries/Workflow and InConcert. As noted earlier, if a synchronizing merge follows an OR-split and more than one outgoing transition of that OR-split can be triggered, it is not until runtime that we can tell whether or not synchronization should take place. MQSeries/Workflow works around that problem by passing a False token for each transition that evaluates to False and a True token for each transition that evaluates to True. The merge will wait until it receives tokens from each incoming transition. InConcert does not use a False token concept. Instead it passes a token through every transition in a graph. This token may or may not enable the execution of an activity depending on the entry condition. This way every activity having more than one incoming transition can expect that it will receive a token from each one of them, thus deadlock cannot occur. The careful reader may note that these evaluation strategies require that the workflow process does not contain cycles.

 

In Eastman, "non-parallel work items routed to Join worksteps bypass Join Processing", hence an XOR-split followed by an AND-join does not have to lead to deadlock.

 

In other workflow engines the implementation of the synchronizing merge typically is not straightforward. The only solution is to avoid the explicit use of the OR-split that may trigger more than one outgoing transition and implement it as a combination of AND-splits and XOR-splits (see Pattern 6 (Multi-choice)). This way we can easily synchronize corresponding branches by using AND-join and standard merge constructs.