Bonnes pratiques
Pour vous permettre de comprendre les bonnes pratiques et recommandations relatives à la double écriture, la synchronisation en direct et la synchronisation initiale, les sections suivantes prennent du recul pour expliquer le processus global d’une transaction et le flux de double écriture.
Le schéma suivant illustre un exemple de transaction de synchronisation en direct et de flux de réussite :
Une transaction dans le flux commence par une mise à jour ou insertion et la table est écrite dans l’enregistrement de Dataverse en étant intégrée à une seule transaction. Ensuite, cette transaction est commencée et validée dans l’environnement Dataverse, qui envoie alors une réponse de réussite. Lorsque la réponse de réussite atteint l’environnement des applications de finances et d’opérations, la transaction est validée et le processus est terminé. Une seule transaction peut impliquer des enregistrements sous-jacents d’une ou plusieurs tables. Tous les enregistrements de table pour une seule transaction sont inclus ensemble pour créer un seul lot et ce lot doit réussir à valider cette transaction dans tous les systèmes.
En cas d’échec, comme illustré dans le schéma précédent, si la transaction échoue dans l’environnement Dataverse ou à tout moment au cours de la transaction, cette dernière est abandonnée si une réponse d’échec est envoyée par le système pendant le flux. Cet échec déclenche la restauration des enregistrements dans l’environnement des applications de finances et d’opérations. Lorsque plusieurs enregistrements sont intégrés à une ou plusieurs tables dans le cadre d’un bloc de transaction unique lors de l’implémentation d’un processus, il est qualifié de bloc de transaction unique. Plusieurs blocs de transaction peuvent également se produire lorsque plusieurs enregistrements sont intégrés à une ou plusieurs tables dans le cadre de plusieurs blocs de transaction plus petits lors de l’implémentation d’un processus à double écriture (comme une routine de validation). Encore une fois, si tout élément des blocs de transaction ou du bloc de transaction multiple échoue, la transaction échoue également. Les transactions entre les systèmes font référence aux unités de travail qui se produisent de chaque côté du processus à double écriture.
Le nombre de transactions, le nombre d’enregistrements pour chaque transaction, le délai d’expiration d’une transaction, les limitations de plateforme et les limites ou limitations d’API peuvent affecter les performances et la fiabilité de la synchronisation en direct en double écriture.
Pour les transactions de synchronisation en direct depuis les applications de finances et d’opérations vers Dataverse, vous devez limiter leur nombre à celui des limites des transactions d’API. Ces limites sont élevées et la double écriture n’effectue pas autant de transactions que la plupart des transactions d’API ; cependant, il est avantageux de garder ces limites à l’esprit. Vous devez limiter une seule transaction à 1 000 enregistrements ou moins. La double écriture et le processus rejettent également une transaction comportant plus de 1 000 enregistrements. Le délai d’expiration de la transaction est de 60 secondes ou deux minutes ; il s’agit de la durée maximale allouée. Le délai d’expiration de la transaction comprend les processus métier et les problèmes de réseau pour chaque système et n’est pas directement lié au nombre d’enregistrements. Chaque délai d’expiration peut s’ajouter à la durée d’implémentation d’une transaction.
Pour les transactions de synchronisation en direct depuis Dataverse vers les applications de finances et d’opérations, ces concepts ont légèrement changé. Le nombre de transactions est déterminé par la limitation basée sur les priorités associée à l’environnement. Souvent, la double écriture n’atteint pas ces limites, mais les connaître est un bon point de référence si ces problèmes surviennent. Aucune limite actuelle n’est imposée au nombre d’enregistrements dans une transaction, mais la transaction doit être terminée dans le délai d’expiration de deux minutes. Le type de processus métier sous-jacent aux entités dans les applications de finances et d’opérations est complexe et présente souvent une logique métier qui s’exécute dans le cadre de cette transaction, ce qui contribue également à la fenêtre d’expiration de deux minutes.
Pour en savoir plus, consultez Limites d’API pour la protection du service et Hiérarchisation des limitations.