Pattern 29 (Cancelling Discriminator)

FLASH animation of Cancelling Discriminator pattern


The convergence of two or more branches 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 the first active incoming branch has been enabled. Triggering the Cancelling Discriminator also cancels the execution of all of the other incoming branches and resets the construct.


After the extract-sample task has completed, parts of the sample are sent to three distinct laboratories for examination. Once the first of these laboratories completes the sample-analysis, the other two task instances are cancelled and the review-drilling task commences.


This pattern provides a means of expediting a process instance where a series of incoming branches to a join need to be synchronized but it is not important that the tasks associated with each of the branches (other than the first of them) be completed.


The operation of this pattern is shown in Figure 45. Inputs i1 to im to the Cancelling Discriminator serve to identify the branches preceding the construct. Transitions A1 to Am signify tasks in these preceding branches. Transitions S1 to Sm indicate alternate "bypass" or "cancellation" tasks for each of these branches (these execution options are not initially available to incoming execution threads). The first control-flow token for a given case received at any input will cause B to fire and put a token in o1. As soon as this occurs, subsequent execution threads on other branches are put into "bypass mode" and instead of executing the normal tasks (A1..Am) on their specific branch, they can execute the "bypass" transitions (S1..Sm). (Note that the bypass transitions do not require any interaction. Hence they are executed directly by the PAIS and it can be assumed that the skip transitions are executed once they are enabled and complete almost instantaneously hence expediting completion of the branch). Once all incoming branches for a given case have been completed, the Cancelling Discriminator construct can then reset and be re-enabled again for the same case.

Figure 45: Cancelling discriminator pattern


There is one context condition associated with the use of this pattern: once the Cancelling Discriminator has been activated and has not yet been reset, it is not possible for another signal to be received on the activated branch or for multiple signals to be received on any incoming branch. In other words, all input palces to the Cancelling Discriminator (i.e. i1 to im) are safe.


In order to implement this pattern, it is necessary for the offering to support some means of denoting the extent of the incoming branches to be cancelled. This can be based on the Cancel Region pattern although support is only required for a restricted form of the pattern as the region to be cancelled will always be a connected subgraph of the overall process model with the Cancelling Discriminator construct being the connection point for all of the incoming branches.

This pattern is supported by the fork construct in SAP Workflow with the number of branches required for completion set to one. In BPMN it is achieved by incorporating the incoming branches and the Cancelling Discriminator in a subprocess that has an error event associated with it. The error event is triggered, cancelling the remaining branches in the subprocess, when the Cancelling Discriminator is triggered by first incoming branch. This configuration is illustrated in Figure 46(a). A similar solution is available in XPDL. UML 2.0 ADs support the pattern in a similar way by enclosing all of the incoming branches in an InterruptibleActivityRegion which is cancelled when the Cancelling Discriminator fires.

Figure 46: Cancelling discriminator pattern in BPMN and UML 2.0 ADs


The major difficulty with this pattern is in determining how much of the process model preceding the Cancelling Discriminator is to be included in the cancellation region.


This issue is easily addressed in structured processes as all of the branches back to the preceding split construct which corresponds to the Cancelling Discriminator should be subject to cancellation. In Figure 47(a), it is easy to see that the area denoted by the dotted box should be the cancellation region. It is a more complex matter when the process is not structured (e.g. as in Figure 47(b)) or other input arcs exist into the preceding branches to the Cancelling Discriminator that are not related to the corresponding split as shown in Figure 47(c). In both of these situations, the overall structure of the process leading up to the Cancelling Discriminator serves as a determinant of whether the pattern can be supported or not. In Figure 47(b), a cancellation region can be conceived which reaches back to the first AND-split and the pattern can be implemented based on this. A formal approach to determining the scope of the cancellation region can be found elsewhere [vdA01]. In Figure 47(c), the potential for other control-flows to be introduced which do not related to the earlier AND-split, means that the pattern probably cannot be supported in the process model of this form.

Figure 47: Process structure considerations for cancelling discriminator

Evaluation Criteria

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. An offering is considered to provide partial support for the pattern if there are side-effects associated with the execution of the pattern (e.g. tasks in incoming branches which have not completed being recorded as complete).

Product Evaluation

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.
Websphere MQ 3.4 - Not supported. There is no support for the discriminator pattern or any ability to cancel a set of (preceding) activities.
FLOWer 3.51 - Not supported. Dynamic subplans can have an auto complete condition however this is only evaluated when all subplans have completed.
COSA 5.1 - Similar to WCP28, no direct support.
iPlanet 3.0 - Not supported. No ability to cancel portions of a process model.
SAP Workflow 4.6c + This pattern is supported by the fork construct which allows for the specification of the number of branches that needs to complete. This can be set 1 one thus resulting in a discriminator. When completing the first branch all remaining branches are cancelled.
FileNet 3.5 - Not supported.
BPEL 1.1 - Not supported. As for WCP28.
Websphere Integration Developer 6.0 - Not supported. As for WCP28.
Oracle BPEL 10.1.2 - Not supported. As for WCP28.
BPMN 1.0 + Supported by including the incoming branches and the OR-join in a subprocess that passes control to the following activity once the first branch has completed as well as cancelling the remaining activities in the sub-process using an error type intermediate event.
XPDL 2.0 + Supported by including the incoming branches and the OR-join in a subprocess that passes control to the following activity once the first branch has completed as well as cancelling the remaining activities in the sub-process using an error event.
UML ADs 2.0 + Supported by incorporating the incoming branches to the join in an interruptible region. The join has an outgoing weight of 1 from the interruptible region to the subsequent activity effectively cancelling all other branches when the first branch reaches the join.
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 structured discriminator through the <concurrence> construct with the attribute settings count = "1" and remaining = "cancel".
Enhydra Shark 2 - Enhydra Shark does not directly support this pattern.