Qu'est-ce que l'architecture pilotée par les événements ?
L'architecture pilotée par les événements (EDA) est un modèle d'intégration qui détecte les « événements » importants dans une entreprise, une transaction, par exemple, ou un panier abandonné, et qui prend des mesures en temps réel.
Architecture pilotée par les événements : présentation
Dans une entreprise, presque tous les événements présentent un caractère urgent. Lorsqu'un client effectue un achat en ligne, qu'un capteur signale un dysfonctionnement imminent, qu'une action baisse ou qu'une violation de sécurité est détectée, il faut prendre des mesures immédiates. C'est là que l'architecture pilotée par les événements est utile. Une EDA crée et détecte les événements, et y répond à mesure qu'ils se déroulent, ce qui permet aux entreprises de s'améliorer d'une manière générale : de l'expérience client à l'efficacité et l'agilité opérationnelles.
Qu'est-ce qu'un événement ?
Commençons dans un premier temps par quelques notions de base. Un événement est une action ou un changement d'état important pour une entreprise. Une personne qui effectue un paiement par carte de crédit, par exemple, s'enregistre pour un vol ou réinitialise un mot de passe, ou la mise à jour des stocks dans un entrepôt. Ces événements se produisent en permanence, dans toutes les entreprises et dans tous les secteurs. Une entreprise « pilotée par les événements » est une entreprise qui capture ces événements et y réagit au fur et à mesure.
Qu'est-ce qu'une architecture pilotée par les événements ?
Une architecture pilotée par les événements (EDA) est un modèle d'intégration conçu pour publier, capturer, traiter les « événements » et y répondre en temps réel dans des systèmes distribués. Lorsqu'un événement se produit dans une application, un message est automatiquement envoyé à toutes les autres applications qui doivent en avoir connaissance, afin qu'elles puissent à leur tour prendre des mesures en conséquence.
Les architectures basées sur les événements étant découplées, les applications n'ont pas besoin d'avoir connaissance les unes des autres pour partager des informations et exécuter des tâches. Les informations sur les événements, ou les messages, peuvent circuler librement et automatiquement entre les applications. Par conséquent, le modèle EDA est beaucoup plus rapide que le modèle demande/réponse traditionnel, dans lequel une application doit demander à une autre les informations spécifiques dont elle a besoin et attendre la réponse avant de passer à la tâche suivante. De plus, une EDA étant découplée, elle est généralement considérée comme une bonne pratique dans la communication de microservices.
Comment fonctionne une EDA ?
Dans une architecture pilotée par les événements, les applications jouent le rôle de producteurs d'événements (c'est-à-dire qu'elles produisent ou capturent des événements) ou de consommateurs d'événements (c'est-à-dire qu'elles traitent les événements et prennent des mesures en conséquence). Les producteurs transmettent en temps réel les événements aux consommateurs via un courtier, encore appelé middleware orienté messagerie. Les consommateurs peuvent ensuite traiter l'événement et déclencher leurs propres actions, workflows ou événements.
Dans une architecture très simple — où un seul diffuseur et un seul consommateur communiquent directement —, les courtiers sont facultatifs. Mais dans la plupart des entreprises, plusieurs sources envoient des événements à plusieurs consommateurs ; un courtier, voire un réseau de courtiers (également appelé « maillage d'événements ») est donc nécessaire. Lorsqu'un courtier ou un maillage d'événements est utilisé, il se crée un « couplage lâche » des applications.
Modèles d'architecture pilotée par les événements
La transmission d'événements dans une architecture pilotée par les événements se fait de deux manières principales : publication/souscription et flux d'événements.
Publication/souscription (« pub/sous ») – Avec le modèle pub/sous, les consommateurs d'événements s'abonnent aux messages et aux canaux publiés par les producteurs d'événements. Lorsqu'un événement est publié, il est directement envoyé à tous les abonnés via un courtier. Pour éviter les duplications, les événements ne peuvent pas être rejoués et ne sont plus accessibles une fois consommés ; ils sont supprimés par le courtier.
Flux d'événements – Avec le flux d'événements, les diffuseurs publient des flux d'événements entiers à un courtier. Les consommateurs s'abonnent au flux et peuvent le lire depuis n'importe où, en consommant uniquement les événements pertinents pour eux. Dans ce modèle, les événements sont conservés par le courtier même après leur consommation.
3 approches pour traiter les événements
Il existe trois approches de traitement des événements une fois qu'ils sont parvenus au consommateur : le traitement d'événement simple, le traitement d'événement complexe et le traitement de flux d'événements.
- Traitement d'événement simple : les consommateurs traitent chaque événement tel qu'il est reçu.
- Traitement d'événement complexe : les consommateurs traitent une série d'événements pour détecter les modèles et effectuer des actions en fonction du résultat.
- Traitement des flux d'événements : Les consommateurs traitent un flux constant de données (données mobiles) et prennent des mesures en temps réel à l'aide d'une plateforme de flux de données.
Les entreprises choisissent leur approche de traitement des événements en fonction de leurs besoins spécifiques et de leurs cas d'utilisation.
Cas d'utilisation et exemples d'architecture pilotée par les événements
Pour tous les secteurs, de la banque au Retail, il existe de nombreux cas d'utilisation pour les architectures pilotées par les événements. Voici un exemple tiré du secteur de la restauration :
Un étudiant commande une pizza sur une application de livraison de type Uber Eats. L'application capture ses informations de base (nom, adresse, informations de paiement et commande) et publie l'événement « commande de pizza ».
La pizzeria s'abonne à l'événement, traite la commande et publie son propre événement « commande prête » sur le service de livraison.
Ensuite, le service affecte un chauffeur-livreur, détermine l'heure d'arrivée prévue et avertit le client que sa pizza est en route.
Exemple d'EDA tiré du e-commerce :
Un client entre les informations de sa carte de crédit sur un site de e-commerce, qui publie l'événement « paiement soumis ».
Le système de paiement s'abonne à l'événement, traite le paiement et émet son propre événement « paiement traité », indiquant s'il a réussi ou échoué, puis le renvoie à l'IU du site Web.
L'IU affiche le statut du paiement au client et l'invite à suivre les étapes suivantes.
D'autres exemples d'EDA :
Un client en ligne clique sur un produit et le système répond en générant des recommandations de produits similaires
Un client dépose un chèque dans une banque et le système l'enregistre automatiquement sur son compte
Un détaillant surveille les transactions mondiales pour détecter les éventuelles fraudes et signale les achats suspects à la société émettrice de cartes de crédit
Un fabricant surveille les flux de données IoT émis par ses équipements et reçoit des alertes en cas de problèmes ou de défaillances de maintenance
Avantages d'une architecture pilotée par les événements
Une architecture basée sur les les événements offre de nombreux avantages. Les trois principaux sont les suivants :
- Workflows et réactivité en temps réel. Une EDA peut surveiller les événements et y réagir rapidement au fur et à mesure qu'ils se produisent, souvent à l'aide de l'automatisation robotisée des processus (RPA) pour accélérer les workflows et déclencher les étapes suivantes en temps réel. C'est une procédure particulièrement importante en période de pic de demande, par exemple lors de ventes importantes ou en période de fêtes. Cette réactivité peut également s'appliquer aux workflows quotidiens (en dehors des périodes de pic), ce qui améliore tous les processus, de l'automatisation de la Supply Chain à la détection des fraudes.
- Messagerie asynchrone. Les applications d'une EDA communiquent de manière asynchrone, c'est-à-dire que les producteurs publient des messages sur les événements sans attendre que les consommateurs les reçoivent. Non seulement cela permet aux applications de passer sans délai à d'autres tâches, mais en plus cela simplifie l'intégration.
- Découplage et couplage lâche. Découplées ou faiblement couplées, les applications d'une EDA ne dépendent pas de la disponibilité des autres. Elles peuvent être mises à jour, testées et déployées de manière indépendante. Elles peuvent aussi échouer de manière indépendante ; l'architecture est donc plus durable et persistante que les modèles traditionnels. De plus, le découplage facilite l'ajout d'éditeurs et de consommateurs selon les besoins, ce qui évite d'avoir à réécrire le code à chaque changement.
Conclusion
Le maillage d'événements offre des options de déploiement dans divers hyperscalers et dans des environnements cloud privés. Il peut être configuré pour former un maillage distribué de courtiers d'événements, déployés dans des environnements cloud privés ou publics. Le maillage d'événements offre un ensemble complet de services : flux d'événements, gestion des événements, surveillance, ainsi que des fonctionnalités avancées telles que le routage dynamique des messages et le filtrage fin.
Découvrir les fonctionnalités de maillage d'événements de SAP
Optimisez vos applications avec une architecture basée sur les événements de SAP Integration Suite.
Idées que vous ne trouverez nulle part ailleurs
Inscrivez-vous pour recevoir une dose de Business Intelligence directement dans votre boîte de réception.