...

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

...

• See 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: Fully supported.
• Implementation: JS7 - Fork / -Join Instruction, JS7 - ForkList / -Join Instruction

Exclusive Choice

• See 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

...

• See 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: Partly supported. The JS7 - AddOrder Instruction can be used in a JS7 - Fork / -Join Instruction or JS7 - ForkList / -Join Instruction to run orders independently without joining. For full workflow pattern support a Split Instruction is required.
• Current Implementation: JS7 - AddOrder Instruction
• Future 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.

...

• See 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.
• Future 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 before proceeding, whereas when the Merge Instruction is used for a Simple Merge pattern, Orders from connected branches can pass at any time. The Simple Merge pattern will use the Merge Instruction with a setting where branches are not to synchronize branchesbe synchronized.

Advanced Branching and Synchronization

...

• See 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."
  • This pattern is an Extension to the Parallel Split and to the Exclusive Choice patterns.
• Support: Fully supported. .
• Implementation: This pattern is implemented by a JS7 - Fork / -Join Instruction or JS7 - ForkList / -Join Instruction immediately followed by a JS7 - If Instruction per branch.
• Implementation with a future Choice Instruction: 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.

...

• Structured Partial Join, Blocking Partial Join, Cancelling Partial Join
• Pattern: "The convergence of two or more branches (say m) 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 n of the incoming branches have been enabled where n is less than m. Subsequent enablements of incoming branches do not result in the thread of control being passed on. The join construct resets when all active incoming branches have been enabled. The join occurs in a structured context, i.e. there must be a single Parallel Split construct earlier in the process model with which the join is associated and it must merge all of the branches emanating from the Parallel Split. These branches must either flow from the Parallel Split to the join without any splits or joins or be structured in form (i.e. balanced splits and joins)."
• Support: Partly supported. The JS7 - ForkList / -Join Instruction allows a dynamic number of branches to be created. Similar to a JS7 - Fork / -Join Instruction, any number of jobs and other instructions can be used in a branch. A branch is configured just once and is dynamically parallelized at run-time by a list of variables carried by the order.
• Current Implementation: JS7 - ForkList / -Join Instruction
• Future Implementation: A dynamically calculated number of Split Orders triggers a Merge Instruction. The subsequent task starts and completes, it should not be re-started before the last incoming Order has reached the instruction. This pattern will not be explicitly applied, however, it can be supported by managing parallelism for Orders.

...

• See Generalized AND-Join
• 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. Additional triggers received on one or more branches between firings of the join persist and are retained for future firings. Over time, each of the incoming branches should deliver the same number of triggers to the AND-join construct (although obviously, the timing of these triggers may vary)."
  • This pattern is an extension to the Blocking Discriminator pattern.
• Support: Fully supported.
• Implementation: A combination of JS7 - Fork / -Join Instruction or JS7 - ForkList / -Join Instruction and the JS7 - ExpectNotice ExpectNotices Instruction. The Fork/ForkList Instruction guarantees that all parallel predecessor nodes have to be processed before the Join operations continues. The ExpectNotice Instruction implements additional triggers that have to be met to make an order proceed in a branch.

...

• See Structured Synchronizing Merge
• Pattern: "The convergence of two or more branches (which diverged earlier in the process at a uniquely identifiable point) into a single subsequent branch such that the thread of control is passed to the subsequent branch when each active incoming branch has been enabled. The Structured Synchronizing Merge occurs in a structured context, i.e. there must be a single Multi-Choice construct earlier in the process model with which the Structured Synchronizing Merge is associated and it must merge all of the branches emanating from the Multi-Choice. These branches must either flow from the Structured Synchronizing Merge without any splits or joins or they must be structured in form (i.e. balanced splits and joins)."
• Support: Fully supported.
• Implementation: JS7 - Fork / -Join Instruction

Local Synchronizing Merge

• See Local Synchronizing Merge
• Pattern: "The convergence of two or more branches which diverged earlier in the process into a single subsequent branch such that the thread of control is passed to the subsequent branch when each active incoming branch has been enabled. Determination of how many branches require synchronization is made on the basis on information locally available to the merge construct. This may be communicated directly to the merge by the preceding diverging construct or alternatively it can be determined on the basis of local data such as the threads of control arriving at the merge."
• Support: Fully supported.
• Implementation: JS7 - ForkList / -Join Instruction. The instruction includes a dynamically calculated number of branches that have to be processed before the Join operation continues. For the decision how many branches to synchronize local Order variables can be used .

...