AX2524

About Scheduler

This section contains conceptual information about the Scheduler feature in Axiom Software.

Scheduler jobs and tasks

The primary unit of Scheduler processing is a job. Each Scheduler job can contain one or more tasks to be performed as part of that job.

Each Scheduler job defines the following basic properties:

The tasks to perform for the job and the properties of those tasks
The schedule of the job, including recurrence (if any)
The priority of the job
The notification options for the job

The tasks define the actual activities to be performed by the job, such as importing data or processing plan files. Some Scheduler tasks correspond to existing features that can also be processed manually (such as Process Plan Files), while other tasks are Scheduler-specific and can only be processed via Scheduler. Each task has a unique set of options that are specific to that task and to the activity to be performed. For more information on the available task types, see Scheduler tasks.

The tasks in a job can be processed sequentially or concurrently as appropriate. Tasks can be dependent on other tasks in the job as needed—for example, you can configure a job so that if a task fails, the job stops and does not process the next task. Tasks can also be processed iteratively, to perform the same task repeatedly over a defined set of values.

The Scheduler jobs in your system fall into the following basic categories:

Client-created: You can create Scheduler jobs as needed to perform tasks in your system.
System jobs: Axiom Software provides a set of system jobs to perform necessary system tasks.
Product-controlled: When a product is installed, it may include one or more Scheduler jobs to support the use of that product. Generally speaking, these jobs should not be changed unless the product documentation says customization is allowed, or as advised by Axiom Support.

How Scheduler jobs are run

Once a Scheduler job has been created, it can be run using any of the following options:

The job can be scheduled for execution at a future date and time using a scheduling rule. Scheduling rules can be one-time only, or recurring.
The job can be run "one time" manually as needed through Scheduler.
The job can be triggered for execution using an event handler. This allows Scheduler jobs to be triggered in various ways, such as by clicking a button in an Axiom form.

Scheduler jobs are processed by one or more servers running the Scheduler service. For Cloud Service systems, the Scheduler service is part of your cloud system and managed by Axiom Support. For on-premise systemsAxiom Software systems that are installed on the client's premises. All servers and technical requirements are managed by the client., the Scheduler service is installed on one or more servers in your environment. The Scheduler service polls the Axiom Application Server periodically to check for any jobs that are ready to be run. Eligible jobs are then executed on the server, based on their processing priority.

When a job is executed by Scheduler, it is run using a particular user identity. In order for a job to be executed successfully, the user must be an active user defined in Axiom Software security, and the user must have the appropriate security permissions to perform the tasks in the job. The user identity for a job is determined as follows:

If a job is a system job, then it is run as the system-managed identity of System instead of a user identity.
If a job is run by using Run Now, then it is run as the user who placed the job on the schedule.
If a job is run by an active scheduling rule, then it is run as the job owner. The job owner is the user who last saved the job.
If a job is run via an event handler, then the job may be run as either the job owner, or the job requester (the user who raised the event).

System jobs

System jobs are automatically created by Axiom Software to support necessary system functionality. Some system jobs are created as part of the initial installation and are intended to run on an ongoing basis, while other system jobs are created on-demand in response to system events. Only administrators can edit these system jobs.

System jobs have two defining characteristics:

System jobs are run using the system-managed identity of System instead of a user identity. The System identity has full rights to the system as necessary to perform system tasks.
System jobs are run by the default System Scheduler service. For on-premise systemsAxiom Software systems that are installed on the client's premises. All servers and technical requirements are managed by the client., this service is created and started automatically on the Axiom Application Server, and does not require a separate installation. This service is exclusively for running system jobs.

Cloud Service systems may or may not have a separate System Scheduler service, depending on the system configuration (as determined by Axiom Support). If your cloud system does not have a System Scheduler service, then your system jobs are run using the available Scheduler services for the cloud system.

In the Scheduler dialog (Desktop Client), the System Scheduler service is listed on the Servers tab using the following naming convention: <ServerName>-System.

If necessary, a product-controlled or client-created job can be flagged as a system job, so that it can be run using the System identity instead of a user identity. To designate a job as a system job, enable Mark as System Job in the General job properties. The following rules apply to manually-created system jobs:

Only system administrators can designate a job as a system job.
The job cannot contain any tasks that are designated as “non-system” tasks. Non-system tasks are any tasks that might involve spreadsheet processing, such as Process Plan Files.

Processing priority for scheduled jobs

Once a job reaches its start time, it is eligible to be processed by Scheduler and joins the processing queue. For scheduled jobs, the start time is based on the scheduling rule that placed it on the schedule. For other jobs, the start time is the time that the job was placed on the schedule using Run Once or triggered by an event handler.

Each Scheduler service has a configured number of threads that are used to process jobs. As a Scheduler thread becomes available, it takes the next job in the processing queue. The priority of jobs in the processing queue is determined by the combination of the job's priority category, and its Priority Elevation setting.

Each job has a priority category, based on how the job execution was initiated. The priority categories are as follows:

Manual: The job was executed manually.
Event Handler: The job was executed by a Scheduler event handler.
Scheduled Job: The scheduled instance of the job results from an active scheduling rule.
Subordinate Job: The job was generated as a subordinate job, from a currently executing job.

Manual jobs are highest priority and are processed first, and subordinate jobs are lowest priority and are processed last. Within each category, jobs are processed according to their Priority Elevation setting.

For example, imagine that Scheduler has 2 available threads and the following jobs are eligible to be processed:

Job	Priority Category	Priority Elevation
A	Manual	Default
B	Event Handler	Default
C	Scheduled	Default
D	Scheduled	Elevated

Scheduler will execute jobs A and B first, because those are the highest priority jobs based on their priority category.
When the next thread becomes available, Scheduler will execute job D. Although job C may have entered the queue first, and the two jobs have the same priority category, job D's priority elevation is set to Elevated so it takes precedence within the category. If instead both jobs were set to Default, then job C would be executed first if it entered the queue before job D.
When the next thread becomes available, Scheduler will execute job C.

NOTE: If a job's Priority Elevation is set to Interrupt, then it is run as soon as it is eligible, regardless of its priority category and regardless of whether any Scheduler threads are currently available to process the job. If no Scheduler threads are available, a new one is created to process the job, even if this temporarily exceeds the number of configured threads for the server.