Comment gérer les utilisateurs hors connexion dans vos campagnes RBM

L'un des principaux facteurs du délai de distribution des messages de votre agent est de savoir si le l'utilisateur que vous tentez de joindre dispose d'une connexion de données au moment où votre agent envoie un message. Si l'utilisateur est hors connexion, la plate-forme RBM stocke le message et tente de le distribuer pendant 30 jours maximum. Si le message ne peut pas être distribué d'ici là, il est supprimé du système.

De nombreuses raisons et situations peuvent expliquer qu'un utilisateur ne soit pas connecté lorsque votre agent tente de le contacter. Il aurait pu désactiver les données pour économiser de l'argent sur leur forfait mobile, pourraient prendre l'avion sans Wi-Fi. d’une connexion, ou se trouvent peut-être dans un métro dans un tunnel. En fonction de l'urgence selon lequel vos messages doivent arriver, l'agent doit gérer les utilisateurs hors ligne en révoquant les messages RBM non distribués et en réacheminant ces messages via un autre canal.

Les sections suivantes expliquent comment utiliser un Google Cloud Datastore pour effectuer le suivi des les messages que vous envoyez et distribuez, comment utiliser Cron pour révoquer les messages non distribués et comment réacheminer ces messages par SMS.

Remarque : Pour révoquer automatiquement un message non distribué après un délai défini (ou à une date spécifique), définissez une date d'expiration du message. Lorsqu'un message expire, la plate-forme RBM tente de le révoquer. Vous recevrez un événement sur votre webhook pour confirmer que la révocation a réussi. Si c'est le cas, C'est le moment idéal pour lancer votre stratégie de message de remplacement.

Suivre les messages envoyés

Chaque message envoyé par votre agent RBM doit inclure un ID de message unique. Pour garder une trace des messages envoyés par votre agent, vous devez enregistrer l'ID du message, le numéro de téléphone et l'horodatage de chaque message.

Vous pouvez utiliser diverses technologies pour stocker ces informations, y compris un Google Cloud Datastore. Cloud Datastore est une base de données NoSQL qui gère automatiquement la segmentation et la réplication. C'est une solution permettant de stocker des données non relationnelles telles que les messages envoyés par un agent. Pour utiliser Cloud Datastore, vous devez disposer d'un instance Google App Engine, ce qui vous permet utiliser App Engine pour héberger votre agent RBM et configurer une tâche Cron.

Des bibliothèques clientes pour Cloud Datastore sont disponibles dans de nombreux langages. Pour cet exemple, vous pouvez utiliser Node.js et baser le code de l'agent RBM sur l'premier exemple Node.js d'agent disponible sur le site Web du développeur RBM. Au début, installer Cloud Datastore pour mon projet Node.js en exécutant la commande la commande suivante:

npm install --save @google-cloud/datastore

Dans le code source de l'agent, ajoutez une référence globale au client Cloud Datastore. bibliothèque.

// Imports the Google Cloud client library
const Datastore = require('@google-cloud/datastore');

// Creates a client
const datastore = new Datastore({
    projectId: PROJECT_ID,
});

Une fois l'objet Datastore créé, vous pouvez introduire une fonction permettant de stocker le msisdn, message id, sent time et delivery pour chaque message.

/**
 *   Records an entry in the Cloud Datastore to keep track of the
 *   messageIds sent to users and the delivery state.
 *
 *   @property {string} msisdn The user's phone number in E.164 format.
 *   @property {string} messageId The unique message identifier.
 *   @property {boolean} delivered True if message has been delivered.
 */
function saveMessage(msisdn, messageId, delivered) {
    const messageKey = datastore.key(['Message', messageId]);

    const dataForMessage = {
        key: messageKey,
        data: {
            id: messageId,
            msisdn: msisdn,
            lastUpdated: new Date().getTime(),
            delivered: delivered
        },
    };

    // Record that the message was sent.
    datastore
        .save(dataForMessage)
        .then(function() {
            console.log('saved message successfully');
        })
        .catch((err) => {
            console.error('ERROR:', err);
        });
}

Une fois cette fonction en place, vous devez appeler cette méthode chaque fois que votre agent envoie un message à un utilisateur. Lorsque le client Node.js RBM bibliothèque envoie des messages RBM, la bibliothèque fournit un objet de réponse dans le rappel qui contient l'messageId pour le message envoyé au utilisateur.

Voici un exemple d'envoi d'un message en texte brut à un utilisateur et d'enregistrement les informations du message après avoir réussi à communiquer avec l'API RBM.

let params = {
    messageText: 'Hello, World!',
    msisdn:'[phone]',
};

// Send "Hello, World!" to the user.
rbmApiHelper.sendMessage(params,
function(response) {
    // Extract the message ID from the response
    let messageId = response.config.params.messageId;

    // Store the sent state in the Datastore
    saveMessage(phoneNumber, messageId, false);
});

Après avoir exécuté le code, vous pouvez inspecter Datastore à partir de la console Google Cloud dans la vue Entités Datastore.

Mettre à jour l'état de distribution des messages

Maintenant que votre agent stocke les requêtes de messages envoyées dans le Datastore, mettez à jour l'état de distribution une fois que le message a été distribué à l'appareil de l'utilisateur.

Les appareils des utilisateurs envoient des événements DELIVERED, READ et IS_TYPING aux agents RBM via Cloud Pub/Sub. Dans le gestionnaire de Pub/Sub, recherchez les événements diffusés et définissez le paramètre Datastore pour l'indicateur de diffusion sur "true".

