Page History

...

In particular, the effect of the stop_on_error and on_error parameters is demonstrated along with the use of suspended orders and setbacks to retry running a job.

Downloads

• shell_error.zip - configuration files

Instructions

Behavior with stop_on_error="

...

no"

• Unzip all files in the download into the ./config/live folder of your JobScheduler installation.
• Open the JobScheduler Operating Center, JOC, in your browser using http://scheduler_host:scheduler_port
• Open the JOB CHAINS tab and enable Show orders.
• Find the job chain samples/shell_error/simple_error_chain.
• Find the order simple_error_order, open the order menu and choose Start order now.

The order will now go move through both nodes of the job chain. On the second node, an error will occur due to exit 5 being included in the job's shell script. If the email settings of your JobScheduler are configured correctly, you will now receive an error mail.

Click on the second node job (samples/shell_error/simple_chained_job2, colored red) to open the Job pane. You will see that the second job has the pending state. This means that he job can process further orders (although in this example, they will all fail as long as exit 5 is specified). The error has been blamed on the order and the order has been moved to the state which was configured as error_state for the step in which the error happened. In the example, this is suspended. The error_state can also be used to configure error handling jobs, it need not point to a final state of the job chain.

If you change the exit code from exit 5 to exit 0 and click on the order menu, you will see that you can either resume the order or reset it:

• resume will cause the order to rerun the second job,
• reset will allow the order to be re-run.

stop_on_error="no" is the default setting for jobs created with JOE and has the advantage that a job is not blocked for all orders if one order should fail due, for example, to a configuration error .

The error can also be blamed on the job, which will be described in the next section.

Behavior with stop_on_error="yes"

• Edit the job configuration file simple_chained_job2.job.xml
• If you have changed the exit code (which caused the error) to exit 0 change it back to exit 5 to simulate an error again
• Change stop_on_error="no" to stop_on_error="yes" and save
• Run the order again
• Look at the order history

Note that the job state of the second job is now stopped. This means that the job will no longer process any orders. The order simple_error_order is now enqueued before the job. Other orders running into this job will also be enqueued.

...

This example has used the stop_on_error="yes" to blame the error on the job. The error can also be blamed on the order, which will be described in the next section.

Behavior with stop_on_error="no"

• Edit the job configuration file simple_chained_job2.job.xml
• Change exit 0 (which caused the error) to exit 5 to simulate an error again
• Change stop_on_error="yes" to stop_on_error="no" and save
• Run the order again
• Look at the order history

This time, the order has ended in the error state and the job has not been stopped. The job can process further orders (although in this example, they will all fail as long as exit 5 is specified). The error has been blamed on the order and the order has been moved to the state which was configured as error_state for the state in which the error happened. The error_state can also be used to configure error handling jobs, it need not point to a final state of the job chain.stop_ on _error="no" is the default setting for jobs created with JOE and has the advantage that a job is not blocked for all orders if one order should fail due to a configuration error .

Suspending Orders

Another option in the event of an error is to suspend the order:

...