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 entering 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): pdSerialLock.workflow.json

In the Configuration view the workflow looks like this:

• the Lock Instruction spawn 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 Instruction in this example explains 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): pdSerialLockNested.workflow.json

In the Configuration view the workflow looks like this:

• two Lock Instructions
  • the outer Lock Instruction spawn any jobs and other instructions in the workflow.
  • the inner Lock Instruction spawns a specific section in the workflow.
• 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 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.

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

Error Handling

Further Resources

• JS7 - Lock Instruction
• JS7 - Options Instruction