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
- Basic Control Flow Patterns
- Sequence
- 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..
- 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.
- 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.
- 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.
- Advanced Branching and Synchronization
- Multi-Choice, Extension to 1.b) and 1.d)
- Multiple Choice based on conditions (Order variables, exit code etc.)
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- Structured Synchronizing Merge
- Requires a previous Multi-Choice pattern.
- 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.
- File Orders
- 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.
- Notes
- 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.
- 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.
- Consider use of dependencies from other job nets.
- Consider use of exit nodes in case of error if the result of a predecessor node is calculated from a condition.
Overview
Content Tools