We recommend using order jobs, i.e. one or more jobs in a job chain with multiple orders rather than multiple standalone jobs, (i.e. jobs that are started individually).
Overview
The advantages of order jobs are that these jobs and job chains:
- are independent of parameter values - only "What the job itself does" is implemented;
- are more generic, meaning that "What a job achieves" is determined by the order parameters;
- can be easily deployed between different environments, e.g. dev, test, prod
- can be more easily changed or modified, if required;
- can take account of dependencies between jobs and
- can handle errors more flexibly.
The last three advantages are described in more detail below.
Example
Consider the case of 700 servers, with 5 housekeeping jobs, e.g. backup, clean up, etc., on each server.
If you created individual jobs for this situation then this would require 700* 5 = 3500 jobs that would more or less be identical. The only difference between the jobs would be the parameters (or constants, hard coded in the jobs).
- Applying the order approach would require 5 jobs and one job chain. An order would be required for each server that would contain the parameters for all 5 jobs in the chain. This approach would decrease the complexity of the scheduling and would greatly simplify the change management for jobs.
In detail
The advantages of order jobs in job chains in comparison to standalone jobs are:
Job Dependencies
Job chains can be configured to take into account dependencies between jobs, so that, for example, one job might start exclusively if other jobs have successfully completed. Dependencies are clearly visible in the JobScheduler GUIs and one log file is generated per order. This covers all the jobs in the job chain.
Code Maintenance
Your might encounter the situation when jobs differ in their parameterization. When such jobs are executed in job chains and are started by orders containing different parameters then it is possible to configure a small number of order jobs to run in multiple job chains.
In this situation:
- if you had to modify a job script, then you just have to apply this to one job.
- if instead you had created a job for each set of parameters then code maintenance would create a considerable overhead.
Error Handling
Error handling in job chains is more flexible than with standalone jobs. There are several ways how to react when jobs in job chains terminate with an error:
- end the job chain
- start another job in the job chain
- repeat the job that terminated in error
suspend the order
Different methods of error handling can be specified for each node in a job chain. Whenever the job at the current job chain node terminates with an error then the order will either be forwarded to the node configured in the error state, will be suspended or will be restarted (setback).
A standalone job can be configured to re-run after the job has terminated with an error or to stop immediately. It cannot be restarted automatically until it has been manually unstopped.