Introduction

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

• Steps for error handling include:
  • JS7 - How to detect job errors and warnings
  • JS7 - How to handle job errors:
    • deciding if a job error can be handled automatically by making:
      • an order continue in the workflow,
      • an order leave the workflow.
    • deciding if a job error requires user intervention.
  • JS7 - How to handle job warnings
• A JS7 - Notification will be created in the event of job errors and warnings.

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

Use Cases

...

Use Cases

More explanations about workflow instructions used for error handling 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 can optionally be sentare 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 Instructionworkflow 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 outcome 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.

job1
job2
job3

...

• 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.

Anchor
use_case_2 use_case_2

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 by subsequent workflow instructions.
• Notifications can optionally be sentare created.
• No User Interventions Intervention is appliednot applicable.

Try
    job1
    job2
Catch
Catch-End
job3

...

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

Feature Status:

For earlier JS7 releases a dummy job has to be added to the Catch block to force a successful outcome for the order.

Try
    job1
    job2
Catch
    job2a
Catch-End
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.

Anchor
use_case_3 use_case_3

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 are created.
• User Intervention is not applicable.

Try
    job1
    job2
Catch
    Finish (fail and 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 Finish instruction makes the order leave the workflow. The Finish instruction is parameterized to create a successful or unsuccessful History outcome when the order leaves 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 will make the child order leave the branch.
• An order that enters the Catch block will not execute job3.

Feature Status:

Anchor
use_case_4 use_case_4

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 are created.
• User Intervention is not applicable.

Try
    job1
    job2
Catch
    Finish (succeed and 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 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 will make the child order leave the branch.
• An order that enters the Catch block will not execute job3.

Feature Status:

For earlier JS7 releases users have to add a dummy job before the Finish instruction that guarantees successful execution in order to force a successful History outcome.

Anchor
use_case_5 use_case_5

Use Case 5: Job warning lets order continue

In this scenario job errors are considered 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 are created.
• User Intervention is not applicable.

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

Feature Status:

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

Notification

A JS7 - Notification is created for all of the above use cases.

• Notifications are visible from the JOC Cockpit user interface 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 Monitor->Notifications view displays errors and warnings like this:

Image Added

Jobs can be exempted from Notifications and they can modify notification settings:

• The Notifications tab in the properties editor of a job 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.
  
  

Image Added

Resources

• JS7 - How to detect job errors and warnings
• JS7 - How to handle job errors
  • JS7 - How to catch job errors
• JS7 - How to handle job warnings

x

xx

Resources

...