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

système de notification

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

système de notification

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!)


Andrea Zerial

Les sujets qui m’intéressent le plus sont Data, Organisation et Temps Réel !

N’hésitez pas à me faire un retour sur cet article ou à me contacter sur LinkedIn pour partager nos actualités!

Andrea

Vous aimerez aussi ...

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Recevez nos articles

Recevez chaque mois par e-mail les derniers articles et livres blancs publiés, ainsi que des informations concernant l’actualité IT ! 

Livres blancs

Partagez nos articles

Rechercher

Rechercher

Vous faites partie des 10 000 visiteurs mensuels du blog !

Merci pour votre visite ! 

Restez informé.e des dernières tendances en vous inscrivant à notre newsletter mensuelle

une organisation rayonnante

Nous utilisons des cookies pour vous garantir la meilleure expérience sur notre site. Si vous continuez à utiliser ce dernier, nous considérerons que vous acceptez l’utilisation des cookies. Voir notre Politique de confidentialité.