Page tree
Skip to end of metadata
Go to start of metadata

On this Page:
A class assigned the stereotype <<E2ETimer>> models a Timer. An activity assigned to the Timer class models the Timer event handler. The internal Bridge scheduler process executes the for each Timer event.

This page gives an overview of the components required to build a Timer Service.

Figure: Timer Use Case Diagram

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

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

Timer Event Handler

Whenever an event is due, the Timer executes the activity assigned to the <<E2ETimer>> class. The following example creates a string, converts the string to a blob, and writes the blob to a file.

Figure: Activity Example of Calling a Time-Triggered Event

The tagged values of an instance of the <<E2ETimer>> class define when the activity above is executed. The deployment diagram specifies the tagged values.

Timer Components

Added in Builder 6.0A Timer service (TimerService) does not have any external interface, so the class resident on the <<E2ETimerService>> contains no operation. This class (Timer) must have the stereotype <<E2ETimer>>; that is, it must be a Timer.

There is one exception, when a Timer service has an external interface: This is a trace interface, which is a SOAP interface to the activity assigned to the Timer class for debugging purposes.The compiler generates automatically the shadow interface and the corresponding shadow service when compiling the service. The E2E Analyzer and the E2E Interactive Debugger display the interface as a SOAP operation (for more information see Testing of Non-SOAP Services).

Figure: Timer Component Diagram

The TimerExample composite contains a Timer service (<<E2ETimerService>>). The Timer service instance contains a class (Timer).

The Timer artifact has the following tagged values that define when the event handler is executed.

Tagged ValueDescriptionDefaultMandatory
repeatIntervalmust be a valid time duration expression (see Time Durations) and defines the break between the repetitions of the defined action in the called activity diagram. mandatory
occurrencesmust be a positive integer and defines the count of repetitions. If the time event shall be repeated forever, set occurrences to always.always 
firstOccurrencemust be a valid time duration expression (see below) and defines the start time of the action. The start time is not set absolutely but is counted from the beginning of the startup of the Bridge process.0
(means directly after start-up of the xUML service)
 
parallelEventsmust be an integer and defines the count of Timer event handlers running in parallel. An event handler runs in parallel when an event handler needs more time for execution than the period defined by the tagged value repeatInterval. In this case, the next event handler is due to start before the prior one has finished. The Timer starts the pending event handler in parallel with the one currently running. This happens as long as the number of parallel running handlers is less than, or equal to, parallelEvents. If the number of allowed parallel events is reached, the next event will be queued.1
(means that Timer event handlers do not run in parallel)
 
queuedEventsmust be an integer and defines the count of timer events that are stored in a queue. The Bridge queues timer events if the count of running parallel events is higher than parallelEvents. These events are not executed immediately but wait until the number of running parallel events is lower than, or equal to, its definition in parallelEvents.1
(means that Timer event handlers that cannot run in parallel will be queued)
 

Running the xUML service, the following warning may be written to the xUML service standard log that can be viewed on the Bridge:

[Warning][External][TIMADLM][13][Event dropped, queue is full. Request not being executed: <internal activity diagram ID>]

Reason and solution for this problem are described in chapter Troubleshooting.

Timer Components and Deployment of E2E Builder Version 5.1

  • Deprecated since Builder 6.0
 Click here to read the documentation of the component diagram used in E2E Builder releases before 6.0...

A Timer service (TimerService) does not have any external interface, so the class resident on the <<E2ETimerService>> contains no operation. This class (Timer) must have the stereotype <<E2ETimer>>; that is, it must be a Timer.

There is one exception, when a Timer service has an external interface: This is a trace interface, which is a SOAP interface to the activity assigned to the Timer class for debugging purposes. This shadow interface and the corresponding shadow service is generated automatically when compiling the service in trace mode. After importing the WSDL file into the E2E Model Debugger, the interface is visible as a SOAP operation.

The component diagram below contains also the FileSystemService because, in this example, the Timer service creates a file.

Figure: Timer Component Diagram

The TimerExample composite contains a Timer service artifact (<<E2ETimerServiceDeployment>>). The Timer service instance contains a class artifact (TimerArtifact).

The Timer artifact has the following tagged values that define when the event handler is executed.

Tagged ValueDescriptionDefaultMandatory
repeatIntervalmust be a valid time duration expression (see below) and defines the break between the repetitions of the defined action in the called activity diagram. mandatory
occurrencesmust be a positive integer and defines the count of repetitions. If the time event shall be repeated forever, set occurrences to always.always 
firstOccurrencemust be a valid time duration expression (see below) and defines the start time of the action. The start time is not set absolutely but is counted from the beginning of the startup of the Bridge process.

0
(means directly after start-up of the xUML service)

 
parallelEventsmust be an integer and defines the count of Timer event handlers running in parallel. An event handler runs in parallel when an event handler needs more time for execution than the period defined by the tagged value repeatInterval. In this case, the next event handler is due to start before the prior one has finished. The Timer starts the pending event handler in parallel with the one currently running. This happens as long as the number of parallel running handlers is less than, or equal to, parallelEvents. If the number of allowed parallel events is reached, the next event will be queued.1
(means that Timer event handlers do not run in parallel)
 
queuedEventsmust be an integer and defines the count of timer events that are stored in a queue. The Bridge queues timer events if the count of running parallel events is higher than parallelEvents. These events are not executed immediately but wait until the number of running parallel events is lower than, or equal to, its definition in parallelEvents.1
(means that Timer event handlers that cannot run in parallel will be queued)
 

The deployment diagram below shows only one node: the E2E Bridge node. As the file system backend service (FileSystemService) runs on the Bridge, there is no additional backend node. Therefore, the Bridge has two assigned stereotypes: <<E2EBridgeServeInstancer>> and <<BackendServerInstance>> , because this node acts as E2E Bridge and backend server at the same time.

In the deployment diagram, you specify components to be deployed; the component diagram defines the components. Deployment means instantiating components, and annotating all configuration information to run these components, on their target systems.

Figure: Timer Deployment Diagram

Running the xUML service, the following warning may be written to the xUML service standard log that can be viewed on the Bridge: [Warning][External][TIMADLM][13][Event dropped, queue is full. Request not being executed: <internal activity diagram ID>]Reason and solution for this problem are described in chapter Troubleshooting.