Événements métiers Microsoft Dataverse

L’automatisation de la logique métier et l’intégration avec d’autres systèmes sont pilotées par des événements. Lorsque quelque chose d’intéressant se produit dans une application métier, un événement se produit et les données décrivant l’événement deviennent disponibles pour que les abonnés puissent y répondre. Microsoft Dataverse fournit des capacités pour relayer les données d’événements aux abonnés à l’aide des applications et technologies suivantes :

  • Flux Power Automate
  • Azure Service Bus
  • Azure Event Hub
  • Webhooks
  • Plug-ins Dataverse

Dataverse dispose d’un cadre d’événements robuste pour capturer les événements système dans Dataverse. Vous pouvez répondre à des événements dans le système à l’aide de l’infrastructure d’événements Dataverse. Cela ne change pas. Informations complémentaires, Infrastructure d’événements

Les événements métier Dataverse offrent de nouvelles façons d’exposer les événements et de composer votre logique métier pour y répondre de manière asynchrone, comme le déclencheur Power Automate Dataverse Lorsqu’une action est effectuée.

En voici quelques exemples :

  • Vous avez une logique que vous souhaitez appliquer lorsqu’une opération de partage est effectuée sur un enregistrement appartenant à l’utilisateur. La seule façon d’initier la logique à ce message GrantAccess qui se produit lorsqu’un enregistrement est partagé est via l’infrastructure d’événements Dataverse, généralement via un plug-in. Avec les événements d’entreprise, vous pouvez cataloguer le tableau qui exposera le message GrantAccess.

  • Un développeur de plug-in peut avoir une logique dans un code de plug-in synchrone qui répond à un certain ensemble de conditions qu’il transmet aux variables partagées pour qu’un autre plug-in asynchrone initie une automatisation. Avec un événement commercial, au lieu de transmettre ces détails via les variables partagées du pipeline d’événements, vous pouvez appeler une action personnalisée contenant les détails de l’événement dans les paramètres. Un plug-in asynchrone peut alors répondre à l’action personnalisée, ou vous pouvez choisir d’utiliser Power Automate plutôt. Une autre logique peut également être ajoutée pour répondre à cet événement. Ce modèle offre une plus grande flexibilité et une opportunité de simplifier la logique dans votre code de plug-in.

Catalogues et événements personnalisés

Événements métiers Dataverse comprend les concepts des Événements métiers Dynamics Finance et Opérations avec l’infrastructure d’événements Dataverse pour fournir une nouvelle façon de découvrir les événements et de créer une automatisation lorsque ces événements se produisent.

  • Catalogue d’événements : Avec autant d’événements disponibles dans le système, il peut être difficile de trouver le bon. Un catalogue d’événements améliore la découverte d’événements en associant des événements à une solution et en organisant les événements en catégories.

    Un catalogue ne comprend que des événements sélectionnés et de grande valeur pertinents pour la solution. L’ajout d’un événement à un catalogue est la façon dont vous exposez l’événement.

  • Événements personnalisés : vous pouvez créer des actions personnalisées pour être des événements personnalisés, car Dataverse les traitera à l’aide de son cadre d’événements.

    Ces événements peuvent ou non représenter des changements de données dans Dataverse. Vous pouvez utiliser des API personnalisées sans aucune logique synchrone qui existe uniquement pour informer les auditeurs qu’un événement d’intérêt s’est produit. Vous émettez l’événement en appelant l’action personnalisée.

Catalogue d’événement

Pour exposer un événement d’entreprise, il doit être catalogué. Plus d’information : Tables Catalog et CatalogAssignment

Un catalogue facilite la découverte de l’événement commercial, car ils sont regroupés par la solution conteneur et les catégories définies pour cette solution. L’éditeur de solutions sélectionne les événements les plus pertinents pour leur solution.

Un Catalogue est une structure hiérarchique où le niveau supérieur représente une solution. Ensuite, le niveau suivant est une Catégorie. Les tables et événements pertinents sont ensuite affectés à une catégorie.

Par exemple, ce qui suit représente un catalogue pour une solution appelée Gestion des clients Contoso :

  • Gestion des clients Contoso
    • Tables
      • Account
      • Contact
      • Affiliation
    • Événements client
      • Magasin visité
      • Aller sur le site web
      • Produit acheté
      • Retour produit

