Pattern 29 (Cancelling Discriminator)

FLASH animation of Cancelling Discriminator pattern

Description

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.

Examples

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.

Motivation

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.

Overview

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

Context

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.

Implementation

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

Issues

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.

Solutions

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.