/**
 *   Uses the event received by the Pub/Sub subscription to send a
 *   response to the client's device.
 *   @param {object} userEvent The JSON object of a message
 *   received by the subscription.
 */
function handleMessage(userEvent) {
    if (userEvent.senderPhoneNumber != undefined) {
        let msisdn = userEvent.senderPhoneNumber;
        let messageId = userEvent.messageId;
        let eventType = userEvent.eventType;

        if(eventType === 'DELIVERED') {
            saveMessage(msisdn, messageId, true);
        }

        // TODO: Process message and create RBM response
    }
}

L'agent enregistre les messages sortants dans Datastore et met à jour les données lorsqu'il reçoit une notification de distribution. Dans la section suivante, découvrez comment configurer une tâche cron sur App Engine de Google pour qu'elle s'exécute toutes les 10 minutes afin de surveiller les messages non distribués.

Cron sur App Engine de Google

Vous pouvez utiliser des tâches Cron pour planifier des tâches à différents intervalles. Dans l'appli Google Compute Engine, une tâche Cron est configurée avec une description, une URL et un intervalle.

Dans les applications Node.js, vous les configurez dans un fichier cron.yaml, que vous pouvez déployer à App Engine à l'aide du SDK Google Cloud. Découvrez d'autres configurations de configuration linguistique dans Planifier des tâches avec cron.yaml.

Comme la tâche cron nécessite une URL, vous devez ajouter un point de terminaison d'URL au routeur d'application Express à appeler par cron. Ce webhook est chargé d'interroger le Datastore pour rechercher d'anciens messages, de les supprimer de la plate-forme RBM et de les envoyer à l'utilisateur par SMS.

router.get('/expireMessages', function(req, res, next) {
    // TOOD: Query the Datastore for undelivered messages,
    // remove them from the RBM platform, and send them over SMS

    res.status(200).send();
});

Vous trouverez ci-dessous la configuration du fichier cron.yaml pour exécuter ce point de terminaison toutes les 10 minutes.

cron:
-   description: "Processing expired RBM messages"
  url: /expireMessages
  schedule: every 10 mins

Pour déployer les tâches Cron sur App Engine, exécutez la commande suivante:

gcloud app deploy cron.yaml

Après le déploiement, App Engine configure automatiquement la tâche Cron et sous App Engine > Jobs Cron :

Interroger Datastore pour les messages non distribués

Dans le webhook du job Cron que vous avez configuré dans la section précédente, vous devez ajouter pour rechercher tous les messages envoyés dont l'état delivered est défini sur "false" et dont le délai d'expiration de lastUpdated est antérieur à un délai d'expiration prédéfini pertinent pour notre cas d'utilisation. Dans cet exemple, les messages datant de plus d'une heure expirent.

Pour accepter une requête composite de ce type, le datastore doit disposer d'un index composite contenant les propriétés delivered et lastUpdated. Pour ce faire, vous pouvez créer un fichier dans votre projet appelé index.yaml avec les informations suivantes :

indexes:
-   kind: Message
  properties:
  -   name: delivered
    direction: asc
  -   name: lastUpdated
    direction: desc

Comme pour le déploiement de la tâche Cron que vous avez définie précédemment, utilisez la bibliothèque cliente Google Cloud SDK permettant de déployer l'index composite que vous avez défini à l'aide de la commande suivante:

gcloud datastore create-indexes index.yaml

Après le déploiement, App Engine configure automatiquement l'index, lequel sous Datastore > Index

Une fois l'index défini, vous pouvez revenir au webhook que vous avez créé pour la tâche cron et finaliser la logique d'expiration des messages :

router.get('/expireMessages', function(req, res, next) {
    // Milliseconds in an hour
    const TIMEOUT = 3600000;

    // Threshold is current time minus one hour
    const OLD_MESSAGE_THRESHOLD = new Date().getTime() - TIMEOUT;

    // Create a query to find old undelivered messages
    const query = datastore
        .createQuery('Message')
        .filter('delivered', '=', false)
        .filter('lastUpdated', '<', OLD_MESSAGE_THRESHOLD);

    // Execute the query
    datastore.runQuery(query).then((results) => {
        for(var i = 0; i < results[0].length; i++) {
            let msisdn = results[0][i].msisdn;
            let messageId = results[0][i].id;

            // Stop the message from being sent
            rbmApiHelper.revokeMessage(msisdn, messageId);

            // Remove the message from the Datastore
            datastore.delete(results[0][i][datastore.KEY]);

            // TODO: Send the user the message as SMS
        }
    });

    res.status(200).send();
});

RBM n'est pas compatible de manière native avec les SMS de remplacement. Vous devez donc implémenter le pour envoyer les messages non distribués par SMS.

Synthèse et résumé

Remarque : Pour révoquer automatiquement un message non distribué après un délai ou une date spécifiés, définissez une date d'expiration du message. Lorsqu'un message expire, la plate-forme RBM tente de le révoquer. Vous recevrez un événement au niveau du webhook pour vérifier si la révocation a bien été effectuée. Si c'est le cas, c'est le bon moment de déclencher votre stratégie de messagerie de remplacement.

Pour gérer les utilisateurs hors connexion, vous pouvez créer une logique de révocation pour les RBM non distribués messages. La durée que vous utilisez avant d'expirer le message dépend de l'urgence des informations que vous transmettez. Avec des informations urgentes, un délai avant expiration recommandé est inférieur à deux heures.

Cet exemple utilise Cloud Datastore et Google App Engine pour gérer le stockage, de requête et de révocation, mais tout mécanisme de stockage permettant de suivre que vos messages envoyés et remis devraient fonctionner.

Bonne chance et à vous de jouer !