Synchroniser des données dans des environnements Dataverse à l’aide de Power Platform

Cette architecture de référence montre comment synchroniser les données de référence entre deux environnements Dataverse à l’aide de Power Automate et de dataflows dans Power Platform. Il illustre un modèle de synchronisation un-à-un où un environnement agit comme source faisant autorité et un autre reçoit des données.

Diagramme d’architecture

Flux de travail

Les étapes suivantes décrivent le flux de travail présenté dans l’exemple de diagramme d’architecture :

1. synchronisation pilotée par événement via Power Automate

   • Opérations CRUD (créer, lire, mettre à jour, supprimer) dans l'environnement Dataverse principal déclenchent des flux Power Automate.

   • La synchronisation pilotée par les événements utilise une chaîne de flux en deux étapes :

     1. Un flux cloud envoie une requête HTTP POST à un point de terminaison publié.
     2. Un flux cloud d’abonné est déclenché par le webhook, traite la charge utile et applique la mise à jour dans l’environnement Dataverse secondaire en quasi-temps réel.

   • Les points de terminaison sont paramétrés pour la gestion du cycle de vie des applications (ALM) et les groupes de sécurité gèrent l’accès.

2. Synchronisation en bloc via des dataflows

   • L’environnement Dataverse secondaire contient les dataflows.

   • Chaque dataflow se connecte à l’environnement Dataverse principal en tant que source de données.

   • Les dataflows s’exécutent selon une planification fixe (par exemple, nocturnement ou après l’exécution d’un autre dataflow avec succès) ou à la demande (par exemple, pour la configuration initiale).

   • Les upserts sont effectués à l’aide d’une autre clé pour éviter les doublons. Cette méthode met à jour les données existantes et insère de nouveaux enregistrements lorsqu’aucune correspondance n’existe.

   • Les champs d’état sont gérés via une colonne « état de synchronisation » dédiée. Un flux Power Automate met à jour le champ d’état réel en conséquence. Ce flux s’exécute après le flux de données et est requis, car un flux de données ne peut pas modifier l’état des lignes ou supprimer des enregistrements supprimés (absents) dans l’environnement Dataverse principal.

3. Gestion et rapprochement des erreurs

   • Les flux de données nocturnes dans l’environnement secondaire corrigent toutes les mises à jour manquées ou ayant échoué pilotées par les événements.

   • Une intervention manuelle peut être nécessaire pour des problèmes de qualité des données (par exemple, des clés manquantes).

Composants

• Microsoft Dataverse : prend en charge la configuration requise pour deux environnements.

• Dataflows pour Power Platform : idéal pour les opérations en bloc, telles que la synchronisation et la population initiales des données. Utilisez l’extraction en bloc, la transformation et le chargement (ETL) pour la synchronisation planifiée, configurée dans l’environnement secondaire.

• Power Automate les flux cloud : fournissez des mises à jour rapides et spécifiques aux enregistrements et compensez les limitations des flux de données. Les flux cloud peuvent déclencher un flux de données lorsqu’un autre flux de données se termine correctement (par exemple, lorsqu’une table contient un champ de recherche vers un autre, et que cet enregistrement référencé doit déjà exister dans l’environnement Dataverse secondaire), envoyer un message d’erreur lorsqu’un flux de données échoue, mettre à jour les états des enregistrements et supprimer des enregistrements.

• Groupes de sécurité et comptes de service : fournissez la gestion et la propriété des accès.

Détails du scénario

Cette architecture est conçue pour une relation un-à-un : un seul environnement de gestion des données de référence (MDM) lié à un autre environnement unique. Les scénarios où un environnement maître doit être synchronisé avec plusieurs autres environnements nécessitent une solution plus évolutive ou distribuée.

Problème commercial

Cette solution résout le défi de synchroniser plusieurs tables entre deux environnements Dataverse distincts. L’environnement principal agit comme source faisant autorité, tandis que l’environnement secondaire contient des tables existantes que vous devez remplir et mettre à jour avec des données de référence.

L’utilisation de tables virtuelles n’est pas possible lorsque les tables du système secondaire existent déjà et nécessitent une sécurité au niveau des lignes.

Exemple de cas d’usage

Une organisation de loisirs et d’hospitalité gère ses principales données de référence, telles que les inventaires d’hôtels et de chambres, dans un environnement Dataverse dédié. L’environnement principal comprend une application basée sur des modèles que l’équipe de gestion des données de référence utilise exclusivement pour maintenir des informations opérationnelles précises et up-to-date.

