Contents

Scheduler Support

Scheduler is a core functionality of Jira, and allows you to schedule repetitive jobs either at a regular interval (for example 5 minutes) or based on some CRON expression. This is a powerful functionality, and SIL™ makes it even more powerful.Our scheduler support adds routines to schedule jobs at interval or based on cron, and also allows you to create 'at' jobs (for instance jobs that run at a specified time).Support for this was added first in SIL Engine™ 3.0.8 version but jobs were not made persistent - they didn't survive Jira restarts. We added this behavior in SIL Engine™ 4.0; it is a major change you requested and we felt obliged to implement. And because this mechanism is more powerful than the old services one, we replaced completely the services with this one.

You may use the scheduling routines from any app supporting the SIL language.

The scheduled scripts run with no issue context and with no user. If you want to impersonate a user or run on some privileged account, use in the script the runAs routine. It should be noted also that minimal amount of time for interval based schedule routines is 1s.

A user interface for scheduling jobs is provided by the Power Scripts™ for Jira app; however, this handy tool is not in the scope of SIL Engine™.

Routines

The app defines just the routines that help you deal with the scheduled jobs:

Changes in 4.0

We improved this area a lot:

1. Starting with SIL Engine™ 4.0, the jobs are persistent and survive Jira restarts.
2. Old services are now removed. Scheduler is the only one that provides job scheduling now. Jobs previously defined over services will be moved on scheduler.
3. Keys of the scheduled jobs have changed, and previous rules are not in place.
4. Jobs were made cluster-aware, and we ensure now that a job is run just once in that cluster.
5. Jobs do not preserve uniqueness based on path+arguments anymore. You will need to re-verify that you are not re-scheduling the same job multiple times now.

Sources Of Incompatibility

We performed some customer interviews to see how these routines are used before modifying them. We rank the risk of incompatibility as being low, but since we cannot rule out the possibility, all we have to do is list what incompatibilities you may encounter.

Keys of Scheduled Jobs

If you relied on the key to extract information, such as the path and/or arguments of the job, this represents a source of incompatibility. However, our customer interviews only showed a basic usage of the scheduler, so the risk of incompatibilities is very, very low. Keep in mind that the key has no meaning other than identifying a certain job.

Uniqueness of the Jobs

Because of the concern of ever-spawning jobs, we added a condition that if the file path and the arguments were the same, and you are re-scheduling a job with those characteristics, we would delete the previous job and schedule a new one. Turns out that it was a false concern and that customers understood the importance of not defining too many jobs.

We lifted this restriction in this version. If you relied on re-scheduling jobs like above, you are advised to review your architecture and ensure that your job is scheduled just once.

The risk of incompatibility is a little greater here, however not much greater. To mitigate this risk, we have created the getScheduledJobKeysByScript() routine that provides access to the key of a scheduled job. You may search for the script prior of scheduling one, and if found, you have the option to cancel it (delete) and reschedule a new job, or simply not to start the same job again.

See also