Implémenter le modèle de boîte d'envoi transactionnelle avec Dataverse

Les solutions d’entreprise doivent acheminer de manière fiable des messages lorsque des modifications de données se produisent dans Dataverse. Cette architecture de référence montre comment implémenter le modèle Outbox transactionnel avec Dataverse pour réduire le risque de perte de messages et aider à synchroniser les systèmes intégrés.

Tip

Cet article fournit un exemple de scénario et un exemple d’architecture généralisé pour illustrer comment implémenter la distribution d’événements fiable à partir de Dataverse. L’exemple d’architecture peut être modifié pour de nombreux scénarios et secteurs différents.

Diagramme d’architecture

Diagramme d’architecture montrant comment Dataverse implémente le modèle Outbox transactionnel en stockant les enregistrements Outbox dans la même transaction que les modifications de données métiers et la publication de messages dans Azure Service Bus pour le traitement en aval.

Flux de travail

Les étapes suivantes décrivent le workflow illustré dans l’exemple de diagramme d’architecture :

  1. Une opération de données dans Dataverse se produit, telle que la création ou la mise à jour d’un enregistrement Contact. Cette opération crée une transaction de base de données.
  2. Un plug-in synchrone Dataverse se déclenche en réponse à cet événement et crée un enregistrement dans une table de boîte d’envoi dans Dataverse dans le cadre de la même transaction.
  3. Si le plug-in s’exécute correctement, la transaction valide à la fois l’enregistrement de la boîte d’envoi et les modifications apportées à l’enregistrement d’origine (par exemple, Contact).
  4. Si l’exécution du plug-in échoue, l’événement de données d’origine est annulé et Dataverse ne valide aucune modification des enregistrements.
  5. Un plug-in asynchrone se déclenche lors de la création d’un enregistrement dans la table de boîte d’envoi de Dataverse et écrit un message dans une file d’attente ou une rubrique Azure Service Bus.
  6. Un consommateur de messages écoute les messages à traiter et à envoyer (push) à un système cible.

Components

Dataverse est le système transactionnel source d’enregistrement où se produit l’événement de données et où se trouve la table d’envoi. Il envoie de façon asynchrone des messages au répartiteur de messages à l’aide d’un plug-in.

Azure Service Bus est le courtier de messages d’entreprise fiable qui reçoit des messages de Dataverse pour traitement par les systèmes récepteurs.

  • Les files d’attente sont idéales lorsqu’un message n’a qu’un seul destinataire.
  • Les rubriques sont particulièrement adaptées lorsque plusieurs abonnés sont susceptibles de traiter le même message ou ont besoin de critères de filtrage pour traiter les messages de manière sélective.

Azure Monitor est une solution de supervision complète permettant de collecter, d’analyser et de réagir aux données de supervision à partir de solutions cloud et locales. Utilisez des métriques intégrées pour Azure Service Bus pour surveiller le nombre de messages dans une file d’attente, un topic ou une file de lettres mortes.

Azure Application Insights est utilisé pour l’analyse des performances des applications et peut être activé pour les plug-ins Dataverse pour envoyer des journaux de trace à un espace de travail Application Insights.

Autres options

  • Azure Logic Apps : alternative viable à faible code pour remettre des messages de la table de boîte d’envoi au répartiteur de messages si vous souhaitez un contrôle plus précis sur le moment où déclencher l’orchestration et la remise du message (par exemple, micro-traitement par lots).
  • Azure Functions : alternative orientée code qui vous offre la plus grande flexibilité et la mise à l’échelle pour gérer des volumes plus élevés et des nouvelles tentatives après des échecs intermittents.

Détails du scénario

Les solutions d’entreprise doivent souvent échanger des données critiques avec d’autres systèmes via des messages. Pour garantir la cohérence entre les systèmes, gérez l’opération de données et la remise des messages en tant qu’opération atomique unique. Toutefois, la plupart des systèmes transactionnels et des courtiers de messages prennent rarement en charge les transactions distribuées, ou ils introduisent un couplage étroit que vous souhaitez éviter. Sans transaction distribuée, il n’existe aucune garantie de fiabilité, car un échec peut se produire lors de l’envoi du message au broker une fois qu’une transaction est validée.

Le modèle de boîte d’envoi transactionnelle résout ce problème en créant un message dans la même transaction de base de données locale que celle qui met à jour les données professionnelles. Un processus distinct peut ensuite transmettre le message de la table de boîte d’envoi au répartiteur de messages. Les échecs de processus intermittents ne sont pas un problème. La table de boîte d’envoi stocke le message de sorte qu’il n’est pas perdu, et le processus retente jusqu’à ce qu’il réussisse.

Dataverse est une plateforme de données à faible code capable et extensible avec un stockage de données transactionnel qui peut implémenter ce modèle pour les scénarios d’intégration sortant critiques.

Considerations

Ces considérations mettent en œuvre les piliers de Power Platform Well-Architected, un ensemble de principes directeurs qui améliorent la qualité d’une charge de travail. En savoir plus dans Microsoft Power Platform Well-Architected.

Fiabilité

Ce modèle améliore considérablement la fiabilité et garantit une remise au moins une fois ainsi qu’une cohérence à terme, en assurant la cohérence transactionnelle. En s’appuyant sur un courtier de messages, il protège les systèmes en aval contre la surcharge en contrôlant le flux de données entre les systèmes source et cible et protège contre les problèmes de disponibilité des systèmes en aval.

Lorsque l’ordre des messages est requis, activez les sessions Azure Service Bus sur la file d’attente ou l’abonnement. Le producteur doit affecter un SessionId cohérent, tel que l’enregistrement Dataverse ou l’ID d’agrégation, aux messages associés afin qu’ils soient traités dans l’ordre dans cette session. Concevez les consommateurs pour un traitement idempotent, car ce modèle fournit une livraison au moins une fois et des messages en double peuvent se produire. Lorsque la détection d’événements manquants ou hors séquence est importante, les messages peuvent inclure un numéro de séquence au niveau de l’application. Les garanties d’ordre s’appliquent au sein d’une session plutôt que globalement, et la solution doit définir l’incidence des nouvelles tentatives et des messages placés dans la file d’attente de lettres mortes sur le traitement ultérieur de cette session.

Security

En utilisant les services Azure, Dataverse peut s’authentifier auprès du répartiteur de messages (Azure Service Bus) via des identités managées Azure grâce à la fonctionnalité d’identité managée de Power Platform. Cette approche élimine les risques liés au stockage d’informations d’identification sensibles et les interruptions de service causées par la rotation des secrets.

Efficacité des performances

L’utilisation d’un répartiteur de messages tel qu’Azure Service Bus permet de lisser la charge afin d’éviter que les applications en aval ne soient surchargées pendant les périodes de forte activité.

Envisagez d’utiliser une fonction Azure plutôt qu’un plug-in Dataverse asynchrone pour envoyer des messages à Azure Service Bus si les volumes deviennent très élevés. Cette approche offre la meilleure évolutivité et une flexibilité pour traiter un grand volume d’enregistrements en lots et gérer des erreurs temporaires.

Contributors

Microsoft conserve cet article. Les contributeurs suivants ont écrit cet article.

Auteurs principaux :

  • Dernière mise à jour :