Platforms and Operating Systems
The JobScheduler JOC Cockpit user interface and JobScheduler Master run on Windows and Linux operating systems. The JobScheduler Universal Agent can be operated on any platform. Agentless Scheduling using SSH is available for the execution of jobs on any server.
For supported platforms see the article:
Database Management Systems
The JobScheduler uses a database to store the status of jobs, job chains and orders as well as job protocols and the job history. The database allows such information to be persistent, allowing, for example a job or order to be restored to its previous state after a JobScheduler restart or in the event of a failover.
The JobScheduler comes with the following user interfaces:
JOC Cockpit User Interface
which provides a web-based interface for starting and monitoring jobs, job chains and orders in real-time.
JOE - JobScheduler Object Editor
which is used to manage JobScheduler objects such as Jobs, Job Chains, Orders, Schedules etc.
JID - JobScheduler Information Dashboard (up to release 1.10)
which provides information about daily work plans - what will run today, what has been executed, what executions were late, what is scheduled for tomorrow etc.
The following programming interfaces are available:
Command Line Operation
The JobScheduler can be operated from the command line, e.g. by the PowerShell CLI, allowing a wide range of operations to be carried out by an external application. These include:
- checking the JobScheduler status,
- checking the status of jobs, job chains and orders,
- adding orders to job chains,
- adding events for Event Handling.
Time events are one way of starting jobs, job chains and orders, with Start Times being set for predefined points in time such as a time of day, weekday, day of month etc.
Job activities can also be limited to time-slots, i.e. jobs have to wait for a time-slot to be reached, e.g. between 8am and 11am.
Jobs, Job Chains and Orders
The JobScheduler's unique concept includes the use of jobs within job chains and 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.
- Languages that are supported by the Java javax.script package (ECMAscript compatible engines such as Rhino, Nashorn).
- Job and monitor scripts can be used to extend jobs and provide a lightweight solution for the individual control of processing behavior.
The JobScheduler comes with a number of methods for error handling. These include:
- stop a job: running orders have to wait for the job to become available
- suspend an order: the order waits to be resumed later on
- setback an order: make an order repeatedly try to continue processing after a predefined time interval
- make an order leave a job chain
- make an order continue processing with a specific job node for error handling
The JobScheduler event handling is a mechanism to implement complex dependencies between jobs or between jobs and external events.
High Availability & Fault Tolerance
The JobScheduler can be implemented to provide high availability and fault tolerance. A number of options are available:
- Passive Cluster includes the set-up of a Primary JobScheduler Master and redundant Backup JobScheduler Master.
- Active Cluster allows the execution of jobs on distributed server nodes with JobScheduler Masters.
- Master/Agent Resilience includes measures for reconciliation and recovery.
- Master/Agent Redundancy includes the use of clustered JobScheduler Master instances and Agent bundles.
- Agents are used in a Master / Agent Cluster and are controlled by a Master JobScheduler. They allow a simplified roll-out and do not require individual configuration or a database connection.
- Remote execution by SSH does not require a JobScheduler component on the remote server: instead an existing SSH server is used to create a secure shell and execute commands and programs.
Central configuration allows the efficient distribution of configuration files from a central source to distributed JobScheduler instances by a Supervisor JobScheduler.
The single point of configuration ensures accurate and punctual delivery of the configuration data to all instances.
Directory Monitoring and File Watching
The JobScheduler offers two methods with which files events can be used to start jobs and job chains automatically:
- Directory Monitoring is used to start jobs when change events such as the addition, modification or removal of files occur within a specified folder. Each event causes a job that can handle the file associated with the event to be executed.
- File Watching is used to start jobs and job chains when files arrive in a specified folder. For each incoming file an order is created that triggers a job chain. A file watcher is configurable for any number of directories.
- The JobScheduler Universal Agent can be used for Remote File Watching, i.e. the Agent monitors incoming files and triggers the start of a job chain with the JobScheduler Master.
- see Use Cases - File Watching
Managed File Transfer
The JobScheduler provides two methods for managing the transfer of files:
- YADE JITL job templates which come with the JobScheduler and
- the YADE Client CLI, a Command Line Interface for YADE that can be executed by shell jobs and independently from the JobScheduler.
Both methods make use of the YADE implementation that comes with a number of unique features, see YADE - Features
Resource Contention Management
Process classes and locks can be used to manage the use of resources such as databases or printers:
- limit the number of jobs that are running concurrently.
- specify remote JobScheduler Workload instances and Agents on which jobs should be executed.
- limit the number of jobs that access the same resources, e.g. databases, in parallel.
- allow mutual exclusive access, i.e. jobs wait without any consumption of CPU for a lock to be released.
The JobScheduler comes with a number of powerful interfaces that are targeted at the following scenarios:
- implementing jobs and monitors that can, for example, check execution results and decide on specific actions. Such implementations often make use of the API Interface to check and manipulate JobScheduler Objects.
- developing individual programs and complex jobs, for example, using the Java API Interface. These jobs can be used to manipulate JobScheduler objects - for example, to create and submit orders from an individual application.
The JobScheduler comes with its own mail client, which it can use to send notifying e-mails in the event of, for example, jobs ending in error.
The JobScheduler can be monitored by System Monitors such as HP OpenView®, Microsoft SCOM®, Nagios®, op5®, Opsview®, Zabbix® etc.
As System Monitors are restricted to checking the availability and performance of a monitored service the JobScheduler provides additional functions allowing System Monitors to report on individual job failure and recovery. The JobScheduler Monitoring Interface can be used with any System Monitor that provides a command line tool for passive checks.
Maintenance Window Management
Maintenance Window Management ensures that jobs are not executed within a given time slot. The JobScheduler supports a number of mechanisms to implement maintenance windows.
Migration and Integration
The JobScheduler provides a number of features to map the functionality of other job scheduling systems. While the JobScheduler does not include any built-in capabilities for automated migration from legacy workload automation products, the SOS provides Migration Services for a smooth transition.
There are integration scenarios that would allow JobScheduler to be operated with legacy scheduling products, e.g. by Integration.