External clients, such as SOAP requests, do not call timed events. An internal Bridge scheduler process executes timed events. The tagged values of a Timer object define when the scheduler process executes the timed events.

The Timer can be used, for instance, to poll Services periodically. The Scheduler is more appropriate if you want to start a Service at a specified date(see chapter Scheduler). Some tasks can be performed by either component. The main difference between the two components is that the Timer's time definitions are relative to the startup time of its Bridge Server process, whereas the Scheduler's time definitions are independent of the startup of its Bridge Server process. Additionally, the Timer can control the execution of parallel events and is able to queue events; the Scheduler cannot. On the other hand, the Scheduler can evaluate complicated date time patterns whereas the Timer is restricted to simple periodical events.

One of the most frequent use cases for the Timer is to poll databases, file systems, or any other kind of backend system. Put differently, the Timer is most frequently used to observe external events. This can modeled by the Timer component mentioned above following the instructions given in the next chapters. However, UML 2.0 introduced a more elegant way of modeling time-triggered events. This mechanism is used in the Event Observer component. Behind-the-scenes, the Event Observer is just a Timer but modeled in a more elegant UML 2.0 compliant way. The section Event Observer describes the Event Observer component.

Example File (Builder project Add-ons/Scheduling):

<your example path>\Add-ons\Scheduling\uml\timer.xml
<your example path>\Add-ons\Scheduling\uml\eventObserver.xml