Cet exemple utilise les tables et Événements clients en tant que catégories, mais vous pouvez utiliser n’importe quel regroupement de catégories qui convient à votre solution.

Si votre solution se compose de plusieurs solutions dépendantes, vous pouvez définir le catalogue racine dans la solution de base, puis ajouter des catégories supplémentaires et des événements affectés aux solutions dépendantes qui les ajoutent.

Événements de table

Lorsqu’une table est affectée à une catégorie, certaines opérations liées à la table seront incluses. Vous ne pouvez pas sélectionner chaque opération individuellement. Si la table prend en charge les opérations de création, de mise à jour et de suppression, ces événements seront inclus.

Des événements supplémentaires liés à d’autres opérations seront également inclus. Par exemple, si la table appartient à l’utilisateur, elle participe aux événements de sécurité. Le propriétaire de n’importe quel enregistrement de la table pourra le partager, modifier les capacités de partage ou arrêter de partager l’enregistrement. Les opérations liées au partage sont exposées comme événements GrantAccess, ModifyAccess, et RevokeAccess. Des événements supplémentaires peuvent également être inclus en fonction de la table. Si la table est une table virtuelle et qu’elle a été configurée pour prendre en charge les événements de table virtuelle, les événements OnExternalCreated, OnExternalUpdated, OnExternalDeleted seront inclus. Plus d’information : Activer les tables virtuelles pour prendre en charge des événements Dataverse

Ajoutez uniquement les tables contenant des données commerciales susceptibles d’intéresser les abonnés. Vous ne devriez pas essayer d’inclure chaque table.

La même table peut être incluse dans plusieurs catalogues. Par exemple, si votre solution dépend des données client dans les tables Compte ou Contact Dataverse, vous devez les inclure. D’autres catalogues peuvent inclure des tableaux de votre solution.

Événements personnalisés

Utilisez l’API personnalisée Dataverse pour créer des événements personnalisés. Chaque API personnalisée créera un message Dataverse et fournissez le point de terminaison de service web pour appeler l’API personnalisée. Pour plus d’informations, voir : Créer et utiliser des API personnalisées.

Les événements commerciaux personnalisés ne peuvent envoyer des notifications que lorsqu’un événement est terminé. L’infrastructure d’événements Dataverse fournit des capacités pour inclure une logique synchrone qui peut annuler une opération ou modifier la sortie afin que vous puissiez étendre le comportement du système. Bon nombre des mêmes messages exposés avec des événements commerciaux peuvent être étendus à l’aide d’une logique synchrone dans l’infrastructure d’événements Dataverse, mais les notifications d’événements commerciaux ne se produisent que lorsque ces opérations se terminent avec succès.

Par exemple, vous pouvez avoir une API personnalisée qui encapsule un ensemble d’opérations qui représentent un processus métier, comme Réaffecter, qui changera la propriété d’un enregistrement à un autre en fonction de certains critères. Ou alors Remonter au support qui augmentera l’état de priorité d’un enregistrement et créera des tâches associées supplémentaires. Lorsque vous utilisez une API personnalisée de cette manière, vous définissez de nouveaux événements susceptibles d’intéresser les abonnés. Si ces opérations se terminent avec succès, une logique asynchrone peut être déclenchée sur eux.

Vous pouvez également créer une action personnalisée uniquement pour permettre aux abonnés d’y répondre. Les Événements externes décrit un cas particulier où des événements ont pour origine Dataverse, mais vous pouvez créer une API personnalisée en tant qu’événements à utiliser dans Dataverse ainsi en utilisant les mêmes paramètres. Si votre action personnalisée est destinée uniquement aux abonnés, nous recommandons que le nom de votre action personnalisée commence par On, tel que OnCustomerPurchase ou alors OnVendorPaymentPosted.

L’API personnalisée peut être utilisée à de nombreuses fins différentes, toutes ne sont pas liées à des opérations qui représentent des événements intéressants pour la logique métier. C’est pourquoi les événements d’entreprise doivent être catalogués. Le propriétaire de la solution qui contient l’API personnalisée ne doit cataloguer que les API personnalisées qui représentent des événements de grande valeur. Vous ne devez pas essayer de cataloguer chaque action personnalisée incluse dans votre solution.

Principes de conception

