Rules can schedule internal events, which are triggered some time in the future. The predefined rule action used to schedule an event has a syntax similar to the generate() action. The schedule()action specifies in the same way a list of pairs (attribute name, attribute value) that are elements of the future event. The date attribute should be present, and its value should be a future date (later than the current date when the rule is evaluated). Otherwise, the event is immediately triggered.
Use the schedule() predefined rule action to schedule an internal event at a specified date. The scheduler keeps track of all scheduled events and activates them when they are due. The general syntax is:
Argument 1: <event_name>. This name identifies the event—or a group of events—in the scheduler. Several scheduled events can have the same name. Such identification is useful in case the event(s) are removed from the scheduler (that is, un-scheduled).
Note: The <event_name> name should be less than 255 characters.
Argument 2: event date (<date>). This is the date of the scheduled event, that is, when generated. The date is expressed following the UTC standard, which is supported by Java (JDK). In case a date is given that is already past, the event is immediately generated. Often, a date expression that adds some time to the current date is given here, like: NOW + 3*DAY.
Following arguments: Values of attributes. These arguments represent a list of named values of the form: <evt_attribute>:<value>. They have the same semantics over the reused event (if any) as for the generate() action. Unless a reused event is specified (last optional argument), the list of named values should always contain at least the two items: type:... and value:....
Event argument (optional): The "reused event" event:<evt_var> is an event variable that represents an incoming existing event (captured in the condition part of the rule) to be reused for defining the scheduled event.
Note: Like for the generate() call, special attributes of the reused event are not automatically reported in the new event: the event ID attribute and the PROCESSINSTANCEID attribute.
Example 1:The rule below schedules an event for generation three hours after reception of an event marking the beginning of a process. The scheduled event repeats the content of the triggering event, except for its date (3 hours later), its type (now "timeout") and an additional attribute in the context ("notes").
rule myschedule
activated by EVT_1 of BP Server::PI_ACTIVATED
if (EVT_1.PROCESSTEMPLATENAME = "Upgrade Memory")
then {
schedule("myevent", EVT_1.date + 3*HOUR , type:"timeout",
value:"timeoutcheck", notes:"upgrade should be finished in 2 hours",
event:EVT_1);
}
Example 2:In this example, the date is calculated by adding three hours to the time the rule is executed (given by the function NOW). Ideally, if the event is received by BPM Events immediately after being generated, then the event time stamp (its date attribute) is approximately the same as the current date (NOW). So the actions in examples 1 and 2 should be equivalent. In practice, there may be some significant difference between the notification date of an event (the date it is received by BPM Events) and the origination date (the time stamp date actually stored in the event). If what really matters is the difference between the origination times of both events, as in this example (If you want to schedule a check exactly three hours after the Upgrade Memory process started), then use the origination date, as in Example 1. If you want a scheduling based on the current date, then use NOW.
schedule("myevent", NOW + 3*HOUR , type:"timeout", value:"timeoutcheck",
notes:" upgrade should be finished in 2 hours", event:EVT_1);
Example 3:In this schedule action, an absolute date is given. No reused event is given. The scheduling date is independent from the date when the rule actually executes.
schedule("myevent", YEAR:2000/MONTH:1/DAY:1 , type:"alarm",
value:"alarmcheck", notes:"check for year 2K problems");
Argument 1: <event_name>. This name identifies the event—or a group of events—in the scheduler. Several scheduled events can have the same name. Such identification is useful in case the event(s) are removed from the scheduler (that is, un-scheduled).