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 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
2. Parallel Split
   • Has to be used with a subsequent Join operation: Child Orders are dismissed in a Join transition, their parameters are merged with the  Parent Order.
   • The Parent Order is not dismissed.
   • Subsequently to a Parallel Split a Multi-Join has to follow. This should be supported by a common workflow template..
3. Synchronization
   • For each predecessor node of a transition an Order is expected. The transition is triggered if all required Orders are available in the predecessor nodes.
4. Exclusive Choice
   • Simple XOR Choice, i.e. only one branch is processed. This transition implements a rule, optionally an external rule, that determines the branch to be processed.
5. Simple Merge
   • Does not synchronize or join Orders. The pattern is simply about re-usability of jobs.
   • Predecessor nodes are not active at the same time. The behavior corresponds to <job_chain max_orders=“1“> with JobScheduler1.
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.