Skip to main content

Comprendre l'architecture logicielle orientée événement

Objectifs de formation

Une fois cette unité terminée, vous pourrez :
  • Dresser la liste des composants d’une architecture logicielle basée sur les événements.
  • Expliquer les avantages d'une architecture logicielle orientée événements.
  • Présenter des cas d'utilisation des événements de plate-forme.
  • Décrire les caractéristiques d'un événement de plate-forme.

Avant de commencer ce module

Nous savons que vous êtes impatient de commencer ! Toutefois, avant de vous lancer dans ce module, vous devez être à l’aise avec certains concepts pour parvenir à le terminer. 

Ce module vous apprend comment publier des événements de plate-forme à l’aide d’Apex, de l’API REST, des flux et des processus. Il vous propose également de vous abonner à des événements de plate-forme à l’aide de déclencheurs Apex, de flux, de processus, d’un composant Lightning, d’un outil s’appuyant sur CometD et de l’API Pub/Sub. Afin de pouvoir comprendre ce module, vous devez connaître au moins une de ces technologies. Pour être en mesure de relever le défi pratique de ce module, vous devez disposer de connaissances sur les déclencheurs Apex. Voici une liste de parcours et de modules que vous pouvez suivre pour découvrir Apex.

De plus, la connaissance des concepts de l’API Streaming (CometD) et de l’API Pub/Sub est utile pour ce module, bien que non obligatoire. 

Comprendre l'architecture logicielle orientée événement

Votre système de commande a-t-il expédié un colis ? Est-ce que votre imprimante a besoin de nouvelles cartouches d'encre ? Quelle que soit la notification que vous souhaitiez recevoir, la plate-forme de messagerie d'entreprise Salesforce assure la livraison de notifications personnalisées sécurisées et évolutives, au sein de Salesforce et issues de sources externes. Avec les événements de plate-forme, vous pouvez surveiller vos systèmes et communiquer les modifications à d'autres systèmes.

Le paradigme d'une communication orientée événement s'articule autour d'un modèle producteur-souscripteur : un émetteur diffuse un message qui est capté par un ou plusieurs récepteurs. C'est le même principe que la transmission par radio : une tour émettrice diffuse un signal radio et les récepteurs le captent s'ils sont sur la bonne fréquence.

Toujours comme dans transmission radio, la communication orientée événement circule de l'émetteur au récepteur. Les événements sont envoyés que les récepteurs les écoutent ou non, et les récepteurs n'accusent pas réception des événements. La communication orientée événement a lieu en temps réel ou, plus précisément, en quasi-temps réel. Les ondes radio voyagent à la vitesse de la lumière, mais les systèmes logiciels et matériels orientés événements présentent généralement une certaine latence. 

Dans le module Trailhead Bases de l’API de la plate-forme, nous faisons une analogie avec le radar d’un bateau pirate pour représenter la détection des événements. Cette analogie fonctionne bien pour la diffusion des événements de capture des données de modification, qui sont fondés sur la modification des enregistrements Salesforce. Ce modèle de communication ne nécessite qu'un souscripteur. Mais dans le cas des événements de plate-forme, la communication fait intervenir deux parties : un émetteur et un récepteur. Une architecture orientée événement comprend deux composants.

Composants des systèmes orientés événements

Avant d'aller plus loin, définissons quelques termes.

Événement
Changement d’état d’une importance significative dans un processus commercial. Par exemple, la création d’une commande est un événement significatif, car le centre de traitement des commandes s’attend à recevoir une notification avant de traiter une commande.

Message d’événement
Message contenant des données sur l’événement. On appelle aussi cela une notification d'événement. Par exemple, un message d’événement peut être une notification de création de commande contenant des informations à son sujet.

Producteur d’événements
Source de publication d’un message d’événement. Il peut par exemple s’agir d’une application de création de commande.

Canal d’événements
Flux d’événements via lequel un producteur d’événements envoie des messages d’événement et les consommateurs d’événements lisent ces messages. Pour les événements de plate-forme, le canal s’applique à un seul événement de plate-forme ou à un canal personnalisé qui regroupe les messages d’événement de plusieurs événements de plate-forme.

Consommateur d’événement
Abonné à un canal qui reçoit des messages par ce biais. Il peut s'agir d'une application d'exécution de commande à notifier en cas de nouvelle commande.

