Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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

Parallel Split

  • 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: 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.

Synchronization

...

  • 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

Parallel Split

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

Simple Merge

  • 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 MergeMerge pattern, Orders from the connected branches can pass at any time. The Simple Merge pattern should will use the Merge Instruction with a setting not to synchronize branches.

...

  • 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 can be is implemented by a JS7 - Fork Instruction immediately followed by an If Instruction per / 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.

...

  • See 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 for the first Order only. Subsequent Orders are ignored by this pattern.
  • Support: Not supported. a Merge Instruction is required.
  • Implementation: This Pattern pattern can be implemented for Split Orders that are created by a previous Split Instruction in the workflow. The Order is not affected by the execution of Split Orders.

...

  • See Blocking 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. The Blocking Discriminator construct resets when all active incoming branches have been enabled once for the same process instance. Subsequent enablements of incoming branches are blocked until the Blocking Discriminator has reset."
    • This pattern is an extension to the Structured Discriminator pattern and limits the Structured Discriminator to single task operation.
  • Support: Partly supported.
  • Implementation: This pattern is not explicitly applied but is implemented by managing parallelism for Orders in a way that only one Order (and any number of Child Orders or Split Orders) can enter a workflow. The lifetime of the Order specifies the period after which the Blocking Discriminator is reset. In addition, task limits for processing of a single task implement this pattern.

...

  • See Multi-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."
    • This pattern is an extension to the Simple Merge pattern. The pattern is applied to each incoming Split Order independently from each other.
    • Delimitation with Simple Merge: the predecessor nodes are active in parallel.
  • Support: Not yet supported.
  • Implementation: With the Merge Instruction being available this pattern can be is implemented by managing parallelism for jobs.

...

  • 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: Not supported. 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: 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: Not yet Fully supported.
  • Implementation: All A combination of JS7 - Fork / Join Instruction or JS7 - ForkList / Join Instruction and the JS7 - ExpectNotice Instruction. The Fork/ForkList Instruction guarantees that 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 differentThe ExpectNotice Instruction implements additional triggers that have to be met to make an order proceed in a branch.

Structured Synchronizing Merge

  • 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: Not 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: Not Fully supported.
  • Implementation: Includes  JS7 - ForkList / Join Instruction. The instruction includes a dynamically calculated number of predecessor nodes branches that have to be processed before the Join operation continues. For the decision which how many branches to synchronize local Order variables can be used .

...

  • 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. Parent Order Orders will only continue after completion of Child Orders.
  • 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.

...