The timer interface

The timer interface consists of nodes DniSetTimer and DniCancelTimer. The following example shows how to use this interface.

An application programmer creates a message flow named PROC that creates service requests out of DB table entries. It sends these requests to other services and waits for a response. If it does not get a response within a reasonable amount of time, a timer wake-up message triggers the service to resend its request. This timer event was set by the service when it created the service request. The timer event ID was stored together with the request in the DB.

The service response is a type of acknowledgment, and so it does not need to be processed. When the response arrives, the service deletes the request from the DB and inserts a Cancel Timer request in the message to delete the timer event it has set in case no response arrives.

The PROC service provides an overview of the general processing, but does not implement detailed processing such as error handling. It has a service interface queue and a service input queue with names that conform to the FTM SWIFT naming conventions. In this example, it is assumed that this service is triggered for the first time by a message that is not a timer wake-up request.

The timer wake-up processor is set with a polling interval of 60 seconds. In other words, it polls every 60 seconds for expired timer events. If the service wants to get a timer wake-up event after 5 minutes, because of the polling the wake-up message might not arrive until 6 minutes (5 minutes + 60 seconds) later. However, this does not affect the processing of the PROC service.

The message flow uses node DniConfigProvider of type DniConfigProvider to receive configuration data needed for processing. Therefore, the application programmer defines a COS named MyProcConfig. This COS has the following configuration:

 COS MyProcConfig
  CT                 CO      Description
  DniTimer           *       for getting all timer categories
  DniLevelsTrace     *       for enabling the FTM SWIFT trace if necessary

The message flow uses both nodes of the timer interface. First, look at the use of node DniSetTimer. During service request creation, the message flow carries out the following steps:

In Compute node GetSvcData it accesses the DB and gets the data for the service request that is to be created. It creates that request and, simultaneously, creates a set timer request that is used in the subsequent DniSetTimer node.
It sets the WakeupInterval value to 5 minutes. This is the time it waits for the response of its service request. If after 5 minutes the service received no response, it must resend the request. Therefore, after this time, a wake-up message from the timer service triggers this service to resend the request.
The node DniSetTimer inserts the timer event in the timer database table and stores the timer event ID and the timer table in its response.
Compute node "StoreTimerEventWithSvcRequest" gets this data from the Response folder of DniSetTimer processing and stores it with the service request data in the database. This ensures that the timer event can be canceled when the response arrives.
The message is sent to the requested service.

The Set Timer request could look like this:

<DniTimer>
  <Set>
    <Request>
      <Category>DNIT0060</Category>
      <TargetService>PROC</TargetService>
      <WakeupInterval>000T00:05:00</WakeupInterval>
    </Request>
  </Set>
</DniTimer>

The Category specifies the timer wake-up processor or more precisely the timer database table to be used. See Timer categories for more information. The TargetService field specifies the name of the service to which the timer wake-up event is to be sent. The value of the WakeupInterval field specifies that the timer wake-up event must be delivered in 5 minutes.

The response looks like this:

 <DniTimer>
   <Set>
     <Request>
       <Category>DNIT0060</Category>
       <TargetService>PROC</TargetService>
       <WakeupInterval>000T00:05:00</WakeupInterval>
     </Request>
     <Response>
       <Completion>
         <Code>Ok</Code>
       </Completion>
       <TimerId   dt = 'bin.hex'>414d5 ... ... 8122887</TimerId>
       <TimerTable>DNI.DNI_TIMER01</TimerTable>
     </Response>
   </Set>
   </DniTimer>

Now, this service awaits one of two possible situations:

Situation A: The response arrives in time. In this case:
1. The service gets the corresponding request and the corresponding timer event data.
2. In Compute node "CreateCancelTimerReq" it creates a cancel timer request, based on the corresponding timer event data, and deletes its service request from the database. The cancel timer request looks like this:
```
<DniTimer>
  <Cancel>
    <Request>
      <TimerId   dt = 'bin.hex'<414d5 ... ... 8122887</TimerId>
      <TimerTable>DNI.DNI_TIMER01</TimerTable>
    </Request>
  </Cancel>
</DniTimer>
```
3. The node DniCancelTimer receives the cancel timer request and removes the timer event from the timer database table.
4. The message flow starts processing the next request.
Situation B: The response does not arrive in time. In this case:
1. The timer wake-up request triggers the message flow.
2. The message flow gets the last request from the DB again in node "GetSvcRequest", and repeats the procedure described previously during service request creation.