Bus d’événement
Service de stockage et de distribution d’événements mutualisé et multicloud basé sur un modèle Publish-Subscribe (publication-abonnement). Le bus d’événements permet la récupération de messages d’événement stockés à tout moment pendant la période de rétention. Le bus d’événements repose sur un journal d’événements classés chronologiquement, qui garantit que les messages d’événement sont stockés et distribués dans l’ordre dans lequel ils sont reçus par Salesforce.

Le schéma ci-dessous illustre une architecture logicielle basée sur les événements.

Contrairement aux modèles de communication demande-réponse, une architecture logicielle bâtie selon un modèle orienté événement dissocie les producteurs d'événements des consommateurs d'événements, ce qui simplifie le modèle de communication dans les systèmes connectés. Aucune demande n'a besoin d'être transmise à un serveur pour obtenir des informations sur un état donné. À la place, un système souscrit à un canal d'événements et il est informé à chaque fois qu'un nouvel état survient. N'importe quel nombre de consommateurs peut recevoir et répondre aux mêmes événements. Lorsqu'un événement se produit, les systèmes obtiennent ces informations et peuvent y réagir quasiment en temps réel. Les systèmes qui envoient des événements et ceux qui les reçoivent ne dépendent pas les uns des autres, excepté au niveau de la sémantique du contenu du message.

La plate-forme de messagerie d'entreprise Salesforce offre tous les avantages d'une architecture logicielle orientée événements. Les événements de plate-forme sont les messages d'événement que vos applications envoient et reçoivent. Ils simplifient le processus consistant à communiquer des changements et à y répondre sans vous demander de rédiger une logique complexe. Les producteurs et les souscripteurs communiquent les uns avec les autres via les événements de plate-forme. Plusieurs souscripteurs peuvent écouter le même événement et accomplir des opérations.

Imaginons qu'une agence de presse appelée Cloud News envoie à ses clients abonnés des événements concernant les dernières informations sur l'état de la circulation et des routes dans une station de haute montagne. Le contenu de ces événements ne se limite pas à la nouvelle elle-même : il inclut également des informations comme son degré d'urgence et la localisation de l'incident. Les abonnés reçoivent ces événements et peuvent déterminer les mesures à prendre, sur la base de l'urgence de la nouvelle.

Tout cela semble parfait, mais quelles sont les applications de ces événements de plate-forme dans le monde réel ? L'utilisation des événements de plate-forme ne se limite naturellement pas aux agences de presse. Voici quelques applications utiles.

Exemples d'utilisation des événements de plate-forme

Examinons quelques scénarios faisant usage des événements de plate-forme. Dans ces scénarios, Salesforce et les systèmes externes communiquent au moyen de messages d'événements de plate-forme. Dans le premier scénario, une application de Salesforce informe les applications externes d'exécution de commande d'un ordre d'expédition de produit. Dans le deuxième scénario, une application produit externe informe Salesforce d'un retour de marchandise. Le dernier scénario explique comment les messages d'événement sont utilisés dans Salesforce à l'aide de déclencheurs.

Plate-forme vers application externe : Exécution d'une commande dans l'application d'un fournisseur

Lorsqu’une opportunité est fermée comme gagnée dans Salesforce, votre entreprise a obtenu un contrat avec un client. Imaginons que vous ayez recours à des fournisseurs pour expédier des produits associés à une opportunité. Chaque fournisseur possède une application externe qui traite les ordres d’expédition pour des produits spécifiques. L'application externe écoute les événements de plate-forme. Lorsqu'une opportunité se ferme, un déclencheur, qui fait partie d'une application de commande de produit dans Salesforce, publie un message d'événement de plate-forme. Chaque application de fournisseur est informée de l’événement. Le fournisseur responsable de l’expédition du produit spécifique crée l’expédition.


Application externe vers application de la plate-forme : Traitement des retours de marchandise dans Salesforce

Imaginons que quelqu'un souhaite retourner un produit acheté à un fournisseur. Un système externe envoie les demandes de retour marchandise à Salesforce afin qu'elles soient traitées. Le système externe publie un événement de plate-forme pour avertir Salesforce du retour marchandise. Un déclencheur Salesforce écoute l'événement, le reçoit et accomplit certaines opérations. Par exemple, le déclencheur peut avertir le représentant commercial du retour et envoyer un e-mail de confirmation au client.


