ProActive Job Planner

API documentation

Scheduler REST    Scheduler GraphQL   Scheduler CLI   Scheduler Java   Workflow Creation Java   Python Client   Jupyter Kernel .NET Client

The following terms are used throughout the documentation:

To create new calendar definition, use the Job Planner Portal, Calendar Definition page. When clicking the "+" button, a calendar definition is created with default parameters.

Click on a Calendar Definition to modify it. Its fields will be visible on the main panel ("Calendar Definition"). The name of the Calendar Definition must be unique in a bucket. The cron expression can be set using the widget, or manually with the "Advanced" tab. The resulting cron expression is shown under the widget.

Changes made in the Calendar Definition panel will be automatically saved. When a calendar definition is selected, it can be removed by clicking on the trash button.

Once a workflow has been published to the Catalog, it can be planned with the Job Planner Portal, Calendar Association page. On the top of this page there is a dashboard of counters that display statistics on the status of planned jobs (total, active, deactivated and failed) to help users gain a better understanding of the operational view of the platform. As a result, when an association is added / removed / deactivated / failed, the corresponding counter is updated accordingly as shown in the screenshot below.

To plan a workflow, first select a calendar from the list on the left, then click on the add button to browse the catalog for the workflow to be scheduled. When creating an association, workflow variables can be given specific values, which may differ from the default values stored in the catalog for that workflow. Thus, a single workflow can be scheduled many times for the same calendar but with different input parameters.

The created association can be deactivated by clicking on the unlink button. This means that the workflows won’t be submitted for the next calendar occurrences, but it will still be visible on the Execution Planning and the Gantt chart. You can reactivate it with the link button. On the left panel, you can easily see the number of associated workflows to each calendar, and how many of them are activated or failed.

It is possible to display the associations as icons or as list by switching between the two buttons next to the search field.

When selecting a calendar with associated workflows, it is possible to filter the associations within this calendar by workflow name, bucket name, username, status, project name, id, description, variables(name and value), and generic info(value and name).

This filtering can also be applied in the Calendars section on the left. By applying this filtering, it will filter both calendars and associated workflows.

An advanced filtering is available by clicking on the filter icon.

Advanced filtering will update the associations to match the filters but also the calendars and the statistics on the status of planned jobs at the top of the page.

To reset the filters, you have two options: you can click on the "Clear icon" located next to the filter pills, or you can use the "Clear button" within the advanced filtering form, as depicted in the second screenshot above

This page can also be opened when clicking on the "plan" button on the Studio or the Scheduler Portal.

There are 3 different tabs for the planning visualization:

If a calendar has no association, you can still select it and see its recurrence on the Execution Planning panel. If nothing is displayed, it means the selected Calendar Definitions have no recurrence on the selected period.

You can also use the Gantt chart to visualize the executions:

In addition to the Execution Planning panel, the Gantt chart allows you to see the past job history, the current one being executed, as well as the future ones, all in a comprehensive interactive view. In this view, you will easily see the potential difference between the Planned Submission time and the Actual Start Time of the Jobs. You will also get estimations of the Finished Time, taking into account the Actual Start Time. Moreover, you can visualize the Job that stayed PENDING for some time (in Yellow), as well as the Jobs that had issues and got KILLED, CANCELLED, or FAILED (in red).

The planned jobs (in orange) are on the row just above the actual jobs so that you can easily compare what was planned and what actually executed. Please refer to the chart legend (Open legend button) for a complete definition of the colors and patterns used in the Gantt chart.

The length of the displayed planned jobs can be:

If a job has been PENDING before starting, depending on the scale you have selected, you can see a yellow part on the displayed job. This corresponds to the time the job was PENDING and helps to highlight a resource problem.

You can see more information jobs in the tooltips, when passing your mouse over a specific job:

Depending on the status of the job, the information won’t be the same. For example, if the job is RUNNING or STALLED, Actual finish time will be replaced by Planned finish time: the time when the job should finish, depending on when it started or how long it has been delayed.

The "Save Gantt" button will take a screenshot of the visible part of the Gantt chart. Like for Gantt chart loading, it might take a while if there are too many events. You can also chose a smaller scale and select only the calendars you need.

