Table of Contents

Introduction

This example configures uses a simple job chain which starts shell jobs and shows what happens to demonstrate the different behaviors that can be configured for JobScheduler if an error occurs in one of the jobs.

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="yes"

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

...

• (optional) open the job chain menu (right click over the 'simple_error_chain' chain) and choose add order (leave everything empty) to add another order to the job chain which will also be enqueued at the second job.
• (optional) click on the job and choose unstop from the job menu which will appear on the right side of the interface. This will cause the job to retry processing the orders but as the error remains, the job will be stopped again.
• Edit the job configuration file simple_chained_job2.job.xml
  (Edit the file by either opening it in a code editor or using JOE - JobScheduler Object Editor.  Note that the job configuration can be read in JOC - but not edited - by opening the job context menu and selecting Show configuration. )

• Change the exit 5 (which caused the error) to exit 0 and save the change.

Now click on  in  the Job Menu in JOE's Job Tab to unstop the job, which will take on the status pending. The next scheduled start for the order will be shown in green in the Job Chain tab.

Once the JobScheduler has noticed the change in the configuration file, it will update the job definition and unstop the job automatically. The order(s) will then be able to run successfully through the job.

• Click on the job chain and enable then Show order history on the right side of the interface

In the order history, you will see, that processing of the order has ended in the success state.

In this example we blamed 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:.

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
• On non-Windows systems wait 60s for the JobScheduler to notice the change (or check incl. hot folders and press update, if your version of the interface supports this feature)
• 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 in this exampleas 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 << Text corrected up to here >>

Another option is to suspend the order:

...

When the error now occurs, the order will be put back into the queue of the second job but it will be suspended. This means that the order will not run again, until somebody manually chooses "reset" "resume" from the order menu.

• Fix the job - i.e. change exit 5 to exit 0
• Choose resume from the JOC's order menu

Retry using "setback"

Another option is to configure automatic retries using "setback":

...