| Table of Contents | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
We always recommend using order jobs (i, 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)individually.
Overview
The advantages of order jobs are that the these jobs and job chains:
- can be are 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 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. These
The last three
...
advantages are described in more detail below.
Example
Consider the case of 700 Serversservers, 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 Using the order approach, you would need 5 jobs and one job chain. An order would be needed required for each server , which that would contain the parameters for all 5 jobs in the chain. This This approach would decrease the complexity of the scheduling and would greatly simplify making changes to the change management for jobs.
In detail
...
The advantages of order jobs in job chains over 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
...
Code Maintenance
...
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 parameterisation. 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 have had to change something in modify a job script, then you only just have to do it in apply this to one job.
- If, instead, you had created a job for each set of parameters then the code maintenance would be considerably more involvedcreate some considerabe 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 ended terminated in error
Suspend the order
No Format 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.
...
Different methods of error handling can be specified for each node in a job chain. Whenever the job at the current job chain node termnates with an error then the order will either be forwarded to the node configured in the error state, will be suspended or will be restared (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.
...