Purpose

• Workflow patterns are used to specify dependencies between jobs such as implementing a fork operation for parallel execution of jobs and and a join operation to continue processing only when any parallel jobs completed.
• JS7 supports a number of standard Workflow Patterns
• JS7 implements dependencies by instructions that are added to a workflow, see JS7 - Workflow Instructions

Supported Workflow Patterns

1. Basic Control Flow Patterns
1. Sequence
   • Pattern: "A task in a process (workflow) is enabled after the completion of a preceding task in the same process (workflow)."
   • Support: Fully supported
   • Implementation: JS7 - Job Instruction
2. Parallel Split
   • Pattern: "The divergence of a branch into two or more parallel branches each of which execute concurrently. There is no join operation for this pattern."
   • Support: Not yet supported. A Split Instruction is required.
   • Implementation: Split Orders are split from an Order to a number of branches. Split branches are not joined. There is no relationship between Order and Split Orders. The Split Orders' results are not available to the Order. The Order continues immediately after the Split Instruction.
3. Synchronization
   • Pattern: "The convergence of two or more branches into a single subsequent branch such that the thread of control is passed to the subsequent branch when all input branches have been enabled."
   • Support: Not yet supported. A Merge Instruction is required.
   • Implementation: This pattern occurs for Split Orders that are created from a Split Instruction. Split Orders from any connected branches can be merged into a single new Split Order.
4. Exclusive Choice
   • Pattern: "The divergence of a branch into two or more branches such that when the incoming branch is enabled, the thread of control is immediately passed to precisely one of the outgoing branches based on a mechanism that can select one of the outgoing branches." This pattern implements an XOR choice, i.e. only one branch is processed.
   • Support: Fully supported.
   • Implementation: JS7 - If Instruction
5. Simple Merge
   • Pattern: "The convergence of two or more branches into a single subsequent branch such that each enablement of an incoming branch results in the thread of control being passed to the subsequent branch."
   • Support: Not supported. A Merge Instruction is required.
   • Implementation: This pattern is a variant of the Synchronization pattern. The difference is that the Merge Instruction for Synchronization expects all incoming branches to be enabled whereas when used for a Simple Merge Orders from any connected branches can pass at any time. This pattern should use the Merge Instruction with a setting not to synchronize branches.
2. Advanced Branching and Synchronization
1. Multi-Choice
   • Pattern: "The divergence of a branch into two or more branches such that when the incoming branch is enabled, the thread of control is immediately passed to one or more of the outgoing branches based on a mechanism that selects one or more outgoing branches." The pattern is an Extension to the Parallel Split and to the Exclusive Choice.
   • Support: Partially supported. A Choice Instruction is required.
     • This pattern can be implemented by a Fork Instruction immediately followed by an If Instruction per branch.
   • Implementation: Similarly to an If Instruction an expression is evaluated. However, there is an individual expression for each branch of the Choice Instruction. Expressions for multiple branches can evaluate to true thus creating Split Orders. 
2. Structured Discriminator
   • Pattern: "The convergence of two or more branches into a single subsequent branch following a corresponding divergence earlier in the process model such that the thread of control is passed to the subsequent branch when the first incoming branch has been enabled. Subsequent enablements of incoming branches do not result in the thread of control being passed on. The Structured Discriminator construct resets when all incoming branches have been enabled. The Structured Discriminator occurs in a structured context, i.e. there must be a single Parallel Split construct earlier in the process model with which the Structured Discriminator is associated and it must merge all of the branches emanating from the Structured Discriminator. These branches must either flow from the Parallel Split to the Structured Discriminator without any splits or joins or they must be structured in form (i.e. balanced splits and joins)."
   • This pattern is executed by the first Order only. Subsequent Orders are ignored by this pattern.
   • This implies that the Parent Order has been determined.
3. Blocking Discriminator (with changes), Extension to 2.b)
   • Restricts the Structured Discriminator to single task operation.
   • This pattern will not be explicitly used, however, it will be supported by managing parallelism for Orders.
4. 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." This pattern is a variant to the Structured Discriminator and to the Blocking Discriminator concerning the behavior in case of cancellation: any other parallel Orders in a Structured Discriminator will be cancelled if the first Order reaches the transition.
   • Support: Not supported. 
5. Multi-Merge (with changes), Extension to 1.e)
   • The pattern does not implement an XOR choice for multiple Orders, instead, it indicates re-usability.
   • Delimitation with Simple Merge: the predecessor nodes are active in parallel.
   • This pattern will not be explicitly used, however, it will be supported by managing parallelism for Jobs.
6. Structured Partial Join, Blocking Partial Join, Cancelling Partial Join
   • A dynamically calculated number of Orders triggers a Join operation. The subsequent task starts and completes, it should not be re-started before the last incoming Order has reached the transition.
   • This pattern will not be explicitly used, however, it will be supported by managing parallelism for Orders.
7. Generalized AND-Join (with changes), Extension to 1.c)
   • All parallel predecessor nodes have to be processed before the Join operations continues.
   • This pattern will be supported, however, management of Order parallelism will be different.
8. Structured Synchronizing Merge
   • Requires a previous Multi-Choice pattern.
9. Local Synchronizing Merge
   • Dynamically calculated number of predecessor nodes that have to be processed before the Join operation continues.
   • For the decision which branches should be synchronized local Order data can be used (parameters, payload.
3. File Orders
1. Synchronization of  File Order Groups
   • The transition triggers if a group of file orders is available. The group is determined by common indicator, e.g. a constant part of the file name.
   • The first File Order causes a Parent Order to be generated. The Parent Order implies the condition to wait for n File Orders (Child Orders) of the same group. All File Orders are Child Orders.
   • Optionally for better visibility the first File Order should cause a Split/Join Operation in order to propagate which Child Orders (File Orders) it is waiting for.
4. Notes
1. Parent Orders and Child Orders are not executed in parallel: Parent Orders represent the expectation that Child Orders will become available, will be processed and will be completed. Only after completion of Child Orders a Parent Order will continue.
2. Workflows dispose of an entry point and an exit point.
   • If a number of Orders is required to start a workflow then processing occurs similarly to File Order Groups. Such Orders are considered being Child Orders and a Parent Order is generated.
3. Consider use of dependencies from other job nets.
4. Consider use of exit nodes in case of error if the result of a predecessor node is calculated from a condition.