Lorsque vous envisagez de cataloguer des API personnalisées en tant qu’événements métier dans votre solution, utilisez les principes de conception suivants.

  • Intention claire : L’intention sous-jacente derrière la création d’un événement commercial doit être clairement comprise. En d’autres termes, quelle est la raison de la création de l’événement d’entreprise, et comment sera-t-il utilisé par l’abonné ?

  • Spécifique : L’événement doit être spécifique afin qu’un abonné n’ait pas besoin de filtrer s’il doit ou non y répondre. Ne créez pas d’événements commerciaux génériques auxquels les abonnés peuvent ne pas toujours répondre.

  • Léger : L’événement ne doit contenir que les données nécessaires pour décrire l’événement. Si l’abonné a besoin de données supplémentaires, les informations de l’événement doivent fournir le contexte pour lui permettre de les récupérer si nécessaire.

  • Pas pour transférer des données : Si votre intention est de transférer des données vers un destinataire et, en fait, de réaliser un scénario d’exportation de données, vous n’avez pas de bon cas d’utilisation pour les événements commerciaux. En fait, l’utilisation d’événements commerciaux pour les scénarios de transfert de données est une mauvaise utilisation des événements commerciaux.

Actions du processus personnalisé

La notion de Action personnalisée comprend à la fois l’API personnalisée et les actions de processus personnalisé. Ils créent tous les deux une API, mais la façon dont ils le font est différente. Pour les événements commerciaux personnalisés, nous recommandons l’API personnalisée.

Les actions de processus personnalisées peuvent également être cataloguées en tant qu’événements commerciaux. C’est pour la compatibilité descendante si votre solution utilise déjà des actions de processus personnalisées pour encapsuler une logique métier qui représenterait un événement métier. Vous n’êtes pas obligé de migrer cette action personnalisée pour utiliser l’API personnalisée.

Cependant, les actions de processus personnalisées présentent les limitations suivantes :

  • Comme tout workflow, ils peuvent être désactivés dans l’interface utilisateur. Vous ne pouvez pas savoir quand quelqu’un désactive votre action de processus personnalisé jusqu’à ce qu’il cesse soudainement de fonctionner.
  • Jusqu’à récemment, il n’y avait aucun moyen d’empêcher l’enregistrement d’étapes de plug-in synchrones sur des actions de processus personnalisés, ce qui signifie que n’importe qui pouvait enregistrer des étapes synchrones susceptibles de modifier le comportement de l’action de processus personnalisé ou même de l’annuler. Il y a maintenant une propriété gérée IsCustomProcessingStepAllowedForOtherPublishers qui permet à une action de processus personnalisé de bloquer cela. Mais si vous envisagez de mettre à jour votre action de processus personnalisé pour définir cette propriété, vous devriez envisager de la convertir pour utiliser l’API personnalisée à la place.

Pour plus d’informations sur leurs différences, consultez Comparer l’action de processus personnalisé et l’API personnalisée

Si votre action de processus personnalisé ne contient aucune logique dans le concepteur de workflow et s’appuie uniquement sur des plug-ins pour effectuer des opérations, vous pouvez probablement migrer l’action de processus personnalisé vers une API personnalisée pour atténuer ces problèmes.

La communauté Power Platform a déjà créé des outils pour aider à cela. Voir le Plugin XrmToolBox Convertisseur d’action personnalisée en API personnalisée.

Notes

Les outils créés par la communauté ne sont pas pris en charge par Microsoft. Si vous avez des questions ou des problèmes avec les outils de la communauté, contactez l’éditeur de l’outil.

Événements externes

Les événements personnalisés peuvent représenter des événements qui se produisent dans des systèmes externes. Les événements qui se produisent dans les systèmes externes sont déjà terminés.

Les API personnalisées créées pour les événements externes doivent s’aligner sur ces principes :

  • Ils ne doivent pas avoir de type de plug-in spécifié pour l’opération principale.
  • Ils ne doivent pas autoriser les enregistrements d’étapes synchrones.
  • Ils ne doivent avoir aucune propriété de réponse, uniquement des paramètres de requête.
    • Sans logique synchrone, il n’y a aucun moyen de définir les propriétés de réponse.

Notes

Ces paramètres ne concernent pas uniquement les événements qui se produisent en dehors de Dataverse. L’API personnalisée peut être utilisée avec ces paramètres pour représenter les événements qui se produisent dans Dataverse également.

