Scenarios for Using Scheduled Rules

Batched events:

In many environments, certain types of events are not immediately available to the Manager. Instead, the events arrive in batches infrequently: once a day or once a week. Such events have different Manager receipt times and end times. Manager receipt times are current (when the batches are submitted), but the event end times are in the past, because they happened in the past. Common examples of events sent in batches are those involving physical security devices, and represent individuals gaining entry to buildings or offices by means of badge readers and card keys.

Since these events (like an employee entering an office) arrive late to the Manager, they cannot be effectively correlated with other events (like a user login) by deployed rules that use the real-time rules engine. When the real-time rules engine receives login events, it waits for 1 minute (or whatever the time window for this rule is) and then discards that login event, since the other event did not arrive within rule's time window. Consider a rule that looks for a badge swipe event and a login event within 1 minute of each other (aggregates on 1 minute). The login events are received by the Manager in real time as they occur. But the badge swipe events are collected and submitted only once a day at 10 p.m.

A real time rule would not correlate the two events because it would discard the login event before it ever gets the batched event. But if you scheduled your rule to run at midnight with the scheduled rules engine, ESM could correlate the actual end times of batched events and login events that occur within 1 minute of each other. Scheduled rules can correlate these types of events because:

1. Rules can be scheduled to run when both the login and batched events are available within the database, and

2. Although the Manager receipt times for these events would be different, their end times are close together within the aggregation window. Correlations are based on end times of events.

Historical data:

You may want to capture and correlate other kinds of historical data other than batched events. For example, if you have observed a pattern of events over the last several weeks, decide to write rules to take actions on some of those events, and correlate not only future occurrences of them but also the past events. This is possible to do by specifying the desired date range in the filter for the schedule, for example, a filter that specifies Manager receipt time (MRT) to be between a past date range.

Optimized rule schedules:

Another scenario in which you might want to use scheduled rules is for rules that are more appropriate to run after business hours (for example, in the middle of the night). The job scheduler on rule groups lets you specify the appropriate schedule, and the rules are deployed as correlated events but are executed on off-hours.

In all such cases, scheduled rules generate correlation events and take real actions when triggered, just like deployed real-time rules.