Concepts for jobs, job chains and orders

Introduction

The JobScheduler's unique concept includes the use of jobs within job chains with 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 based on 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.