Introduction
The Options Instruction rules error handling for a number of instructions:
If the Options Instruction is in place and specifies the Stop on Failure attribute then failed orders will remain with the failing instruction, for example a job.
- This configuration is used if Locks are not considered resources for shared access by jobs but are used to prevent entry of parallel orders to a number of subsequent instructions.
- For example, if a Lock Instruction spawns a complete workflow to prevent parallel orders from entering the workflow before the current order leaves the workflow.
- For example, if a Notice is not consumed by a number of workflows but is used to prevent repeated execution of the same workflow for the same Daily Plan date.
If no Options Instruction is in place then orders that fail within one of the instructions will be moved to the begin of the instruction and will remain in a failed state.
- The motivation for this behavior being that Locks and Notices are considered resources that should not be blocked by failed orders.
- For example, if a Lock Instruction is used to limit access to a database by parallel jobs. In case of failure of a job the order moves to the begin of the Lock Instruction to free the resource.
- For example, if a ConsumeNotices Instruction is used to expect and to delete a Notice in transactional manner. In case of failure the order moves to the begin of the ConsumeNotices Instruction to allow other ConsumeNotices Instructions in parallel workflows to delete the Notice and not to delay deletion by a failed order.
- This behavior similarly applies to use of nested Lock Instructions and nested ConsumeNotices Instructions.
- A failed order will be moved to the outmost Lock Instruction or ConsumeNotices instruction to free any resources blocked by nested instructions.
FEATURE AVAILABILITY STARTING FROM RELEASE 2.5.3
Lock Instruction
Use with StopOnFailure Option
This example introduces a situation when users find a nested JS7 - Lock Instruction.
Download (upload .json):
The example implements nested use of Lock Instructions with orders remaining at their workflow position in case of failure.
- the Options Instruction is used to set the StopOnFailure attribute.
- the first Lock Instruction expects the
pdErrorLockBig
Lock being present. - the second Lock Instruction occurs inside the first instruction and expects the
pdErrorLockSmall
Lock being present. - the
job3a
job is assumed to fail with return code3
.
In the Configuration view the workflow looks like this:
At run-time in the Workflows view the workflow looks like this for a failed order:
- the failed order remains with the failed job.
- the
pdErrorLockBig
andpdErrorLockSmall
Resource Locks remain blocked by respective Lock Instructions and are not freed before the order leaves the instruction block.
Use without StopOnFailure Option
This example introduces a situation when users find a nested JS7 - Lock Instruction.
Download (upload .json):
The example implements nested use of Lock Instructions with orders moving to the outmost Lock Instruction in case of failure.
- no Options Instruction is used.
- the first Lock Instruction expects the
pdErrorLockBig
Lock being present. - the second Lock Instruction occurs inside the first instruction and expects the
pdErrorLockSmall
Lock being present. - the
job3a
job is assumed to fail with return code3
.
In the Configuration view the workflow looks like this:
At run-time in the Workflows view the workflow looks like this for a failed order:
- the failed order moves to the outmost Lock Instruction and remains in a failed state.
- the
pdErrorLockBig
andpdErrorLockSmall
Locks are freed and are available to other Lock Instructions.
ConsumeNotices Instruction
Use with StopOnFailure Option
This example introduces a situation when users find a nested JS7 - ConsumeNotices Instruction.
Download (upload .json):
- pdErrorNotice01.noticeboard.json
- pdErrorNotice02.noticeboard.json
- pdErrorNoticeFailWithInstruction.workflow.json
The example implements nested use of ConsumeNotices Instructions with orders remaining at their workflow position in case of failure.
- the Options Instruction is used to set the StopOnFailure attribute.
- the first ConsumeNotices Instruction expects the
Notice01
Notice being present. - the second ConsumeNotices Instruction occurs inside the first instruction and expects the
Notice02
Notice being present. - the
job3a
job is assumed to fail with return code3
.
In the Configuration view the workflow looks like this:
At run-time in the Workflows view the workflow looks like this for a failed order:
- the failed order remains with the failed job.
- the
Notice01
andNotice02
Notices are consumed by respective ConsumeNotices Instructions and are not removed before the order leaves the instruction block.
Use without StopOnFailure Option
This example introduces a situation when users find a nested JS7 - ConsumeNotices Instruction.
Download (upload .json):
- pdErrorNotice01.noticeboard.json
- pdErrorNotice02.noticeboard.json
- pdErrorNoticeFailWithNotice.workflow.json
The example implements nested use of ConsumeNotices Instructions with orders moving to the outmost ConsumeNotices Instruction in case of failure.
- no Options Instruction is used.
- the first ConsumeNotices Instruction expects the
Notice01
Notice being present. - the second ConsumeNotices Instruction occurs inside the first instruction and expects the
Notice02
Notice being present. - the
job3a
job is assumed to fail with return code3
.
In the Configuration view the workflow looks like this:
At run-time in the Workflows view the workflow looks like this for a failed order:
- the failed order moves to the outmost ConsumeNotices Instruction.
- the
Notice01
andNotice02
Notices are freed and remain available for parallel ConsumeNotices Instructions in other workflows.