Gestion des erreurs
Le module Intégrer les applications de finances et d’opérations dans Microsoft Power Platform décrit certaines erreurs et problèmes susceptibles de se produire lors de la mise en œuvre et de la synchronisation de la double écriture. Vous allez maintenant découvrir la gestion des erreurs dans différents scénarios et les actions de double écriture.
Synchronisation initiale
La synchronisation initiale est exécutée la première fois que vous connectez un environnement à un autre et lors du premier mappage entre les deux champs ou tables. Ce processus extrait ou exporte des données en bloc à partir du système source et du système cible, ce qui garantit que les informations sont disponibles dans les applications de finances et d’opérations et Dataverse. Ce processus survient pour une entité juridique à la fois, et un grand volume de données peut potentiellement transiter par cette connexion.
Synchronisation durable
L’un des scénarios les plus courants auxquels vous pouvez être confronté pour cette synchronisation initiale est qu’elle s’exécute pendant une période prolongée. Dans ce cas, plusieurs problèmes pourraient se produire.
Problème potentiel : le nombre d’entreprises présentes dans la synchronisation initiale
Étant donné que la synchronisation initiale s’exécute pour chaque société, en fonction de la bande passante dont vous disposez pour chaque système, et qu’elle monte jusqu’à 100 enregistrements par minute, son exécution peut prendre beaucoup de temps.
Pour éviter ce problème, nous vous conseillons de choisir un plus petit sous-ensemble de sociétés pour la synchronisation initiale si l’ensemble de données initial est volumineux et couvre plusieurs entreprises. Vous pouvez ajouter quatre à cinq sociétés à la fois, afin de vous assurer que les synchronisations aboutissent et n’expirent pas.
Problème potentiel : le nombre d’entités dépendantes
La double écriture a été conçue pour accorder la priorité aux dépendances en amont lors de la synchronisation initiale. Si vous exécutez une synchronisation initiale pour les clients, celle-ci recherche toutes les dépendances en amont et les place en premier. Si vous choisissez une entité plus éloignée (une entité feuille) lors de la synchronisation initiale, de nombreuses dépendances et informations peuvent être choisies en amont pour être synchronisées initialement.
Nous vous conseillons dans ce cas d’éviter de sélectionner les entités « feuilles » en choisissant les entités racine, ou de niveau parent, puis en divisant le sous-ensemble de la synchronisation initiale dans le cas de grands ensembles de données.
Problème potentiel : grands volumes de données à importer pour les applications de finances et d’opérations
Ce problème se produit généralement lorsque vous avez une implémentation existante et un grand volume de données dans Dataverse, et que vous devez l’importer dans les applications de finances et d’opérations. La double écriture ne remplace pas la migration des données, car le processus de migration est beaucoup plus approfondi et comporte des mesures d’équilibre destinées à garantir l’intégrité des données sur de gros volumes. La synchronisation initiale n’était pas destinée à résoudre ce problème. Cependant, de grands volumes de données peuvent exister en dehors d’un scénario de migration des données. Dans ce cas, il est nécessaire de prendre en compte les performances pour définir les paramètres d’implémentation de l’importation d’entités. Pour en savoir plus, consultez Vue d’ensemble de tâches d’importation et d’exportation de données - Importations parallèles et Optimiser la migration des données pour les applications de finances et d’opérations.
Problème potentiel : limitation de la bande passante Dataverse en cas de gros volumes de données
En règle générale, ce problème se produit lorsque les données historiques des applications de finances et d’opérations sont transférées via une double écriture.
Pour éviter que ce problème se produise, vous pouvez utiliser des filtres ou des colonnes calculées pour réduire les données anciennes ou archivées qui pourraient ne pas être obligatoires dans Dataverse.
Synchronisation en direct
La synchronisation en direct prend le relais une fois la synchronisation initiale terminée. Les mappages en double écriture passent en mode de synchronisation en direct, qui met à jour en continu les données en fonction des mappages de table associés au suivi des modifications activé sur les entités. Ces problèmes sont courants et surviennent fréquemment. Des recommandations pour aborder ces problèmes sont présentées dans les sections suivantes.
Impossible de synchroniser les données
Imaginez un scénario dans lequel vous avez activé la double écriture, mais que les modifications des applications de finances et d’opérations ne semblent pas se synchroniser avec Dataverse. Généralement, vous pouvez effectuer plusieurs vérifications pour optimiser et garantir la synchronisation des données souhaitées.
Problème potentiel : les modifications ne font pas partie de la transaction
Les événements sont déclenchés sur les événements de pré-validation, qui fait partie de la vérification permettant de s’assurer que les données soient transférées à partir des applications de finances et d’opérations.
Si des personnalisations existent, nous vous conseillons de vous assurer que les données se trouvent à l’intérieur de la transaction. Si les données que vous prévoyez de synchroniser ne s’affichent pas, il se peut qu’elles soient hors du périmètre de la transaction.
Problème potentiel : les propriétés DoUpdates/Insert/Deletes, Record Set Operations et Skip Business Events sont définies sur true
Dans ce cas, les opérations de jeu d’enregistrements et les événements commerciaux ne peuvent pas écouter les modifications. Lorsque vous utilisez ces commandes dans le code, l’intention générale est d’ignorer une grande partie de la logique métier.
Nous vous conseillons de conserver les méthodes actuelles Create, Update, Delete et Update. Vous devez vous assurer que les modifications apportées à l’application font partie des méthodes au niveau de la table qui sont écoutées par la synchronisation en direct en double écriture.
Problème potentiel : table non suivie de l’entité
Les sources de données qui n’ont aucun champ mappé ou mappé uniquement sur une recherche, ou même une jointure externe en lecture seule, ne sont pas suivies.
Passez en revue les mappages de champs afin de vérifier que les tables et les champs sont mappés. Dans le cas contraire, vous pouvez utiliser la méthode de remplacement getEntityDataSourceToFieldMapping pour inclure des sources de données non suivies dans la logique métier de l’entité.
Performance
Dans certains cas, vous constaterez peut-être que l’intégration entre les applications de finances et d’opérations et Dataverse via la double écriture est lente et ne se synchronise pas rapidement. Dans ce cas, plusieurs problèmes pourraient se produire.
Problème potentiel : le plan de requête d’entité n’est pas optimisé
La requête d’entité permet d’identifier les enregistrements et les champs uniques qui sont utilisés pour les mappages.
Nous vous conseillons d’exécuter une analyse des performances sur le plan de requête d’entité pour déterminer s’il fonctionne correctement et s’il est optimisé. Vous pouvez également réduire la complexité de l’entité en supprimant les jointures et les liens superflus. En outre, nous vous conseillons d’exécuter une analyse d’index sur les plages utilisées dans la requête pour vérifier qu’elles sont optimisées.
Problème potentiel : plusieurs tables suivies pour chaque entité
Les modifications apportées aux entités sont suivies pour les tables utilisées dans les mappages. Si toutes les tables suivies sont modifiées dans le cadre d’une transaction, plusieurs événements peuvent exister pour le même enregistrement d’entité, ainsi qu’un plan de requête non optimisé. Ce problème peut avoir un impact sur les performances.
Pour ce scénario, nous vous conseillons de suivre les mêmes étapes que pour le premier problème potentiel, à savoir, analyser le plan de requête. Vous pouvez également utiliser la méthode de remplacement dualWriteShouldSkipDataSource dans la logique métier de l’entité ou de l’extension pour ignorer les tables suivies superflues. Cette méthode, et bien d’autres, sont présentes sur CustCustomerV3Entity, qui existe par défaut dans les applications de finances et d’opérations.
Problème potentiel : plusieurs tables suivies pour plusieurs entités
Les tables communes sont suivies pour plusieurs entités, ce qui peut déclencher des événements pour toutes les entités liées, en particulier si elles s’exécutent sur un plan de requête non optimisé, ce qui peut avoir un impact sur les performances de l’intégration avec la double écriture.
Pour résoudre ce problème, nous vous conseillons d’effectuer une vérification sur le groupe businessEventsDefinition par les champs RefTableName et RefEntityName.
Échecs et validations de données
Outre les performances, un autre problème courant concerne les échecs de recherche.
Problème potentiel : les enregistrements dépendants ne sont pas disponibles dans Dataverse
Les recherches comprennent les données de référence requises pour la résolution d’une transaction. Même si les données sont marquées comme null dans Dataverse, les recherches sont requises si les tables et les champs sont mappés en double écriture.
Nous vous conseillons d’analyser les données de référence pour savoir si elles ont été créées avant ou si elles font partie de la transaction. Pour obtenir des informations détaillées sur la charge utile, vous pouvez utiliser le mode de débogage dans la synchronisation en direct pour effectuer une enquête plus approfondie.
Problème potentiel : les enregistrements dépendants ne sont pas créés dans le cadre de la transaction
Étant donné que les dépendances en amont sont créées dans le cadre de la transaction, elles ne sont pas résolues lors de la résolution de la recherche et, par conséquent, elles échouent.
Les résolutions de recherche dépendent des relations entre les entités dans les applications de finances et d’opérations. Vous pouvez ajouter des relations sur toutes les entités associées qui font partie de la transaction.