Introduction
JS7 offers a number of strategies for error handling that are explained from in the matrix below matrix.
- Steps for error handling include:Error handling includes
- 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 Case | Job | Order | Order History | Notification | User Intervention |
---|
No. | On Error | On Warning | Stopped | Continued | Finished | Successful | Failed | Optional | Resume Order | Suspend Order | Cancel Order |
---|
Use Case 1 | yes | no | yes | no | no | - | - | yes | yes | yes | yes |
Use Case 2 | yes | no | no | yes | no | - | - | yes | - | - | - |
Use Case 3 | yes | no | no | no | yes | no | yes | yes | - | - | - |
Use Case 4 | yes | no | no | no | yes | yes | no | yes | - | - | - |
Use Case 5 | no | yes | no | yes | no | - | - | yes | - | - | - |
Use Cases
More explanations about workflow instructions used for error handling can be found in the JS7 - How to catch job errors article.
Use Case 1: Job error makes order stopIn 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 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.
Code Block |
---|
title | Example for default error handling |
---|
linenumbers | true |
---|
collapse | true |
---|
|
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.
Use Case 2: Job error lets order continueIn 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.
- User Interventions Intervention is not applicable.
Code Block |
---|
title | Example for catching a job error by use of an empty Catch block |
---|
linenumbers | true |
---|
collapse | true |
---|
|
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:
Display feature availability |
---|
|
Jira |
---|
server | SOS JIRA |
---|
columnIds | issuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution |
---|
columns | key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution |
---|
serverId | 6dc67751-9d67-34cd-985b-194a8cdc9602 |
---|
key | JS-2005 |
---|
|
For earlier JS7 releases a dummy job has to be added to the Catch block to force a successful outcome for the order.
Code Block |
---|
title | Example for catching a job error by use of a recovery job |
---|
linenumbers | true |
---|
collapse | true |
---|
|
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.
Use Case 3: Job error makes order leave the workflow with failed history outcomeIn 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 sentare created.
- User Interventions Intervention is not applicable.
Code Block |
---|
title | Example for catching a job error with failed history outcome |
---|
linenumbers | true |
---|
collapse | true |
---|
|
Try
job1
job2
Catch
FailFinish (fail and leave workflow)
Catch-End
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 Fail instruction Finish instruction makes the order leave the workflow. The Fail Finish instruction can be is parameterized to either stop an order or to make an order leave the workflowcreate 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:
Display feature availability |
---|
|
Jira |
---|
server | SOS JIRA |
---|
columnIds | issuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution |
---|
columns | key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution |
---|
serverId | 6dc67751-9d67-34cd-985b-194a8cdc9602 |
---|
key | JS-2014 |
---|
|
Use Case 4: Job error makes order leave workflow with successful history outcomeSimilar 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 sentare created.
- User Interventions Intervention is not applicable.
Code Block |
---|
title | Example for catching a job error with successful history outcome |
---|
linenumbers | true |
---|
collapse | true |
---|
|
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:
Display feature availability |
---|
|
Jira |
---|
server | SOS JIRA |
---|
columnIds | issuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution |
---|
columns | key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution |
---|
serverId | 6dc67751-9d67-34cd-985b-194a8cdc9602 |
---|
key | JS-2005 |
---|
|
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.
Use Case 5: Job warning lets order continueIn 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 sentare created.
- User Interventions Intervention is not applicable.
Code Block |
---|
title | Example for handling of job warnings |
---|
linenumbers | true |
---|
collapse | true |
---|
|
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) |
...
- 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.
Feature Status:
Display feature availability |
---|
|
...
Jira |
---|
server | SOS JIRA |
---|
columnIds | issuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution |
---|
columns | key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution |
---|
serverId | 6dc67751-9d67-34cd-985b-194a8cdc9602 |
---|
key | JOC-1350 |
---|
|
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