Comment concevoir un système de notification Big Data et/ou Temps Réel ?

Alerter en temps réel est devenu une fonctionnalité indispensable. Qu’il s’agisse de prévenir des clients, des partenaires ou des fournisseurs, se doter d’un système de notification robuste et fiable n’est plus optionnel.

Voici un retour d’expérience sur un projet de notification aux clients dans le domaine de la Supply Chain. Découvrez également l’interview de Jérémy Amourous, DSI de Colissimo, qui explique les valeurs ajoutées de la mise en place d’une Architecture Réactive en temps réel.

Le choix d’une architecture réactive

Le besoin exprimé est simple. Il s’agit d’avertir un client d’un problème sur sa commande, ou tout simplement de lui donner de la visibilité sur l’avancement du processus. Sur certaines étapes-clé, il faut donc envoyer un message au destinataire final.

C’est assez simple, non? Et très visible! Pensez à votre propre expérience… Nous sommes tous devenus éminemment impatients! Si on ne reçoit pas dans la minute un message (ex. « forgot password », ou une information de livraison d’un site e-Commerce), on a vite l’impression que rien ne fonctionne!

Mais à y regarder de plus près, tout n’est pas si simple…

D’abord, il est difficile de prévoir à l’avance un volume d’activité et d’envoi d’alertes. Du coup, en cas de saisonnalité ou de pic, on peut avoir à gérer 10 à 20 fois plus de volumes que d’habitude. Il suffit de regarder les records successifs des acteurs de l’e-Commerce (Alibaba en tête) pour se convaincre qu’il faut tenir la charge!

Ensuite, le Système d’Information, ne trace pas toujours bien les différentes étapes du processus, voire… peut perdre des messages ! Pourtant, le client final lui ne pardonnera pas des informations incomplètes ou inexactes. Il faut le prévenir au bon moment… un point c’est tout !

Enfin, les règles de notification peuvent vite évoluer… Faut-il envoyer un mail? Un SMS? Tenir compte des préférences du destinataire? Quel format envoyer en fonction de l’étape? Ainsi, dans notre cas, en plus des mails nous nous avons du progressivement gérer des SMS, puis des notifications mobiles !

Pour répondre à ces différents challenges, le choix d’une l’architecture réactive s’est vite imposé.

Le déclenchement du système de notification réactif

Il est important de prévoir les différents cas dans lesquels le système de notification va se déclencher.

Dans notre cas, on peut en distinguer trois: 

• le déclenchement temps réel. Il s’agit de l’envoi « à la volée » des notifications. Pour celà, on récupère les messages et « logs » du cycle de vie d’un objet. Chaque événement passe à travers un premier composant logiciel. Ce composant, vérifie si les conditions pour déclencher une notification sont remplies. Il s’agit ici de règles au sens « métier ». Par exemple : je reçois un message correspondant à l’envoi d’une commande et la règle métier veut qu’une notification soit alors envoyée au client final.
• le déclenchement par Batch. Ce sont cette fois des événements qui ne dépendent pas directement de ce qui se passe en temps réel, mais d’un déclencheur externe. On utilise cette logique lorsque la notification dépend plutôt d’un calcul de délai. Par exemple, si on veut notifier un utilisateur final qu’il n’est pas allé retirer sa commande; ou encore qu’il a laissé des articles dans son panier…
• la gestion des erreurs. Je préfère le considérer comme un 3ème canal de déclenchement des notifications, car il me semble important de gérer au mieux les cas d’erreur… Du coup, autant prévoir dès la conception, le fait « d’attraper » les erreurs et de les faire rejouer automatiquement. Ceci permettra de gérer des cas fonctionnels particuliers (ex. des messages manquants ou dans le désordre) ou bien sûr, des erreurs techniques.

Chacun de ces cas, va entraîner le déclenchement du système de notification. Techniquement cela va se matérialiser par un message mis à disposition des briques d’envoi.

Les étapes d’envoi

Après avoir été déclenchées, toutes les notifications sont candidates à l’envoi. Elles passent, donc, dans le module d’envoi, où elles devront suivre plusieurs étapes :

1. Récupération des abonnements.  On vient enrichir les informations de la notification candidate avec les éventuelles informations du destinataire (ex. préférence d’abonnement, emails, etc…). 
2. Vérification de la cohérence. Ici, il s’agit d’assurer la logique entre l’événement déclencheur de la notification, les informations déjà disponibles et le cycle de vie prévu. Il faut notamment éviter de spammer ou de notifier à tort (ex. j’envoie une notification qui date d’hier…) et de n’envoyer qu’une seule fois une notification donnée.
3. Mapping des données à restituer aux clients. Ici, on récupère des champs des objets de référence. Si besoin, des systèmes externes sont appelés à la volée via des API ou des microservices. Ceci permettra par exemple d’enrichir la notification envoyée pour ajouter des taxes, préciser des horaires d’ouverture,…). Une fois ces données récupérées, on crée un objet JSON.  Ce dernier contient les données complémentaires ainsi que le(s) adresse(s) de contact (mail ou téléphone). Cet objet est transmis par API aux plateformes d’envoi.
4. Envoi de la notification via la ou les plateforme(s) d’envoi. La plateforme d’envoi par SMS, mail ou autre, récupère l’objet JSON et le traite. C’est elle qui se charge de l’exécution de l’envoi et récupère un accusé de réception qui peut être renvoyé au système de notification pour clore le processus.

A garder en tête pour un système de notification

Pour être efficace (et apprécié!) les notifications envoyées doivent suivre les règles essentielles :

1-  ne pas spammer le destinataire (par mail ou encore pire par SMS),

2-  être en cohérence dans la suite logique de chaque étape de la vie de l’objet, 

3-  émettre des relances sous forme de notifications en fonction des délais définis par le métier.

Dans notre cas, le recours à une architecture réactive permet de combiner l’approche temps réel avec des déclenchements régulier (type batch). Surtout, les systèmes réactifs sont élastiques par rapport à l’activité : ils ont vocation à traiter de forts volumes de données afin de garantir la disponibilité de l’application.

Ce qui est donc particulièrement pertinent pour un système de notification qui doit répondre 24h/24, 7 jours/7, quelle que soit l’activité!

(Merci à Jérémie qui a co-écrit cet article!)