We always recommend using order jobs (i.e. one or more jobs in a job chain) together with multiple orders rather than multiple standalone jobs (i.e. jobs being started directly).
Overview
The advantages of order jobs are that the jobs and job chains:
- can be independent of the parameter values - only "What the job itself does" is implemented;
- are more or less generic, meaning that "What a job achieves" is determined by the order parameters;
- can be easily transported 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.
These last three points 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 create jobs for this situation, you need 700* 5 = 3500 jobs, which would be more or less identical. The only difference between the jobs would be the parameters (or constants, hard coded in the jobs).
- Using the order approach, you would need 5 jobs and one job chain. An order would be needed for each server, which would contain the parameters for all 5 jobs in the chain. This approach would decrease the complexity of the scheduling and greatly simplify making changes to the jobs.
In detail....
The advantages of order jobs in job chains over standalone jobs are:
Dependencies between Jobs
Job chains can be configured to take account of dependencies between jobs, so that, for example, one job may only start if other jobs have successfully finished. Dependencies can be clearly seen and Only one log is generated per order. This covers all the jobs in the job chain.
Code Maintenance
Often you have the situation where jobs differ only in their parameterisation. When such jobs are run in job chains, and started by orders containing the different parameters, it is often possible to configure a small number of order jobs to run in multiple job chains.
In this situation:
- If you have to change something in a job script, then you only have to do it in one job.
- If, instead, you had created a job for each set of parameters then the code maintenance would be considerably more involved.
Error handling
The error handling in job chains is more flexible than with standalone jobs. There are several possible ways to react when jobs in job chains end in error:
- End the job chain
- Start another job in the job chain
- Repeat the job that ended in error
- Suspend the order
A different method of error handling can be specified for each node in a job chain. Whenever the job at the current job chain node ends in error, the order will be either be forwarded to the node configured in the error state, suspended or given a scheduled restart.
A standalone job can be configured to rerun after a job has ended in error or to stop immediately. It cannot be restarted automatically until it has been manually unstopped.