The description allows users who are not familiar with cron expressions to provide a humain-readable description to know when it occurs. It might also be used for other purpose, for example saying when is the Calendar Definition used.

The aim of the time zone is to make the user able to select a specific time for his future scheduled jobs depending on the region. By default, it is set according to the client location. The server time zone is always displayed on the top right corner. It indicates the time of the machine where ProActive instance is running. To simplify the process of selecting a time zone, the time zone dropdown now features a search field. Users can enter a value into this field to filter and narrow down the list of available options.

The aim of the cron expression is to launch the planned workflow according to the cron syntax. One can see the cron expression "0 0 9 ? * MON-FRI *", which follows the quartz cron expression syntax explained in the Quartz Cron Expression Syntax section. The cron expression in this example executes at 9:00 AM on working days (Monday to Friday).

The purpose of the inclusion calendar section is to use an ICS file to specify a workflow launching policies during calendar events. For instance automatically submit a worklfow at event start. Given an event, a predefined action will be applied on the workflow execution.

The purpose of the exclusion calendar is to use an ICS file to prevent workflows to be executed during a calendar event. Given an event, a predefined action will be applied on the workflow execution.

If an inclusion or exclusion calendar is not retrievable, it is blocking the Workflow submission. An inclusion or exclusion calendar can become not retrievable if it cannot be downloaded from its URL and the Job Planner cache doesn’t hold a copy.

This configuration controls how the Job Planner reacts when it detects that one or more executions have been missed for a given association. For instance, if the server is down for a period of time, the Job Planner won’t be able to submit Workflows during this interval. Two properties are used to define how the Job Planner reacts to this situation.

True by default, this option tells the Job Planner to submit a new execution if it detects that previous executions have been missed. It is equivalent to say that the submission has been delayed and thus a Delayed submission executing notification will be triggered for all users subscribed to this event. If set to false, the Job Planner will not submit a new execution.

This property, when greater than zero, allows the job planner to submit a missed execution within a given time window in milliseconds. If the job planner is unable to submit the missed execution after the configured delay, it will be skipped until the next calendar occurrence. By default, the skipped execution window is disabled : -1.

This feature enables to specify to the Job Planner what should be done when a planned execution must occur but the previous one is still executing.

The Job Planner can either remove (default) or postpone the submission.

With pa.on_going_job.cancel_execution=true (default), when a past submission of the same calendar association is still ongoing (job is not finished), the Job Planner will decide to skip submission until the next calendar occurrence.

In such case, a Submission canceled notification will be triggered to users subscribed to this event.

If enabled pa.on_going_job.postponed_execution=true, when a past submission of the same calendar association is still ongoing (job is not finished), the Job Planner will decide to postpone submission until the previous job terminates its execution.

In such case we can expect two notifications:

This feature defines the behavior of the Job Planner when the previous execution for a planned workflow has errors. By default, it will continue to submit according to the calendar.

If set to true, the Calendar Association will be set to FAILED and Job Planner will stop submitting until the user manually reactivates the association.

In such case, an Association failed notification will be triggered to users subscribed to this event.

If a workflow or a calendar cannot be retrieved by the Job Planner from the catalog, the association will be set to FAILED and will require manual reactivation for the submissions to restart.

In such case, an Association failed notification will be triggered to users subscribed to this event.

RBAC, or Role Based Access Control, represents a control model for a system in which each access decision is based on the role to which the user is associated. In the Job-Planner, RBAC operations are only performed by Job-Planner admins or associations' owners. RBAC operations can be distinguished in two types:

Both types of authorizations can be assigned for either a specific user (using her/his username) or a user group (that contains multiple users). Only one authorization can be assigned to a username or a user group for each type of RBAC operation. However, the user can eventually have multiple authorizations due to a mix of both types of RBAC operations. Furthermore, the created authorizations can be modified or deleted.

An authorization gives the specified user(s) some access permission to the specific association(s). We provide four authorization levels:

Since each user might belong to multiple user groups, a user could have multiple authorizations over an association or a group of them due to his/her username or user group(s) authorizations. In such case, the resulting access type will be calculated as follows:

Activeeon SAS, © 2007-2019. All Rights Reserved.

For more information, please contact contact@activeeon.com.