Exemples

Comparons deux exemples d’événements externes :

Scénario A : OnCustomerPurchase

Vous disposez d’une application point de vente et un achat client est un événement important que vous souhaitez immortaliser. Vous souhaitez peut-être leur envoyer un e-mail pour les remercier de leur achat, et vous souhaitez stocker des informations sur le montant total que le client a dépensé en Dataverse. Vous pouvez définir une API personnalisée OnCustomerPurchase dans Dataverse. Votre application de point de vente peut envoyer des informations sur cet événement à Dataverse. Dans Dataverse, vous souhaitez mettre à jour un enregistrement avec le total. Ensuite, vous voulez utiliser Power Automate pour envoyer un e-mail les remerciant pour leur achat.

Il peut sembler plus efficace d’implémenter la logique pour calculer le total et mettre à jour l’enregistrement dans une opération principale de l’API personnalisée. Mais l’introduction de la logique synchrone de cette manière introduit la possibilité que la logique échoue et renvoie une erreur à l’application de point de vente qui l’appelle. Étant donné que l’événement s’est déjà produit, il n’est pas nécessaire d’exécuter une logique synchrone qui pourrait provoquer le appel Dataverse à l’échec. Au lieu de cela, dépendez de Power Automate pour inclure toute la logique ou inclure une autre étape de plug-in asynchrone sur l’événement OnCustomerPurchase pour mettre à jour l’enregistrement dans Dataverse.

Scénario B : OnVendorPaymentPosted

Vous avez une application ERP a un événement OnVendorPaymentPosted et vous voulez simplement simplifier la façon dont vous centralisez votre logique d’automatisation. Vous pouvez créer une API personnalisée représentant cet événement externe et configurer l’application ERP pour l’appeler l’API Dataverse. Lorsque vous cataloguerez cette API personnalisée en tant qu’événement, vous pourrez utiliser le connecteur Dataverse Power Automate pour utiliser cet événement comme déclencheur.

Cet exemple n’attend rien à faire dans Dataverse sauf permettre à la logique asynchrone d’être enregistrée pour l’événement.

Appel de l’API personnalisée à partir d’applications externes

L’exigence clé pour utiliser l’API personnalisée pour envoyer des événements commerciaux est que votre application doit avoir la capacité de faire des requêtes HTTP autorisées à Dataverse. Pour l’autorisation, les demandes provenant d’autres applications utiliseront généralement un compte d’utilisateur d’application spécial qui doit être créé dans l’environnement Dataverse. Les utilisateurs Dataverse sous licence et authentifiés peuvent également utiliser des applications pour envoyer ces demandes.

En supprimant toute la logique synchrone de l’API personnalisée, la probabilité qu’une erreur entraîne l’échec de l’opération est extrêmement faible, mais pas impossible. Votre application appelante doit fournir un moyen de traiter les erreurs passagères dans le cas où le service Dataverse ne répond pas, il y a des problèmes de connectivité réseau ou des erreurs de limite de protection de service sont renvoyées.

Pour activer les appels autorisés vers Dataverse à partir de votre application, il doit y avoir un utilisateur de l’application configuré pour l’environnement Dataverse. Pour plus d’informations : Créer des applications web en utilisant l’authentification de serveur à serveur (S2S).

Utilisez les événements commerciaux pour déclencher l’automatisation

À mesure que les événements commerciaux deviennent un modèle courant, il y aura plusieurs façons d’activer l’automatisation.

La première expérience où les événements d’affaires sont exposés est dans le connecteur Power Automate Dataverse à l’aide du déclencheur Quand une action est effectuée.

Déclencheur Lorsqu’une action est exécutée.

Dans cette expérience, les événements de création, de mise à jour et de suppression ne sont pas affichés pour les événements de table. Ces événements sont déjà disponibles via le déclencheur Lorsqu’une ligne est ajoutée, modifiée ou supprimée.

Voir aussi

Tables Catalogue et CatalogAssignment
Activer les tables virtuelles pour prendre en charge des événements Dataverse

Notes

Pouvez-vous nous indiquer vos préférences de langue pour la documentation ? Répondez à un court questionnaire. (veuillez noter que ce questionnaire est en anglais)

Le questionnaire vous prendra environ sept minutes. Aucune donnée personnelle n’est collectée (déclaration de confidentialité).