This section describes how the original control-flow patterns are realised in YAWL. The solutions are grouped as follows:
- Basic Control Flow Patterns
- Advanced Branching and Synchronization Patterns
- Structural Patterns
- Multiple Instances Patterns
- State-based Patterns
- Cancellation Patterns
Task B follows task A.
Task B, task C and task D are executed in parallel after task A.
After the execution of task B, task C, and task D, task E can be executed.
A choice is made to execute either task B, task C or task D after execution of task A. Note that such a choice typically involves predicates specified for the various arcs. Currently such conditions are specified in XPath.
Task A will be started when any one of the tasks B, C or D completes. This solution is identical to the solution for the Multiple Merge. This pattern though makes a context assumption: there is no parallelism preceding task A.
Task B, task C, task D or any combination thereof is executed after task A. Note that such a choice typically involves predicates for the various arcs. Currently such conditions are specified in XPath.
Task A can execute when at least one of the tasks B, C, or D has completed and there is no possibility of another incoming branch becoming active in the foreseeable future, given the current state of the workflow. Note that this solution in YAWL does not impose any restrictions on the corresponding graph (e.g., it doesn't assume the existence of a corresponding multichoice).
See the solution for Simple Merge.
There are two different solutions for this.
The first thread that completes, triggers A and leads to cancellation of the other threads.
When t threads are completed, or if the number of threads is less than t when all threads are completed, task A can be initiated. Any remaining threads of task B are cancelled. This provides a solution to the n-out-of-m join. Note: the original pattern description did not prescribe cancellation of the "other threads".
YAWL does not impose any restrictions on cycles. A structure like the one pictured below is acceptable in YAWL.
This is the only control flow pattern not supported in YAWL. This choice was made on purpose to force designers to think carefully about workflow termination. In general it is very easy to achieve through; just connect all final tasks to an or-join which then acts as the single termination point.
Note, this solution does not always work. E.g., in case of preceding or-joins, or multiple executions of any final task.
Multiple Instances Without Synchronization
Tasks B and C are executed in parallel after task A. Task B is a multiple instance task of which between n and m instances will be created. Note that there is no synchronization between instances of B and C.
After task A, n instances of task B are created. When all such created instances are completed, task C can start.
Multiple Instances With a Priori Run Time Knowledge
Same solution as Multiple Instances With a Priori Design Time Knowledge except that n is replaced by XQuery expressions. These expressions are evaluated at run time to help determine how many instances of task B are to be created.
Multiple Instances Without a Priori Run Time Knowledge
After completion of task A, the XQueries xq 1 and xq 2 are evaluated to help determine the number of instances to be created of task B. The 'd' indicates that new instances may be created dynamically (to a maximum of the value of xq 2).
Note that synchronization of all created threads takes place before execution of task C which is not prescribed by the original pattern. To avoid this, a similar solution as described in Multiple Instances Without Synchronization may be used.
After task A, both tasks B and C are enabled. When one of them is selected for execution, the other one is disabled.
Given that YAWL is based on Petri nets, the idea of a mutex place can be used as presented in the patterns website.
None of the tasks A, B, C, or D are executed in parallel with any of the others. In addition, the execution of task B has to await completion of the execution of task A, and the execution of task D has to await completion of the execution of task C.
As with Interleaved Parallel Routing, here also the fact that YAWL is based on Petri nets can be exploited and the idea described in the patterns website used.
Task C can only be executed after completion of task D and task A, and before execution of task B.
Cancel Activity & Cancel Case
Execution of task B means cancellation of task A. In fact, any region can be chosen for cancellation so cancellation sets allow for cancellation of a single task, a whole case, and anything in between.