Documentation

Services

Tips > Use Timers

Timers can be very beneficial when you want to ensure the execution of an action.
For example the sender action could fail becuase the SMPP connection to the SMSC is down, while some actions can be configured to retry several times, other actions donot have such feature, and here comes the use of the timer, consider this scenario:
you created a scenario where your customer requests certain information about his account, you create a SQL action to read the requested information, and a sender action to send it back to the customer:

This is striaghtforward and very simple, the downside is that the sender action could fail, say the connecttion to the SMPP was down!
A better approach to ensure the sending of the reply is to create two actions groups:
  • The first group is only executed for the requests recieved from customers, this action consists of two child actions
    • SQL action to look up the data from the database
    • SQL action to inserts the message into an "Outbox" table in the database where it gets persisted
  • The second group of actions is only executed from a timer that runs periodically, say every 10 seconds, with three child actions:
    • A SQL action to read a message from the Outbox table
    • A sender action to send the read message, this action should have "continue on error" set to false
    • A SQL action to delete the message from the Outbox
Something like this:

to limit the an action to group to a certain service or timer you can set the expression of th action group to:
${SERVICE} = 'MyService' ${SERVICE} = 'Mytimer' This migh be a little more complex but it comes with the value of not ensuring the sending of the messages
More optimization can be done to read and send messages in batches