Scheduled Events - Legacy

1 Introduction

With scheduled events you can let the runtime execute a microflow at a specific moment in time. The event can also be repeated with a given interval, for example every day.

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

A ScheduledEventInformation object is created every time the scheduled event defined in your app model is run. This records the following:

• Name – the Name of the scheduled event as entered in Common Properties
• Description – the Documentation of the scheduled event as entered in Common Properties
• StartTime – the time this run of the scheduled event started
• EndTime – the time this run of the scheduled event ended
• Status – the current status of this run of the scheduled event:
  • Running – the event is currently running and has not yet ended
  • Completed – the event has completed successfully
  • Error – the event completed with an error — you can find the error on the error log using the StartTime and EndTime to locate it if necessary
  • Stopped – the scheduled event was stopped before completion, for example by the app being stopped or a cluster node becoming unhealthy

2 Common Properties

3 Execution Properties

4 Timing Properties

5 Additional Information

5.1 Running Concurrently

You cannot run more then 10 scheduled events in parallel.

This limit cannot be overridden and is independent of how the app is scaled.

5.2 Calculating Intervals

The platform schedules the scheduled event by fixed intervals. That means that at startup, the platform schedules the next iterations/intervals the scheduled event should run. This is done by retrieving the intervals, and in addition the platform does some calculations.

Seconds, Minutes, Hours, Days, and Weeks are scheduled exactly as configured.

Months and Years might not be executed as you would expect:

• A Month is interpreted as a 31 day interval
• A Year as a 365 day interval

So be aware when scheduling your events using Month or Year, because they may not run on the day you are expecting.

For example, if you schedule an event to start on March 1 with one month intervals, it will subsequently run on April 1, May 2, Jun 2, Jul 3, Aug 3, Sep 3, and so forth.

This is a simplified example of the implementation of how the Mendix 5.3.2 release calculated the interval. Later releases might behave slightly different.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

switch(scheduledEvent.getIntervalType())
{
    case SECOND:
        timeUnit = TimeUnit.SECONDS;
        interval = scheduledEvent.getInterval();
        break;
    case MINUTE:
        timeUnit = TimeUnit.MINUTES;
        interval = scheduledEvent.getInterval();
        break;
    case HOUR:
        timeUnit = TimeUnit.HOURS;
        interval = scheduledEvent.getInterval();
        break;
    case DAY:
        timeUnit = TimeUnit.DAYS;
        interval = scheduledEvent.getInterval();
        break;
    case WEEK:
        timeUnit = TimeUnit.DAYS;
        interval = scheduledEvent.getInterval()*7;
        break;
    case MONTH:
        timeUnit = TimeUnit.DAYS;
        interval = scheduledEvent.getInterval()*31;
        break;
    case YEAR:
        timeUnit = TimeUnit.DAYS;
        interval = scheduledEvent.getInterval()*365;
        break;
}

5.2.3 Running a Scheduled Event on a Specific Day

If it is absolutely critical to run a scheduled event on a specific day of the month, schedule the event to run daily and have it check whether it is the right day of the month to run it.

In your microflow, start with a decision using an expression similar to this:

parseInteger( formatDateTime( [%CurrentDateTime%], 'dd') ) = 15
// This runs the scheduled event on the 15th of the month

To run it on the last day of the month, you can use this suggestion from Herbert Vujik:

formatDateTime([%CurrentDateTime%], 'dd') = formatDateTime([%EndOfCurrentMonth%], 'dd') 

5.3 Specifying the Time

In addition to Monthly and Yearly scheduled events, you also want to be careful when scheduling daily events if they need to run every day at a specific time. This is because of daylight saving time.

Whenever you set up an event to run every day at a certain time, it will start at the specified time. However, after this it will run at a fixed interval (internally this is calculated back to run every X nanoseconds). This means that a daily event runs every 24 hours. Therefore, if the time changes because of daylight saving, your event could be an hour off.

This depends on the locale (time zone) your server is hosted in. Even if you choose UTC time, you will still experience this time shift if you are in a country that adopts daylight savings, as the daylight savings changes the offset from UTC.

Unfortunately there isn’t a great workaround for this issue. If the scheduled event has to be run at a specific time you could create a similar solution to that described above, scheduling the event hourly and using ‘HH’ (0-23 hours), or ‘kk’ (1-24 hours) rather than ‘dd’ in the date format expression. Remember that this will increase the number of ScheduledEventInformation objects created.

5.4 Long Running Events

If a repeated scheduled event takes longer than the interval then the next scheduled event will be delayed, the events will not run concurrently. For example, if a scheduled event is repeated every 5 minutes but the event takes 10 minutes then the next event is delayed by 5 minutes.

5.5 Cleaning Up Old Events

The execution of a scheduled event produces a System.ScheduledEventInformation object in the database. Over time these accumulate and the table can grow large.

In Mendix 9.9 and above, the System.ScheduledEventInformation can be cleaned up automatically by specifying the com.mendix.core.ScheduledEventsCleanupAge runtime setting. This setting specifies (in milliseconds) how old objects in the table have to be before they are automatically cleaned up. Only objects with the “Completed” status are cleaned up. The cleanup action will be run every ClusterManagerActionInterval, and does not produce any log messages. In Mendix version 9.24.17 and above, the cleanup action will remove a maximum of 10000 objects each time it runs. This can be configured with the com.mendix.core.ProcessedTasksCleanupBatchSize runtime setting. In versions below Mendix 9.24.17, the action will remove all matching objects.

In Mendix 9.9 and above if com.mendix.core.ScheduledEventsCleanupAge is not specified, no cleanup is performed. In Mendix 10 if com.mendix.core.ScheduledEventsCleanupAge is not specified, then the default setting is 365 days for projects migrated from Mendix 9 and 7 days for new projects or projects with an empty database.

In versions of Mendix below 9.9.0, you can clean up old events by creating a microflow for administrators to use if the table gets too large.