Retrying Messages

If a message is delivered via SMPP or MM7 and it is not possible to deliver it immediately, it can be stored and resent later. This is done using the mstore module.

For an SMPP message, delivery is indicated by a delivery receipt and for MM7 by a delivery report. After a message is successfully submitted on SMPP or MM7, it may take a while to deliver it to the handset, or to decide it cannot be delivered. If it cannot be delivered, policy hooks can requeue the message to the same or another domain.

In order to retry messages delivered via SMPP or MM7 the mstore module needs to be initialized. This module uses Riak to retain messages so a Riak server must be configured. If you accepted the default settings during installation, this should already be set up. For more information about Riak see Riak and Riak Server. The length of time that messages are retained is discussed in “Message Retention”.

In version 3.3 additional non-module options are introduced to support the mstore module. These options are as follows:

mm7_mstore_save_message

Whether or not to save messages for resubmission. This option must be enabled in order for the mstore module to function. The default value for this option is true.

This option is valid in the binding, binding_group, domain and global scopes.

mm7_mstore_bucket_use_shortcode

Whether or not to make use of the shortcode as part of the bucket ID. The Riak bucket ID is required when using mstore Lua functions or the mstore console commands. The default value for this option is true.

msys.mstore.inject(msg): inject the message back into spool. If you want to reroute the message to a different destination, it is recommended that you use the existing API method msg:inject(from, to) to do this. For more information about this function see msg:inject.

The purpose of this hook is to suppress storing messages in the mstore or to provide alternate storage. A return of non-zero from these hooks suppresses the default storage.

This hook is called on a successful SMPP submission. The return values are as follows:

MSTORE_CONTINUE (0) – continue with the default action, which is to store the message, along with the bucket ID and message ID, in the Riak data store

MSTORE_DONE (1) – skip the default action

smpp_handle_DR_negative(const char * bucket, const char * msgid)

The purpose of this hook is to implement policy (using the Lua API) when a delivery receipt arrives. This hook typically loads a message from the mstore, injects a message into ecelerity, and/or deletes a message from the mstore.

SMPP_CONTINUE (0) – continue default process, which is to generate a bounce email to the original sender

SMPP_DELIVERED (3) – skip the default process (i.e. do not generate a bounce email to the original sender)

smpp_handle_DR_positive(const char * bucket, const char * msgid)

The purpose of this hook is to implement policy (using the Lua API) when a delivery receipt arrives. This hook typically loads a message from the mstore, injects a message into ecelerity, and/or deletes a message from the mstore.

SMPP_CONTINUE (0) – continue default process, which is to generate a bounce email to the original sender

SMPP_DELIVERED (3) – skip the default process (i.e. do not generate a bounce email to the original sender)

This hook is called on a successful mm7 request submission. The return values are as follows:

MSTORE_CONTINUE (0) – continue with the default action, which is to store ec_message into Riak data storage along with the bucket ID and message ID

MSTORE_DONE (1) – skip the default action

mm7_handle_DR_negative(mm7_trx, bucket_id, msgid)

This hook is called upon receiving a delivery report which indicates a failure of the previous request submission (the Status indicated in the delivery report has the value “Expired”, “Rejected”, “Unrecognised” or “DeliveryConditionNotMet”). This hook happens before DeliveryReceiptRsp is sent and also before a bounce email is generated. The most intuitive use of this hook point is to call the “mstore.load_message” API to retrieve the previous submission and reroute the message, as shown in the examples below. The user can return the following values from this hook:

MM7_CONTINUE (0) – continue default process, which is to generate a bounce email to the original sender

MM7_DELIVERED (3) – skip the default process (i.e. do not generate a bounce email to the original sender)

mm7_handle_DR_positive(mm7_trx, bucket_id, msgid)

A counterpart of the previous hook. It handles a DeliveryReceiptReq which indicates a successful request submission. A straightforward implementation of this hook is to use “mstore.delete_message” to remove the submitted message from the Riak storage. The integer return value of this hook is not currently used.