The JS7 JobScheduler brings its wording for scheduling objects. Find explanations from the following sections about:
- the wording for components, objects and operations used with JS7,
- the mapping of terms used with the predecessor product JS1 (branch 1.x).
Terminology for Components used with JS7
A Controller knows what Workflows and Jobs to execute, when to execute and with which Agents to execute. A Controller receives the job-related inventory from JOC Cockpit and deploys this information to Agents which execute Workflows and Jobs on the respective servers. A Standalone Controller is a singe instance that orchestrates Agents.
|Controller Cluster||A Controller is clustered for high availability by two instances, one being active and one being in standby mode. A manual switch-over and an automated fail-over between instances can occur. For details see JS7 - Controller Cluster.|
|Agent||Standalone Agent||Agents execute Jobs that call executable files and commands on the Agent's server. Agents receive the information what Jobs to start and when to start from a Controller and report back execution results and log output to the Controller. Agents can act autonomously without a Controller being connected at the point in time of job execution. Standalone Agents act independently from each other.|
|Agent Cluster, Subagent||Agent instances that are clustered for high availability and for performance are called Subagents. If a Subagent fails in an active-passive Cluster then automated fail-over takes place. In an active-active Cluster a number of Subagents run Tasks for the same applications in parallel and can replace each other. A Cluster is a logical layer that allows to select any number of Subagents for Task execution in fixed-priority mode or in round-robin mode. Subagents can participate in any number of Clusters. For details see JS7 - Agent Cluster.|
|Director Agent||Agent Clusters work autonomously, they include primary and secondary Director Agent instances that act as a passive Cluster and that implement automated fail-over. Director Agents communicate with a Controller and orchestrate Subagents in the Cluster.|
|JOC Cockpit||Standalone |
|JOC Cockpit is the user interface to manage the job-related inventory and to monitor & control Workflow execution with Controllers and Agents. A Standalone JOC Cockpit is a single instance that can be used to manage one or more Controllers.|
|JOC Cockpit Cluster|
A number of JOC Cockpit instances act in a passive cluster for high availability that allows manual switch-over and automated fail-over between instances. For details see JS7 - JOC Cockpit Cluster.
Terminology for Objects used with JS7
Jobs come in two flavors: Shell Jobs specify job scripts that are executed for an operating system shell, JVM Jobs specify use of a Java class, see JS7 - Job Templates.
For both usages the Job defines what should be executed. At the point in time when a Job is started it is called a running Task, i.e. the instance of a Job.
A Job specifies what is executed on a given machine, for example, the commands in a shell of the operating system. Jobs are stateless objects, Tasks are stateful objects that can be started, killed etc.
For details see JS7 - Job Instruction.
|Task||The instance of a Job that is executed. A Job can run in a number of parallel Tasks.|
|Process||The operating system view of a Task. In addition, Tasks can have child processes.|
|Return Code||A summary term for the Exit Code of a Process and the Return Code provided by Jobs running in a JVM.|
|Exit Code||An Exit Code is returned by a terminating Process. This includes Exit Codes that are returned by shell Jobs. JVM Jobs do not return Exit Codes as their Tasks can be re-used. Instead, JVM Jobs complete with a Return Code.|
A Workflow is started by an Order that passes the Nodes and Instructions included with the Workflow. Any number of Orders can execute the same Workflow in parallel instances running independently of each other.
The succession of Instructions in a Workflow implements a Workflow Pattern, for example a Sequence. However, the most simple Workflow Pattern can include execution of a single Job.
Frequently used synonyms include the terms Job Net, Job Stream. For details see JS7 - Workflows.
|Instruction||Instructions implement Workflow Patterns such as Fork/Join, a Sequence etc.. Instructions rule job dependencies, see JS7 - Workflow Instructions.|
|Node||The position of an Instruction, for example, for the execution of a Job in a Workflow. Nodes are assigned labels that allow recognition of steps in a Workflow.|
|Workflow Pattern||A number of Nodes that are implemented by Instructions in a Workflow. Instructions include, for example, execution of a Job or forking execution according to a Workflow Pattern. For details see JS7 - Workflow Patterns.|
|Sequence||A Workflow Pattern that implements sequential execution of Instructions in a Workflow.|
Orders represent triggers for execution of Workflows.
For details see JS7 - Orders.
|Timed Order||Such Orders are automatically created by a Schedule that determines when to run the Order and what parameterization to be applied.|
|Ad hoc Order||Such Orders are added by users or from external applications on-the-fly. Schedules are not involved.|
|File Order||An Order that is represented by an incoming file, see JS7 - File Watching.|
Orders are stateful objects that pass a number of State Transitions during their lifetime. States include, for example, being scheduled for later execution, waiting for resources, running, failed, etc.
Orders are subject to State Transitions when moving from one State to the next. JS7 implements a Finite-state Machine with non-deterministic transitions that can be considered a Directed Acyclic Graph.
State Transitions are signaled by Events. For details see JS7 - Order State Transitions.
|Event||Events signal State Transitions of Orders. They are used, for example, to automatically update information in the JOC Cockpit GUI about Orders running, waiting, having failed, etc.|
|File Order Source||The scheduling object that defines a source for File Orders, for example, the directory that should be watched for incoming files. For details see JS7 - File Watching.|
Resource Locks implement mutual exclusion and can be used to limit parallelism of Jobs. For details see JS7 - Resource Locks.
|Job Resource||Job Resources are used to propagate variables and to inject environment variables to shell Jobs. They are a flexible means for parameterizing Workflows and Jobs. For details see JS7 - Job Resources.|
|Notice Board||Notice Boards implement job dependencies, for example, to make a Job wait for another Job in a different Workflow. For details see JS7 - Notice Boards.|
|Script Include||Script Includes are re-usable pieces of shell code that can be added to Job scripts. For details see JS7 - Script Includes.|
Calendars determine the days that are considered by Schedules when creating Orders. For example, a business day Calendar can specify Monday to Friday as possible days for Workflow execution. A Schedule that is assigned this Calendar can further restrict execution to more specific days. For details see JS7 - Calendars.
Schedules make use of Calendars that specify possible days for Workflow execution. Schedules can create Orders for any days of the assigned Calendar and they can further restrict the days on which Orders are created.:
For details see JS7 - Schedules.
Terminology for Operations used with JS7
Deployment includes forwarding objects to Controllers and Agents that store deployed objects with their respective journal. This applies to objects such as Workflows, Job Resources, Resource Locks etc. For details see JS7 - Deployment.
|Revoke||Users can Revoke a Deployment which forces deletion of the respective scheduling object from Controllers and Agents.|
Submission includes adding Orders to Controllers and Agents. Submitted Orders can be cancelled or suspended.. For details see JS7 - Daily Plan.
|Rollout||Rollout||Scheduling objects are rolled out to separate environments, for example for a sequence of dev -> test -> prod environments. For details see JS7 - Rollout of Scheduling Objects.|
Mapping of the Terminology used for Objects with JS1
|Job||Job||Jobs in JS1 can be used standalone and in Job Chains. In JS7 any Jobs are used in Workflows, including use of a Workflow with a single Job.||Meaning changed|
|Job Chain||Workflow||Any Job Chain is considered a Workflow. In JS1 Job Chains are limited to forward-dependencies, JS7 adds backward-dependencies to Workflows.||Meaning extended|
Order is the summary term for any Order instance, such as Permanent Orders, Ad Hoc Orders, File Orders. This meaning is mapped accordingly to JS1 with the one exception being that Permanent Orders are mapped to Timed Orders and are intended for one-time execution.
JS1 Orders recalculate the next start time after each execution. JS7 Orders are created for one-time execution only. Instead, JS7 Schedules create individual Orders for any scheduled dates.
|Schedule||Schedule||JS1 Schedules are common rules for start-times that are applied by a number of Jobs or Orders. JS7 Schedules can create a number of Orders for the same execution date.||Meaning extended|
|Task||Task||The instance of a Job that is executed. The meaning of this term is the same for JS1 and JS7.||Meaning unchanged|
|Exit Code||Exit Code||JS1 Exit Codes map to JS7 Exit Codes.||Meaning unchanged|
|Return Code||Return Code||A summary term for the Exit Code of a process and the Return Code provided by API Jobs. JS1 Return Codes map to JS7 Return Codes.||Meaning unchanged|
|File Order||File Order||An Order that is represented by a file. The meaning of this term is the same for JS1 and JS7.||Meaning unchanged|
|Node||Node||A Node indicates the position of a Job in a Job Chain. The meaning is extended with JS7 Nodes which, in addition to Jobs, know a number of Instructions that are assigned Nodes.||Meaning extended|
|State||Label||JS1 States are assigned the Nodes in a Job Chain. This maps to use of labels with Nodes in JS7 Workflows.||Meaning changed|