Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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

...

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

Find more More explanations about workflow instructions used for error handling from can be found in the JS7 - How to catch job errors article.

Anchor
use_case_1
use_case_1
Use Case 1: Job error makes order stop

In this scenario an order stops subsequently to after 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 by subsequent User Intervention.
  • Notifications are created.
  • 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.
      • Child orders in Fork-Join and ForkList-Join instructions can be resumed within their branch.
    • 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 will indicate the failed outcome of order execution.
      • Child orders in Fork-Join and ForkList-Join instructions leave their branch with a failed outcome that is adopted by the parent order.

...

  • The History outcome is not determined as the order continues in the workflow. The History outcome will be determined from later by subsequent workflow instructions.
  • Notifications are created.
  • User Intervention is not applicable.

...

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

...

  • 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 waiting for User Intervention.
    • Consider Note that Try-Catch instructions can be nested, i.e. in a Catch block another Try-Catch instruction can be used for error handling.

...

  • 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.
    • If the above example is applied to child orders, for example in branches of Fork-Join and ForkList-Join instructions then the Fail instruction makes will make the child order leave the branch.
  • An order that enters the Catch block will not execute job3.

...

  • 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.
    • If the above example is applied to child orders, for example in branches of Fork-Join and ForkList-Join instructions then the Finish instruction makes instruction will make the child order leave the branch.
  • An order that enters the Catch block will not execute job3.

...

  • 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 the event of job warnings the order continues with the next instruction in the workflow.

...

For earlier JS7 releases Notifications are not sent in case the event of of job warnings.

Notification

For any above use case a A JS7 - Notification is created for all of the above use cases.

  • Notifications are visible from the JOC Cockpit user interface with in the Monitor->Notifications view.
  • Notifications can be configured to be forwarded:
    • by e-mail,
    • by writing to a log file,
    • by integration with a System Monitor or Message Queue (JMS).

...

  • The Notifications tab in the properties editor for of a job offers to overrule events allows events to be overruled when notifications are sent by mail:
    • Mail on: Users can select one or more of the events ERROR, WARNING, SUCCESS.
    • Mail To, Mail Cc, Mail Bcc: Users can specify recipients of e-mail notifications. An empty specification will prevent an e-mail from being sent.
  • The settings take precedence over general settings specified for JS7 - Notification.

...