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 workflow is enabled after the completion of a preceding task in the same workflow.
   • Support: Fully supported
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 supported. A Split Instruction should be added.
   • Implementation: Split Orders are split from the Order to a number of branches. Split branches are not joined. There is no relationship between Order and Split Orders. The Split Order's 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 supported. A Merge Instruction should be added.
   • Implementation: This pattern occurs for Split Orders that are created from a Split Instruction. Split Orders from any connected branches are 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.
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. 
   • 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, Extension to 1.b) and 1.d)
   • Multiple Choice based on conditions (Order variables, exit code etc.)
2. Structured Discriminator
   • 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
   • Variant to 2.b) and 2.c) concerning behavior in case of cancellation: other Child Orders in a Structured Discriminator will be cancelled if the first Child Order reaches the transition.
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.