Scheduled Events

Introduction

Sometimes you will want to regularly run a microflow which does not require end-user interaction. You can do this using scheduled events. Scheduled events are managed using the task queue mechanism.

A scheduled event is added to your module as a document (right-click your module and you will find it listed under Add other).

Common Properties

Execution Properties

Timing Properties

Yearly Properties

You can specify how a yearly scheduled event is run in two different ways by specifying the Input type:

• Date – run it on a specific date
• Month and weekday – run it on a specific weekday

Date

This allows you to run the event on the same date every year (for example, April 5th).

Month and Weekday

This allows you to run the event on a certain day of the week every year. For example, the first Monday in April.

Monthly Properties

You can also specify how a monthly scheduled event is run in two different ways by specifying the Input type:

• Particular day – run it on a specific day of the month
• Weekday – run it on a specific weekday

Particular Day

This allows you to run the event on the same date every month, or number of months (for example, the 5th of each month).

Weekday

This allows you to run the event on a certain day of the week every month, or number of months. For example, the first Monday of each month.

Weekly Properties

This allows you to run the event on certain days every week. For example every Monday, Wednesday, and Friday.

Daily Properties

This allows you to run the event every day.

Hourly Properties

This allows you to run the event every hour, or number of hours. It also allows you to set an offset, so the first event is not run at midnight. For example, every three hours starting at 01:30.

Example times will be shown in the dialog to illustrate the effects of the offset.

Minutes Properties

This allows you to run the event every minute, or number of minutes.

Long-Running Events

If a repeated scheduled event takes longer than the interval, an overlap would occur. To prevent this, choose one of the following options in the On overlap property of the scheduled event:

• Skip next – If an event takes longer than its interval, subsequent events are skipped until it has completed. The next event will start at the next available scheduled time.

  This is the default and will ensure that events are always run at a scheduled time, subject to queue resources being available (see Running Concurrently, below).

• Delay next – If an event takes longer than its interval, the next event is delayed until it has completed. The next event will start immediately after the previous one has completed and will likely not be run at a scheduled time.

  If multiple successive events are longer than their interval, the intended scheduled time will be further and further away from the actual start time. This situation should be avoided by choosing an interval that is generally sufficient to run the event.

  If an event has drifted a long way from its intended schedule over time, the best way to remedy this is to delete the event and create a new one (with a longer interval).

Additional Information

Server Time

You can choose Server time rather than UTC time, but make sure that your server time is set as you expect. Many servers are set to run on UTC to avoid issues when working across time zones.

Daylight Saving

If the chosen time zone is UTC, then an event will always be run at the specified time. However, if server time is chosen there may be daylight saving for the configured time zone (in the app’s runtime settings). If a time is chosen which is in the daylight saving time window (the time at which the clocks change, for example between 01:00 and 03:00 in Europe), then that time will not occur on one day of the year and occur twice on another day of the year. The scheduled event will not be affected by this and will run exactly once on those days.

Running Concurrently

No more than ten scheduled events can be run in parallel for each cluster node. Additional scheduled events will be queued and run in “first in, first out” order as currently running events finish.

This limit cannot be overridden.

Unsupported Intervals

Hour- and minute-based intervals can only be integer divisors of 24 or 60, respectively. For example you cannot schedule an event to be run every seven minutes as this does not divide precisely into 60 minutes. If it is absolutely critical that an unsupported interval is used, you should schedule the event with interval value of one (every hour or every minute) and decide within the microflow whether it should continue at that particular time.

Cleaning Up Completed Scheduled Events

Every time a scheduled event is run it produces an entry in the System.ProcessedQueueTask table in the database. Over time these accumulate and the table can grow large. Refer to the documentation on Cleaning Up Old Processed Tasks in Task Queue to learn how to remove processed entries.

One Session for All Scheduled Events

Each runtime node has one specific session in memory which is used for all scheduled events. Changes to this session are visible for all scheduled events on that node. Things like changing the time zone via a Java action in one scheduled event can lead to unexpected behavior in other scheduled events. You are therefore strongly discouraged from changing the session object for scheduled events.