Chains

Chains are the means by which you can implement dependency scheduling, in which jobs are started depending on the outcomes of one or more previous jobs. A chain consists of multiple steps combined using dependency rules. The dependency rules define the conditions that can be used to start or stop a task or the chain itself. Conditions can include the success, failure, or completion- or exit-codes of previous tasks. Logical expressions, such as AND/OR, can be used in the conditions. In a sense, a chain resembles a decision tree, with many possible paths for selecting which tasks run and when.

In its simplest form, a chain consists of two or more Scheduler program objects (programs) that are linked together for a single, combined objective. An example of a chain might be "run program A and then program B, but only run program C if programs A and B complete successfully, otherwise wait an hour and then run program D."

A typical situation where you might want to create a chain is to combine the different programs necessary for a successful financial transaction, such as validating and approving a loan application and then funding the loan.

A Scheduler job can point to a chain instead of pointing to a single program object. The job then serves to start the chain. This job is referred to as the chain job. More than one chain job can point to the same chain, and more than one of these jobs can run simultaneously, thereby creating multiple instances of the same chain, each at a different point of progress in the chain.

Each position within a chain is referred to as a step. Typically, after an initial set of chain steps has started, the execution of successive steps depends on the completion of one or more previous steps. Each step can point to one of the following:

• A program object (program)

  The program can run a database program unit (such as a stored procedure or PL/SQL anonymous block), or it can run a local or remote external executable. For a remote external executable, you designate the destination host.

• Another chain (a nested chain)

  Chains can be nested to any level.

• An event schedule or inline event

  A step that points to an event schedule or that has an inline event specification waits until the specified event is raised. When the event occurs, the step completes, and steps that are dependent on the event step can run. A common example of an event in a chain is a user intervention, such an approval or rejection.

Multiple steps in the chain can invoke the same program or nested chain.

Figure 26-2 shows a chain with multiple branches. In this chain, rules could have been defined as follows:

• If Step 1 completes successfully, start Step 2.

• If Step 1 fails with error code 20100, start Step 3.

• If Step 1 fails with any other error code, end the chain.

Additional rules would govern the running of steps 4, 5, 6, and 7.

While a job pointing to a chain is running, the current state of all steps of the running chain can be monitored. For every step, the Scheduler creates a step job with the same job name and owner as the chain job. Each step job additionally has a step job subname to uniquely identify it. The step job subname is included as the JOB_SUBNAME column in the views *_SCHEDULER_RUNNING_JOBS, *_SCHEDULER_JOB_LOG, and *_SCHEDULER_JOB_RUN_DETAILS, and as the STEP_JOB_SUBNAME column in the *_SCHEDULER_RUNNING_CHAINS views.

See "Using Chains" for more information.