Page History

...

Now click on  in  the Job Menu in JOC'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 then Show order history on the right side of the interface

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

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.

...

• 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

...

• First of all, ensure that stop_on_error is set for both jobs to "no"
• Then edit the job chain configuration file simple_error_chain.job_chain.xml:
  • On the next job_chain_node add a new on_error="suspend" attribute and save
• Run the order again
• When the error now occurs, the order will be put back into the order queue of the second job but it will be suspended.
  This means that the order will not run again, until somebody manually chooses  "resume" from the order menu.
• Fix the job - i.e. change exit 5 to exit 0
• Choose "resume" from JOC's order menu

Retry using "setback"

Alternative Example:

Note that we also have a dedicated example, showing the use of setbacks: How to use setbacks to make a job retry in the event an error

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

...