JS7 JobScheduler

Space shortcuts

Page tree

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 8 Next »

Introduction

JS7 offers a number of strategies for error handling that are explained from the below matrix.

The following matrix shows possible combinations for the handling of job errors and warnings:

Use CaseJobOrderOrder HistoryNotificationUser Intervention
No.On ErrorOn WarningStoppedContinuedFinishedSuccessfulFailedOptionalResume OrderSuspend OrderCancel Order
Use Case 1yesnoyesnono--yesyesyesyes
Use Case 2yesnonoyesno--yes---
Use Case 3yesnononoyesnoyesyes---
Use Case 4yesnononoyesyesnoyes---
Use Case 5noyesnoyesno--yes---

Use Cases

Use Case 1: Job error makes order stop

In this scenario an order stops subsequently to a job error. The order is put in the failed state. This is the default behavior if no workflow instructions for error handling are used.

  • The History outcome is not determined as the order remains in the workflow. The History outcome will be determined from later User Intervention.
  • Notifications can optionally be sent.
  • User Interventions include the following operations:
    • Resume Order: The order will be continued at the same, at a previous or at a later workflow instruction
    • Suspend Order: The order will be suspended and will be resumed or cancelled later on.
    • Cancel Order: The order will be cancelled and the History outcome will indicate the failed order execution.


Example for default error handling 
job1
job2
job3

Explanation:

  • If any of job1, job2 or job3 raises an error then the order stops and is put in the failed state.
  • User Intervention is required to resume, to suspend or to cancel the order.

Use Case 2: Job error lets order continue

In this scenario a job error is caught and is handled in a way that lets the order continue in the workflow:

  • The History outcome is not determined as the order continues in the workflow. The History outcome will be determined from later workflow instructions.
  • Notifications can optionally be sent.
  • User Interventions is not applicable.


Example for catching a job error 
Try
    job1
    job2
Catch
Catch-End
job3

Explanation:

  • if any of job1 or job2 in the Try block raises an error then the empty Catch block lets the order continue.
  • Leaving the Catch block the order will continue with job3.


Example for catching a job error by use of a recovery job 
Try
    job1
    job2
Catch
    job2a
Catch-End
job3

Explanation:

  • if any of job1 or job2 in the Try block raises an error then the order will enter the Catch block.
  • In the Catch block job2a is executed.
    • If job2a completes successfully then the order will leave the Catch block and will continue with job3.
    • If job2a fails then the order will be put in the failed state, will be stopped and will remain in the Catch block to wait for User Intervention
    • Consider that Try-Catch instructions can be nested, i.e. in a Catch block another Try-Catch instruction can be used for error handling.

Use Case 3: Job error makes order leave the workflow with failed history outcome

In this scenario a job error is caught and is handled in a way that makes the order leave the workflow:

  • The History outcome is specified to be failed as a Fail instruction is used.
  • Notifications can optionally be sent.
  • User Interventions is not applicable.


Example for catching a job error with failed history outcome 
Try
    job1
    job2
Catch
    Fail (leave workflow)
Catch-End
job3

Explanation:

  • if any of job1 or job2 in the Try block raises an error then the order enters the Catch block.
  • In the Catch block the Fail instruction makes the order leave the workflow. The Fail instruction can be parameterized to either stop an order or to make an order leave the workflow.
  • An order that enters the Catch block will not execute job3.

Use Case 4: Job error makes order leave workflow with successful history outcome

Similar to use case 3 in this scenario a job error is caught and is handled in a way that makes the order leave the workflow:

  • The History outcome is specified to be successful as a Try-Catch instruction is used to handle errors.
  • Notifications can optionally be sent.
  • User Interventions is not applicable.


Example for catching a job error with successful history outcome 
Try
    job1
    job2
Catch
    Finish
Catch-End
job3

Explanation:

  • if any of job1 or job2 in the Try block raises an error then the order enters the Catch block.
  • In the Catch block the Finish instruction makes the order leave the workflow.
  • An order that enters the Catch block will not execute job3.

Use Case 5: Job warning lets order continue

In this scenario job errors are considered being warnings based on a selection of job return codes. Such warnings do not require specific error handling, instead the order will continue in the workflow.

  • The History outcome is not determined: as the order continues in the workflow. The History outcome will be determined from later workflow instructions.
  • Notifications can optionally be sent.
  • User Interventions is not applicable.


Example for handling of job warnings 
job1 (return codes: 0=success, 1=warning, >1=error)
job2 (return codes: 0=success, 1=warning, >1=error)
job3 (return codes: 0=success, 1=warning, >1=error)

Explanation:

  • If any of job1, job2 or job3 completes with return code 1 this is considered a warning. Any other non-zero return codes are considered errors.
  • In case of job warnings the order continues with the next instruction in the workflow.
  • User Intervention is not applicable.

Resources



  • No labels