Comment gérer les évènements d’intégration dans une architecture pilotée par les évènements ?

L’architecture pilotée par les évènements est un modèle d’architecture qui repose sur la gestion des évènements (enregistrement, publication, consommation, etc.). Elle est définie comme une architecture distribuée. En outre, les ressources ne se sont pas situées sur la même machine, ce qui lui permet d’assurer un couplage faible entre un consommateur et un producteur qui ignore comment les évènements publiés seront traités.

Par définition, un évènement est quelque chose qui s’est produit dans le passé. Il existe deux types d’évènements :

• Les évènements du domaine : ce sont des évènements qui se sont déroulés dans un même contexte métier délimité (Bounded Context). Selon la documentation Microsoft, « un évènement de domaine est quelque chose qui a eu lieu dans le domaine et dont vous voulez que les autres parties du même domaine (in-process) soient informées. Les parties notifiées réagissent généralement aux évènements ».
• Les évènements d’intégration : il s’agit des évènements qui permettent de propager les informations d’un contexte métier afin de notifier les systèmes externes. C’est le type d’évènement adressé dans une architecture distribuée.

Comment et sur quels critères publier un évènement d’intégration ?

Dans une architecture distribuée, un critère doit être rempli afin de publier un évènement d’intégration : l’« atomicité ». Il s’agit d’exécuter ses changements (ses instructions) jusqu’au bout. En cas d’interruption ou de défaillance, l’exécution doit être annulée et revenir à l’état antérieur afin d’éviter toute transaction partielle. Précisément, l’enregistrement de l’état d’un système (par exemple : persister une entité) et la publication d’un évènement d’intégration doivent être atomiques.

Or, pour une raison telle que l’indisponibilité du support de publication, nous nous exposons à une incohérence de données entre les différents systèmes.

Comme vous pouvez le constater, une fois la transaction terminée (Ligne 2) rien ne garantit la disponibilité du support de transport de l’évènement d’intégration (Ligne 8).

D’où l’intérêt de remplir ce critère d’atomicité afin de maintenir la cohérence des données.

Quelles mesures mettre en place pour renforcer l’atomicité ?

Plusieurs mesures peuvent renforcer cet aspect atomique, telles que :

• Le Change Data Capture
• L’OutBox Pattern
• L’Event Sourcing

Cette liste n’est pas exhaustive. Le but, ici, est de vous présenter une multitude de choix à considérer et que vous pouvez adopter selon votre contexte métier et projet.

Change Data Capture

Ce pattern d’intégration de données permet de suivre quand et quels changements de données se sont produits. Il permet, cependant, de récupérer ces informations et de les traiter afin de notifier un système externe.

Plusieurs systèmes de gestion de données implémentent ce pattern : c’est le cas de Microsoft SQL Server, PostgreSQL ou MySQL. Ils mettent à disposition un agent qui enregistre les activités de la base de données telles que les insertions, les suppressions ou encore les mises à jour.

Cette fonctionnalité est aussi disponible pour les bases de données NoSQL comme Cosmos via le « Change Feed ». Microsoft définit ainsi le Change Feed : « Le flux de modification dans Azure Cosmos DB est un enregistrement persistant des modifications apportées à un conteneur dans l’ordre dans lequel elles se produisent ».

Toutes ces modifications peuvent être capturées à travers une ou des « Azure Functions », afin de créer des évènements d’intégration qui seront publiés via un Azure Service Bus :

Néanmoins, si vous optez pour l’utilisation de ce pattern Change Data Capture, vous serez trop dépendant de l’infrastructure utilisée. Si vous décidez un jour de changer de système de gestion de base de données, il faudra repenser la solution. Ce qui peut être parfois problématique…

Outbox Pattern

L’Outbox Pattern (ou le modèle de la boîte d’envoi) est aussi un pattern d’architecture visant, de la même manière, à rendre l’enregistrement de l’état du système et la publication d’un évènement d’intégration atomiques.

Ce pattern fonctionne en deux temps :

• D’abord la sauvegarde de l’état du système et les évènements d’intégrations dans la base de données.
• Ensuite, la publication de ces évènements à travers un Thread/Process : le « Publisher ».

Une fois un évènement publié, son statut est modifié et marqué en tant que « lu ».

De la même façon, l’ Outbox pattern nécessite la mise en place de quelques actions. Ainsi, l’enregistrement des données et des évènements doit être fait dans une seule et même transaction :

Le but est ici de s’assurer qu’au moment où vous sauvegardez l’entité, vous sauvegardez aussi le ou les évènements à publier et qui y sont liés.

Certains outils intègrent ces fonctionnalités et ne nécessitent pas un développement spécifique. C’est le cas de CAP qui est “une bibliothèque basée sur .net standard, qui est une solution pour gérer les transactions distribuées. Il intègre également la fonction de bus d’évènement. Elle est légère, facile à utiliser et efficace.” (Source : documentation CAP)

Notons que le Publisher peut diffuser par erreur plusieurs fois un même évènement si jamais il n’arrive pas à mettre à jour son statut dans la base de données.

Par conséquent, le destinataire doit garantir une gestion idempotente de l’évènement d’intégration afin qu’aucun effet imprévu, tel que des doublons, ne soit causé par le traitement répété du même évènement.

Event Sourcing

Cette troisième approche tire profit de l’ « Event Sourcing » pour gérer les transactions distribuées. publier les évènements d’intégration. L’Event Sourcing est un pattern d’architecture qui enregistre tous les évènements métiers d’un système dans un Event Store. Cette approche représente une grande différence avec les bases de données classiques où l’on priorise l’enregistrement de dernier état.

En outre, l’état actuel du système n’est autre que le résultat d’une cumulation de ces évènements métier sauvegardés.

Parmi les Event Stores les plus utilisés sur le marché, il existe Eventstore et Martendb.io.

Chacun de ces Event stores permet l’observabilité à travers les souscriptions. Ce concept est similaire aux CDC (Change Data Capture) : chaque action dans le système, en l’occurrence l’enregistrement d’un évènement métier, émet des informations qui peuvent être utilisées soit pour :

• Mettre à jour les modèles de lectures
• Exécuter l’étape d’après dans un contexte de workflow
• Créer des évènements d’intégration afin de notifier les systèmes externes. Effectivement il faudra utiliser un support de transport afin de les publier.

Si l’Event Sourcing semble être la meilleure approche, celle-ci peut ne pas être appliquée sur tous les projets possibles et existants. Dans un contexte de legacy, il est fort probable que vous n’utilisez pas d’EventStore et il serait impossible d’en tirer profit.

Adopter et s’adapter…

Cette panoplie de solutions, qui peuvent remédier au problème d’atomicité, ne sont qu’un moyen à utiliser avec modération. Quelle que soit la solution adoptée, il existe des considérations à prendre en compte.

Aujourd’hui, une architecture (distribuée) pilotée par les évènements peut être primordiale ou parfois imposée, en raison des solutions existantes dans l’entreprise ou bien par la nature de la communication en interne.

Par conséquent, quelle que soit la solution que vous voulez adopter, il est primordial de prendre en considération le contexte dans lequel vous vous projetez pour faire votre choix. Ce contexte peut être influencé par l’infrastructure existante, le besoin métier ou même les besoins d’audit.

Vous souhaitez être accompagné par des experts dans vos projets de transformation numérique ? Contactez-nous !