Un service distinct au sein de la même organisation est responsable de plusieurs processus financiers et de rapprochement. Pour simplifier ces processus, le service souhaite créer sa propre application basée sur des modèles dans un environnement Dataverse isolé. Toutefois, leur application nécessite toujours l’accès aux données de référence fondamentales telles que les détails de l’hôtel et de la chambre.

L’équipe a rejeté les tables virtuelles, car l’équipe financière avait besoin d’enrichir les enregistrements avec des attributs propres au service régis par une sécurité stricte au niveau des lignes.

L’incorporation de l’application financière à l’intérieur de l’environnement MDM principal n’est pas une option non plus. Autoriser les décideurs financiers ou les administrateurs dans l’environnement MDM expose des connecteurs, des solutions, des autorisations d’API et des données sensibles qui doivent rester limitées à l’équipe de développement MDM.

Ces exigences ont conduit l’organisation à adopter l’architecture de synchronisation décrite dans cet article.

Valeur créée

Cette architecture offre une solution robuste et gérable pour la synchronisation des données de référence entre deux environnements Dataverse lorsque les tables virtuelles ne sont pas une option. Remplir et mettre à jour directement des tables existantes dans l’environnement secondaire garantit la cohérence des données et la fiabilité opérationnelle.

L'approche utilise uniquement les composants Power Platform, tels que les flux de données et les Power Automate, ce qui entraîne un déploiement simple, facile à gérer et évite toute complexité inutile.

Étant donné que l’architecture est adaptée à une relation d’environnement un-à-un, elle réduit la surcharge et optimise la transparence. Il est idéal pour les organisations qui ont besoin d’une synchronisation simple et fiable des données de référence sans gestion multi-environnement à grande échelle.

Observations

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.

Reliability

• Les dataflows nocturnes garantissent la cohérence.

• Les flux pilotés par les événements fournissent des mises à jour rapides.

• La surveillance manuelle détecte les problèmes de qualité des données.

Sécurité

• Comptes de service et groupes de sécurité pour le contrôle d’accès. Lorsque vous utilisez des flux de données, vous ne pouvez pas désigner des entités de service en tant que propriétaires.

• Points de terminaison HTTP paramétrables pour la compatibilité ALM.

• Flux de données dans des solutions isolées pour éviter les tâches manuelles inutiles. Il existe une raison spécifique d’isoler les flux de données dans une solution dédiée : après chaque déploiement, vous devez rétablir manuellement la connexion de flux de données. En plaçant des dataflows dans une solution distincte que vous déployez uniquement lorsque vous modifiez les flux de données, vous évitez le travail manuel inutile lors du déploiement d’autres composants de la solution principale.

Excellence opérationnelle

• Planification et orchestration automatisées des flux de données.

• Surveillance et alertes pour les synchronisations ayant échoué.

Efficacité des performances

• Les flux de données optimisés pour les traitements par lots.

• Les flux de Power Automate pilotés par les événements réduisent la latence des mises à jour critiques au niveau des enregistrements. Lors de la conception de flux pilotés par les événements, assurez-vous que le volume d’actions et la concurrence restent dans les limites de service Power Automate. L’activité CRUD à haute fréquence peut déclencher une limitation, en particulier dans les scénarios où les flux exécutent des dizaines de milliers d’actions par jour. Pour les intégrations à haut débit ou critiques pour l'entreprise, appliquez les licences Power Automate appropriées pour gérer les limites de débit et éviter le bridage inattendu. Cette approche réduit les risques d’escalade et garantit des performances prévisibles.

Optimisation de l’expérience

• Nécessite une intervention manuelle minimale.

• Sépare clairement les synchronisations en bloc et pilotées par les événements.

Contributeurs

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

Auteurs principaux :

• Lothar van Diessen, Architecte de solutions

Ressources associées

• Que sont les flux de données ?
• Modèles Power Automate pour le connecteur de flux de données
• Dataverse en tant que système de données de référence
• Comprendre les restrictions de la plateforme et éviter la restriction
• Migration des données CRM vers Dataverse : Informations clés et bonnes pratiques
• Migrer des données entre des environnements Microsoft Dataverse en utilisant le connecteur OData des flux de données