JS7 JobScheduler

Space shortcuts

Page tree

Introduction

There can be situations when a given workflow should be processed by a single order only. Any additional orders should wait for the first order to complete and to leave the workflow. This mechanism is called order serialization.

Order serialization is different from job parallelism

  • Job parallelism applies to the number of instances of a job that are executed by parallel orders.
    • For example, if a workflow includes a number of jobs for which parallelism is limited to 1 task then the following applies:
      • With 3 orders entering the workflow the first order will execute job1. The remaining orders wait in front of job1.
      • With job1 being processed then order1 moves on and starts to process job2.
      • At the same time order2 will start to process job1.
      • With job1 being processed then order2 to moves to process job2 and order3 starts to process job1.
    • This means that job parallelism allows any number of orders to be active in a workflow. It limits the number of orders that execute a job in parallel.
  • Order serialization is intended to make any additional orders wait for a previous order to complete the workflow before they will enter the workflow.

Use of Lock Instruction

Exclusive Use of Lock

The Lock Instruction in this example is used to prevent any additional orders from entering a workflow.

Download (upload .json): 

In the Configuration view the workflow looks like this:

  • the Lock Instruction spawns any jobs and other instructions in the workflow.
  • the pdSerialLockSingle Resource Lock is used in exclusive mode to prevent access by parallel orders.


The configuration of the pdSerialLockSingle Resource Lock looks like this:


In the Workflows view at run-time the workflow looks like this:

  • one order is running in the workflow.
  • any additional orders wait in front of the workflow.

Shared Use of Lock

The Lock Instructions in this example implement mixed use of limiting and preventing the number of additional orders in different sections of a workflow:

  • the outer section of the workflow can be executed by a limited number of orders.
  • the inner section of the workflow can be executed by single order only.

Download (upload .json): 

In the Configuration view the workflow looks like this:

  • two Lock Instructions
    • the outer Lock Instruction spawns any jobs and other instructions in the workflow and makes shared use of a Resource Lock using weight 1.
    • the inner Lock Instruction spawns a specific section in the workflow and makes exclusive use of a Resource Lock.
  • two Resource Locks are used
    • the pdSerialLockMulti Resource Lock is used in shared mode by the outer Lock Instruction to limit access by parallel orders, for example to 10 orders.
    • the pdSerialLockSingle Resource Lock is used in exclusive mode by the inner Lock Instruction to prevent access by parallel orders.


The configuration of the pdSerialLockSingle Resource Lock looks like in the above example.
The configuration of the pdSerialLockMulti Resource Lock allows the lock to be acquired in parallel by any number of orders up to its capacity like this:


In the Workflows view at run-time the workflow looks like this:

  • three orders acquire the outer Resource Lock and enter the outer section of the workflow in parallel.
  • one order acquires the inner Resource Lock and is running in the workflow's inner section.
  • one order is running in the outer section of the workflow.
  • one order is waiting in the outer section of the workflow as job parallelism is limited to 1.
  • it is guaranteed that only one order at a time will enter the inner section  of the workflow.

Error Handling

Starting from the above example, if an error occurs in a job or other instruction the following default behavior applies:

  • The order is moved to the outmost Lock Instruction and is set to the failed state.
  • The Resource Lock therefore is freed and parallel orders can enter the workflow.
  • Users who wish orders to remain with a failing job or other instruction and to continue blocking Resource Locks can apply the JS7 - Options Instruction.

Use of Options Instruction and Lock Instruction

Considering error handling the previous examples allow additional orders to enter a workflow if a previous order fails and is moved to the outmost Lock Instruction in a workflow.

Users might wish a more strict behavior preventing additional orders to enter a workflow even in case that a previous order fails in a workflow. To this purpose the JS7 - Options Instruction is used which causes an order to remain with the failing job and prevents additional orders from entering the workflow.

Find more examples and details from the JS7 - Options Instruction article.

FEATURE AVAILABILITY STARTING FROM RELEASE 2.5.3

Exclusive Use of Lock

The example applies to use of a single lock in shared mode.

Download (upload .json): 

In the Configuration view the workflow looks like this:

  • the Options Instruction spawns any instructions in the workflow.
  • the Lock Instruction spawns subsequent jobs and other instructions in the workflow.
  • the pdSerialLockSingle Resource Lock is used in exclusive mode to prevent access by parallel orders.
  • the job2 job is assumed to fail with return code 3.


In the Workflows view at run-time the workflow looks like this:

  • one order is remaining in the workflow in a failed state with job2.
  • any additional orders wait in front of the Lock Instruction.

Shared Use of Lock

The example implements mixed use of limiting and preventing the number of additional orders in different sections of a workflow:

  • the outer section of the workflow can be executed by a limited number of orders.
  • the inner section of the workflow can be executed by single order only.

Download (upload .json): 

In the Configuration view the workflow looks like this:

  • the Options Instruction spawns any instructions in the workflow.
  • the outer Lock Instruction spawns subsequent jobs and other instructions in the workflow.
    • the pdSerialLockMulti Resource Lock is used in shared mode to allow a number of parallel orders.
  • the inner Lock Instruction spawns a section of the workflow that should be used by single order only.
    • the pdSerialLockSingle Resource Lock is used in exclusive mode to prevent access by parallel orders.
  • the job2 job is assumed to fail with return code 3.


In the Workflows view at run-time the workflow looks like this:

  • one order is remaining in the workflow in a failed state with job2.
  • any additional orders wait in front of the inner Lock Instruction.

Further Resources


  • No labels