Time Events and Scheduler Functions : Overview of Time Events

Overview of Time Events
TIBCO BusinessEvents offers two kinds of time events, repeating and rule-based. In addition you can schedule events using functions.
Time events do not go through an event preprocessor. If you are using cache-only cache mode, ensure that any objects are properly loaded. Events scheduled using scheduler functions, however, are sent through channels and would therefore go through event preprocessors in the usual way.
See Also
Chapter 8, Simple Events for overview information about events in general.
Chapter 24, Diagrams for information on using diagrams.
Scheduled Time Events
Repeat (Interval) based time events are not supported in multi-engine mode   Time events configured to repeat at intervals are not supported in multiple-agent (multi-engine) configurations. Rule-based time events, however, are supported.
You can configure a time event to repeat at a configurable time interval. For example, if you configure a time event to repeat every thirty seconds, then every thirty seconds BusinessEvents creates a new time event of that type.
You can configure a repeating time event to create a specified number of events at each interval.
At engine startup
The time interval begins during engine startup. See Appendix C, Engine Startup and Shutdown Sequence in TIBCO BusinessEvents Administration for specific details.
Rule Based Time Events
A rule based TimeEvent resource has only a name and description. You can then use it in a rule to schedule a simple event to be asserted, using its ontology function, ScheduleTimeEventName() in a rule (see Rule Based TimeEvent Function Reference). You can schedule the event to be asserted after a period of time, and you can pass information to the event and specify its time to live. You can call the ScheduleTimeEventName() function in different places with different time delays.
You can use rule based time events in various ways. For example, you might write rules that check for delays in order fulfillment:
1.
A new Order event is asserted, and Rule A (which has Order in its scope) creates a time event T and configures it to be asserted in sixty minutes, and passes the order ID as the closure parameter value. (Rule A also sends the order details to another system.)
2.
3.
The assertion of time event T triggers Rule B, which has T in its scope. Rule B checks the order status. If the order is delayed, it sends out an alert.