Modèles
Cette unité présente des modèles communs (bonnes pratiques) qui ont été observés parmi les clients et l’utilisation de la double écriture afin de fournir une meilleure compréhension des implications et des utilisations réelles de l’intégration. De ces scénarios réels sont nés les modèles (bonnes pratiques) et les anti-modèles (pièges) suivants pour la double écriture, la synchronisation initiale, la synchronisation en direct et d’autres processus.
Synchronisation initiale
La double écriture vous permet de synchroniser les données initiales entre les applications de finances et d’opérations et Dataverse. La synchronisation initiale est utilisée de préférence pour créer les données initiales de faibles volumes ; elle n’est pas conçue pour traiter de grandes quantités de données à des fins de migration des données. En fait, vous ne devez pas activer le mappage de table à double écriture ou effectuer une synchronisation initiale avant que tous les processus de migration des données ne soient terminés. La synchronisation initiale fournit les données de votre application de destination à la nouvelle implémentation.
Par exemple, si vous avez une implémentation complète des applications de finances et d’opérations, et que vous avez ajouté une implémentation de Microsoft Dynamics 365 Customer Engagement, alors la synchronisation initiale peut être utile pour vous aider à transférer les données existantes des applications de finances et d’opérations vers Customer Engagement afin de commencer l’implémentation de Customer Engagement sans attendre un scénario de migration de données. De plus, la synchronisation initiale en double écriture n’écrasera pas les données existantes dans l’un ou l’autre des environnements.
Si vous devez remapper ou recréer des données dans l’un ou l’autre système, nous vous recommandons de nettoyer l’environnement avant d’effectuer la synchronisation initiale. Veillez à vérifier vos données principales pour la synchronisation initiale, puis assurez-vous que tous les champs, les champs filtrés et les entités juridiques sont prévus pour la synchronisation initiale. Une limite est fixée à 500 000 lignes pour chaque exécution et à 70 000 pour une table à thread unique. Si la synchronisation initiale est supérieure à ces limites, vous devez alors migrer les données dans chaque environnement (applications de finances et d’opérations ou Dataverse) séparément, puis sauter la synchronisation initiale. Une autre option consiste à synchroniser plusieurs entités juridiques, une par une, plutôt que toutes en même temps.
Pour en savoir plus, consultez Considérations relatives à la synchronisation initiale.
Piggybacking, ou implémentation asynchrone
La synchronisation en double écriture est déclenchée comme dernière étape avant de valider les transactions de la base de données dans l’application source. Le même contenu de transaction pour tous les enregistrements pertinents est envoyé à l’application cible en un seul lot. Ce n’est que lorsque le lot entier est accepté par l’application cible que la transaction de la base de données source est validée. Les champs qui sont définis dans l’application cible dans le cadre de la transaction de création ou de mise à jour ne sont pas synchronisés avec la source. Ce scénario, appelé « piggybacking », est interdit pour éviter une intégration circulaire et infinie.
Par exemple, une ligne de devis est créée dans la section Microsoft Dynamics 365 Sales. Cet enregistrement de ligne de devis se synchronise avec les applications de finances et d’opérations et est créé dans cette application. Dans le cadre de la création des applications de finances et d’opérations, une certaine logique commerciale s’exécute et propose par défaut plusieurs champs, tels que Site et Entrepôt. Ces champs ne sont pas redéfinis dans Dynamics 365 Sales. Dans ce cas, nous vous recommandons de reproduire la logique par défaut dans Dynamics 365 Sales afin de faire correspondre les enregistrements par défaut dans les applications de finances et d’opérations.
Parfois, une autre option consiste à déplacer la logique par défaut vers un travail asynchrone distinct qui peut mettre à jour l’enregistrement dans une transaction distincte et déclencher en toute sécurité une synchronisation vers l’application source. Ce processus est considéré comme un anti-modèle (piège) car les performances pourraient être affectées, vous devez donc l’évaluer au cas par cas.
Déclencheurs personnalisés sur les colonnes de recherche dans les applications d’engagement des clients
Ce scénario concerne spécifiquement les données principales et le détail ou l’en-tête et les lignes en double écriture.
Exemple
Vous vous trouvez dans l’espace des ventes de l’entreprise et votre seule tâche consiste à ajouter un devis dans l’application Dynamics 365 Sales. Vous voulez accomplir cette tâche rapidement, sans supplément, et sans exigences du point de vue du système. Vous parlez à un client, saisissez ses informations et créez un devis. Plus tard, vous remplirez le reste des informations, lorsqu’elles seront prêtes à être synchronisées entre Dynamics 365 Sales et Dynamics 365 Supply Chain Management.
Dans ce cas, vous voulez saisir un devis et le synchroniser uniquement lorsqu’il est marqué comme prêt à être intégré. Pour ce faire, vous pouvez créer une colonne personnalisée sur l’en-tête du devis qui servira de déclencheur lorsqu’il sera prêt à être intégré. Ensuite, vous pouvez créer une colonne personnalisée sur le tableau des lignes de devis en tant que champ calculé. Ensuite, vous définirez le filtre sur le mappage de la table à double écriture de l’En-tête de devis et le mappage de la Ligne de devis pour ces champs afin d’obtenir la valeur correcte dans les colonnes calculées. Lorsque la colonne personnalisée dans l’en-tête est mise à jour, le déclencheur double écriture fonctionne et déclenche l’intégration en double écriture sur les lignes liées. Ce processus crée une intégration efficace à la demande, basée sur la mise à jour des colonnes personnalisées.
Transactions des applications de finances et d’opérations - En-tête et lignes dans la même transaction
Pour toute transaction, les applications de finances et d’opérations créent des données dans un lot et les envoient ensuite en tant que lot vers Dataverse. Si deux enregistrements sont créés dans le cadre de la même transaction et qu’ils font référence l’un à l’autre, une erreur se produit, telle que « Impossible d’écrire des données dans l’entité X. Impossible de rechercher l’entité avec les valeurs XXXX. Impossible de rechercher l’entité X avec les valeurs XXXX. » Dans ce cas, la solution consiste à créer des relations entre les entités dans les applications de finances et d’opérations pour indiquer à la plateforme de double écriture que les deux entités sont liées et qu’il existe des relations entre les deux enregistrements qui, dans ce cas, sont traités dans la même transaction.
Tables virtuelles et double écriture
Les modules Prise en main de l’intégration d’applications de finances et d’opérations dans Microsoft Power Platform et Intégrer les applications de finances et d’opérations à Microsoft Power Platform à l’aide de concepts clés et de la configuration décrivaient les entités virtuelles comme une option pour accéder aux données entre les applications de finances et d’opérations et Dataverse sans copier physiquement les informations entre les deux applications. Les données n’existent pas dans les deux bases de données des applications et ne résident que dans les applications de finances et d’opérations. Pour décider de l’option la mieux adaptée à vos données, vous devez explorer quelques considérations de conception.
La résidence des données des tables virtuelles est une considération importante. Si le processus métier exige que vous copiez physiquement les données, les tables et entités virtuelles ne sont peut-être pas la bonne solution pour vous. Dans ce cas, vous souhaiterez probablement utiliser l’intégration en double écriture pour vous assurer que les deux applications disposent d’une copie des données.
Pensez à vous poser les questions suivantes sur l’analytique données :
- Les besoins de l’entreprise imposent-ils que les analyses s’appuient sur des données sources ?
- Des exigences en matière de latence sont-elles en place ?
- Une exigence de faible latence est-elle établie pour les données qui doivent être copiées de système à système ?
- Les coûts de transaction et de réplication des données sont-ils élevés ?
Les tables virtuelles ne copient pas les données physiques dans les applications Dataverse. Les tables virtuelles constituent une option à faible latence pour les données qui doivent être copiées ou répliquées et peuvent être une solution utile pour la réplication des données. Étant donné que les tables virtuelles ne copient pas physiquement les données dans Dataverse, vous devez tenir compte de cette solution en utilisant des tables virtuelles pour héberger et traiter les données transactionnelles, telles que les transactions de détail ou les stocks disponibles.
Cependant, la double écriture répond à des scénarios où les données doivent être physiquement copiées entre les applications.