Plate-forme à plate-forme : Réaffectation d'enregistrements de pistes

Quand une piste est affectée dans Salesforce, un déclencheur vérifie les requêtes et les opportunités ouvertes associées au propriétaire de la piste. Selon les enregistrements associés, le déclencheur publie un événement qui est reçu par l'application Salesforce. Selon les informations contenues dans l'événement, l'application réaffecte la piste et crée une publication Chatter.

Dans ce scénario, vous pouvez effectuer les mêmes actions en utilisant Flow Builder. Mais en utilisant les événements de plate-forme, vous bénéficiez du modèle de programmation orienté événement et d'une méthode de programmation standard sur l'ensemble de vos applications.


Caractéristiques des événements de plate-forme

Maintenant que vous savez quand utiliser les événements de plate-forme, plongeons-nous un peu dans leurs composants et leurs caractéristiques.

Vous définissez les données personnalisées contenues dans les événements de plate-forme. Tout comme dans le cas des objets personnalisés, les événements de plate-forme sont définis dans Salesforce. Vous créez une définition d'événement de plate-forme en lui donnant un nom et en ajoutant des champs personnalisés. Voici un exemple de définition de champs personnalisés pour un événement d'actualité de l'agence Cloud News.

Nom/étiquette de champ Nom d'API du champ Type de champ
Location Location__c Longueur
de texte : 100
Urgent Urgent__c Case à cocher
News Content News_Content__c Zone de texte (longue)

Événements de plate-forme et objets Salesforce

Un événement de plate-forme est un type spécial d’entité Salesforce, similaire à un objet Salesforce à de nombreux égards. Un message d’événement est une instance d’un événement de plate-forme, de la même façon qu’un enregistrement est une instance d’objet Salesforce. Contrairement aux enregistrements, vous ne pouvez pas modifier ni supprimer un message d’événement, ni en afficher dans l’interface utilisateur de Salesforce.

Vous pouvez créer des autorisations de lecture et de création pour les événements de plate-forme. Les autorisations sont accordées aux utilisateurs via des profils ou des ensembles d'autorisations.

Utiliser les événements de plate-forme dans les applications natives et externes

Les événements de plate-forme permettent de faire circuler des messages d'événement au sein de Salesforce, mais aussi vers et depuis des applications externes. Les applications de la plate-forme Salesforce utilisent une méthode Apex pour publier des événements et un déclencheur Apex ou le composant Lightning API Emp pour les consommer. Comme alternative au code, vous pouvez publier des événements avec l’outil déclaratif Flow Builder. Les applications externes publient des événements à l’aide de l’API sObject ou de l’API Pub/Sub, et consomment des événements à l’aide de CometD ou de l’API Pub/Sub. Comme vous pouvez le voir, les possibilités d'utilisation des événements de plate-forme sont nombreuses !

Utilisez les événements de plate-forme aux fins suivantes :

  • Pour envoyer et recevoir des données d’événement personnalisé avec un schéma prédéfini
  • Pour publier des événements ou y souscrire dans Apex
  • Pour plus de souplesse dans la publication et le traitement des événements au sein de la plate-forme Salesforce comme en dehors

Remarque

Parmi les types d’événement de diffusion, citons également l’événement de capture des données de modification. Cet événement contient des modifications d’enregistrements Salesforce correspondant à des opérations de création, de mise à jour, de suppression et de restauration.  Pour plus d’informations, consultez le module Trailhead Fondamentaux de la capture des données de modification. Pour consulter une comparaison des types d’événements, reportez-vous à la section Fonctionnalités des événements de diffusion en continu du guide du développeur de l’API Streaming.

Dans la prochaine unité, nous verrons comment définir un événement de plate-forme et publier des événements.

Formez-vous gratuitement !
Créez un compte pour continuer.
S'inscrire Se connecter
Qu’est-ce que vous y gagnez ?
  • Obtenez des recommandations personnalisées pour vos objectifs de carrière
  • Mettez en pratique vos compétences grâce à des défis pratiques et à des questionnaires
  • Suivez et partagez vos progrès avec des employeurs
  • Découvrez des opportunités de mentorat et de carrière
Ignorer pour l'instant