Concepts for jobs, job chains and orders

Introduction

The JobScheduler's unique job and order concept includes the organization of jobs into job chains and the use of dependencies.

Jobs are the basic unit for the processing of executable files (programs, scripts, commands etc.).
Job Chains can be seen as an assembly line on which a number of job nodes are passed sequentially.
Orders represent triggers that will cause a job chain to be started according to calendar events.

Jobs are the basic unit for the processing of executable files, shell scripts, commands and of job implementations based on the JobScheduler internal API.
Jobs can be executed independently from one another. However, job starts can also be made dependent on the execution result (success, failure, exit code) of preceding jobs.
Jobs can also be started according to the results of preprocessing operations if a monitor is specified for that operation.
Jobs can be executed in parallel by a configurable number of tasks.

Read more on the features of Job Objects in the job documentation.

Job chains can be seen as an assembly line on which multiple job nodes are passed, with each job making up one step in the processing of a chain.
Job chains allow the reuse of jobs in different job chains with different parameter sets.
Job chains allow dependencies to be mapped by, for example, causing processing to continue at different job nodes according to result returned from the processing of a job node.
Job chains enable complex workflow patterns such as Split & Sync: see Example showing the synchronization of multiple job chains
Nested job chains can be used to control and parallelize the execution of multiple job chains.

Orders are triggers that will cause a job chain to start. Jobs can be started by calendar events, file events and by programmatically created events.
Orders can be used with parameters that allow the same job chain to be used with different parameter sets.
Workflows are regulated by orders. An order can be thought of as a directive that is processed in a chain of jobs. An order is assigned to a job chain with an identifier which is valid for that particular job chain. The order also has a status that changes after the processing of each job node and can have a payload of parameters.
Orders are persistently stored during processing. If a job, job chain or order is stopped during processing and then restarted, it will be continued at exactly the point where it was stopped.

Read more on the features of Order objects in the order and job chain documentation.

Job Chains are either created using the JobScheduler Object Editor (JOE), or using API methods in individual programs:

The individual jobs in the job chain are created along with the job chain. Every position in the job chain is assigned a state and a job.
An Order is then created - i.e. a simple token that is assigned a state in a job chain (normally the beginning of a job chain). Optionally an order has a payload consisting of parameters that are processed by the jobs. When an order is added to the job chain, it is enqueued by JobScheduler according to the state of the order. The job assigned to this position then carries out the order. Additionally, each position in a job chain has a successor state and an error state. JobScheduler changes the state of an order after each job in the job chain has been processed. If the job step was successful, JobScheduler sets the successor state; otherwise it sets the error state.
The order then moves to another position in the job chain as defined by the new state.

Jobs within a job chain can be executed in multiple processes to handle parallel processing of orders.