Suivez votre progression
Accueil Trailhead
Accueil Trailhead

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 et d’un outil s’appuyant sur CometD. 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, il est utile de se familiariser avec les concepts de l’API Streaming pour suivre ce module. Si ce n’est pas déjà fait, suivez le module Bases de l’API de la plate-forme Lightning avant de travailler sur celui-ci.

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 Bases de l’API de la plate-forme Lightning, nous employons 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 d'événements PushTopic, qui sont basé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.

Evènement
Changement d’état d’une importance significative dans un processus commercial. Par exemple, la création d'un bon de commande est un événement pertinent parce que le centre d’exécution 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 sur un canal. Il peut s'agir d'une application de création de commande.

Canal d’événements
Flux d’événements via lequel un producteur d’événement envoie des messages d’événement lus par des consommateurs d’événements.

Consommateur d’événements
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.

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

Un schéma présentant les composants des systèmes orientés événements : producteurs d'événements, qui envoient des informations dans le bus d'événements, qui envoie les messages aux consommateurs d'é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 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. 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 et crée un ordre d'expédition pour le produit concerné.

Dans ce schéma, une application de commande publie un événement de commande sur un bus d'événements. Différentes applications de fournisseurs sont abonnées au bus et reçoivent l'événement.

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.

Une application externe d'un fournisseur publie un message d'événement de plate-forme concernant une demande de retour marchandise. Dans Salesforce, un déclencheur abonné au bus d'événements reçoit l'événement.

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 accomplir les mêmes actions en utilisant d'autres fonctionnalités de Salesforce comme le Générateur de processus ou les flux. 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.

Dans ce schéma, une application de Salesforce publie un événement de plate-forme. Un déclencheur abonné au canal d'événements reçoit l'événement.

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 sObjects

Un événement de plate-forme est un type spécial d’entité Salesforce, similaire à sObjects à 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 personnalisé. Contrairement aux objets personnalisés, vous ne pouvez pas modifier ni supprimer un enregistrement 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 empApi pour les consommer. Comme alternative au code, vous pouvez publier des événements à l’aide d’outils déclaratifs comme le Générateur de processus et Flow Builder. Les applications externes, elles, publient des événements à l’aide de l’API sObjects et consomment des événements à l’aide de CometD. Comme vous pouvez le voir, les possibilités d'utilisation des événements de plate-forme sont nombreuses !

Différences entre les événements de plate-forme et les autres événements de diffusion

Quels sont les autres événements de diffusion ? Il s’agit notamment des événements PushTopic et des événements génériques. Avec les événements PushTopic, les clients reçoivent des messages concernant les modifications des enregistrements Salesforce selon une requête prédéfinie. Avec les événements génériques, vous pouvez envoyer et recevoir des contenus de message arbitraires qui ne sont pas nécessairement liés à des enregistrements Salesforce. Les événements de plate-forme sont similaires aux événements génériques, mais offrent des options de personnalisation plus puissantes. Avec les événements de plate-forme, vous pouvez publier tout type de données personnalisées. Vous définissez le schéma des données d'événement à un niveau granulaire en tant que champs typés. De plus, vous pouvez utiliser les événements de plate-forme dans les applications Salesforce natives comme dans les applications externes. Utilisez les événements de plate-forme dans les situations 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

Ce tableau compare les caractéristiques des événements génériques et des événements de plate-forme.

Fonctionnalité Événement générique Événement de plate-forme
Définir un schéma d'événement en tant que champs typés
Coche
Inclure des contenus définis par l’utilisateur Coche Coche
Publier des événements via une ou plusieurs API Coche Coche
Publier des événements via Apex
Coche
Souscrire via CometD Coche Coche
Souscrire via des déclencheurs Apex
Coche
Publier de manière déclarative à l’aide du Générateur de processus et de Flow Builder
Coche
Remarque

Remarque

Pour consulter une comparaison entre un nombre plus important de 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.