JS7 JobScheduler

Space shortcuts

Page tree

Purpose

  • 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

Basic Control Flow Patterns

Sequence

  • 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

Synchronization

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

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 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 be synchronized.

Advanced Branching and Synchronization

Multi-Choice

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

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

Blocking Discriminator 

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

Cancelling Discriminator

  • See Cancelling 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. Triggering the Cancelling Discriminator also cancels the execution of all of the other incoming branches and resets the construct." This pattern is a variant to the Structured Discriminator and to the Blocking Discriminator concerning the behavior in case of cancellation: any other parallel Orders in a Structured Discriminator will be cancelled if the first Order reaches the transition."
  • Support: Not yet supported. 
  • Implementation: With the first Split Order entering the Merge Instruction any additional Split Orders from incoming branches are cancelled.

Multi-Merge

  • 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 is implemented by managing parallelism for jobs.

Structured Partial Join

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

Generalized AND-Join

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

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

File Order Group Synchronization

  • Synchronization of  File Order Groups
    • The transition triggers if a group of file orders is available. The group is determined by a 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 Parent Order should implement a Fork Instruction with a dynamic number of branches in order to propagate which Child Orders (File Orders) it is waiting for.
  • Support: Not yet supported.

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


  • No labels