Cet article décrit un scénario dans lequel un client hypothétique basé aux États-Unis, Contoso, a récemment acquis une autre société basée en Europe et qui est en train de mettre en place des systèmes CRM et ERP entre les deux sociétés. Dans le cadre de cette intégration, il doit synchroniser une partie de ses entités Dynamics 365 Dataverse jusqu’à ce qu’elles puissent être entièrement intégrées. Une application métier appartenant à Contoso consomme des données des deux systèmes et doit être en mesure d’accepter les demandes quand les données sont en attente de synchronisation ou quand elles sont manquantes. Le guide suivant montre comment prendre en compte la cohérence éventuelle entre les instances Power Platform.
Architecture
Plug-in/flux pour toujours faire un upsert en fonction du GUID ou de la clé secondaire
Téléchargez un fichier Visio de cette architecture.
Workflow
Cette solution peut être créée avec plusieurs étapes de plug-in, dans le cycle de vie du plug-in. Quand l’entité que vous créez est obligatoire, effectuez l’étape de prévalidation. La prévalidation (PreValidation) se produit avant le démarrage de toute transaction de base de données. Il s’agit de l’option recommandée si le champ est obligatoire. Toutefois, dans certains scénarios, une étape de plug-in PreCreate suffit.
- L’instance États-Unis tente de synchroniser un nouveau compte avec l’instance Europe via une application logique. L’instance Europe est inaccessible en raison d’un temps d’arrêt ou d’une mise à niveau.
- L’application métier Contoso lit les entités de compte principales à partir de l’instance États-Unis. Elle a pour but de soumettre un appel d’API qui fait référence à une entité de compte qui n’a pas été répliquée sur l’instance Europe. En l’état, l’appel d’API échouerait car l’enregistrement n’existe pas en raison du fait que la synchronisation ne fonctionne pas.
- Toutefois, un plug-in PreValidation/PreCreate effectue d’abord un upsert basé sur le GUID d’entité et les données de référence fournis. S’il existe déjà, rien n’est modifié. S’il n’existe pas, un compte est créé avec la plupart des champs vides.
- L’appel d’API aboutit parce que le compte portant l’ID donné existe dans le système. Le plug-in a intercepté l’opération et géré l’enregistrement manquant normalement. Le rapport de l’application métier est généré avec succès.
Notes
Microsoft recommande d’introduire un modèle de disjoncteur dans votre code personnalisé pour interrompre et réessayer dans le cadre de cette solution afin de gérer les pannes de plateforme lorsque vous référencez l’une ou l’autre des instances. Pour plus d’informations sur l’utilisation d’un disjoncteur, consultez Modèle de disjoncteur.
Autres solutions
Le scénario décrit ci-dessus utilise une application logique personnalisée comme méthode de réplication. Toutefois, il existe plusieurs façons de répliquer des données entre des instances Dataverse, notamment :
- Logic Apps
- Applications de fonction dans Azure Functions
- Azure Data Factory
- Azure Synapse Analytics
- Power Automate
Détails du scénario
Les organisations jugent parfois nécessaire de maintenir synchronisées deux instances Power Platform ou plus, Et pour être plus précis, il s’agit généralement d’un sous-ensemble d’entités Dataverse. Cette exigence peut se produire lorsqu’une organisation a intentionnellement ajouté de nouvelles instances pour l’isolement géographique, mais qu’elle a besoin d’un jeu de données commun dans toutes les zones géographiques. Cela peut aussi se produire lorsque deux organisations fusionnent avant la fin de la consolidation de Power Platform.
Quand le processus de synchronisation fonctionne comme prévu, les applications métier qui consomment auprès des deux instances ne rencontrent pas de problèmes. Toutefois, les mécanismes de synchronisation ne sont jamais une preuve d’erreur. Des pannes ou des problèmes inattendus se produiront probablement. Dans ce cas, votre application métier qui consomme des données en provenance des deux instances doit être générée pour gérer des données incomplètes.
Pour que la nouvelle filiale européenne de Contoso soit intégrée à la structure métier de Contoso, il doit synchroniser les comptes et les contacts d’une instance de Power Platform à une autre. Dans ce scénario, l’instance États-Unis de Power Platform synchronise un lot quotidien de données de référence avec l’instance Europe via une application logique personnalisée. Une application métier Contoso propriétaire génère des rapports sur les tickets de problème créés par les utilisateurs. Pour effectuer cette tâche, l’application métier lit les données utilisateur provenant des deux instances Dataverse pour extraire les données pertinentes, les clés de référence primaires de l’instance États-Unis et les données de ticket de l’instance Europe. Si le processus de synchronisation n’a pas été effectué en raison d’un temps d’arrêt, d’une maintenance ou d’un autre problème de communication, la demande génère une erreur due à des entités manquantes dans l’instance Europe.
Cas d’usage potentiels
Ce modèle est inutile dans les situations suivantes :
- Le système qui envoie les données de référence est inactif.
- La synchronisation des données prend beaucoup de temps ou le processus est retardé.
- Les systèmes consommant les données n’ont pas de logique concernant la création d’entité.
Quand utiliser cette approche
Cette approche est utile dans les scénarios suivants :
- Vous souhaitez garantir qu’un enregistrement avec une clé donnée existe, peu importe si l’enregistrement n’est pas entièrement alimenté.
- Vous devez accepter la création, même si les données ne sont toujours pas synchronisées.
Il se peut que ce modèle ne convienne pas dans le scénario suivant :
- La logique est appliquée lors de la création de l’enregistrement. Étant donné que les données ne sont pas alimentée, il n’est pas possible de s’appuyer sur certaines propriétés disponibles.
Exemples
Les exemples suivants illustrent les parcours potentiels et le résultat des retards de synchronisation.
Exemple 1 : chemin d’accès réussi sans interruption ou erreur temporaire
Téléchargez un fichier Visio de cette architecture.
- L’instance États-Unis synchronise un nouveau compte avec l’instance Europe via une application logique. Elles fonctionnent toutes car aucune interruption ou erreur temporaire ne s’est produite.
- L’application métier Contoso lit les entités de compte principales à partir de l’instance États-Unis et a pour but de soumettre un appel d’API faisant référence à une entité de compte qui a été répliquée sur l’instance Europe. Cela fonctionne parce que tout était opérationnel et qu’aucune panne ou erreur temporaire ne s’est produite. Le rapport de l’application métier est généré avec succès.
Exemple 2 : chemin d’accès incorrect dans lequel la synchronisation est interrompue ou retardée
Téléchargez un fichier Visio de cette architecture.
- L’instance États-Unis tente de synchroniser un nouveau compte avec l’instance Europe via une application logique. L’instance Europe est inaccessible en raison d’un temps d’arrêt, d’une maintenance ou d’un autre problème de communication.
- L’application métier Contoso lit les entités de compte principales à partir de l’instance États-Unis et a pour but de soumettre un appel d’API faisant référence à une entité de compte qui n’a pas été répliquée sur l’instance Europe. L’appel d’API échoue car le compte avec l’identificateur donné n’a pas été créé dans l’instance Europe et le rapport n’est pas généré.
Considérations
Tenez compte de l’impact d’une logique métier sur une entité qui n’est pas encore alimentée. Envisagez un scénario dans lequel l’entité n’est pas encore entièrement alimentée et synchronisée. Certaines propriétés ayant une valeur null, vous devez vous assurer que toutes les décisions sur les données sont factorisées lors de l’utilisation de cette approche.
Étapes suivantes
- Power Platform
- Qu’est-ce que Power Apps ?
- Qu’est-ce qu’Azure Logic Apps ?
- Bien démarrer avec Power Automate
Ressources associées
Architectures connexes :
Conseils pour le développement web :