Traitement asynchrone des transactions en cascade
Certaines transactions peuvent être configurées en cascade dans tous les enregistrements associés. Cela signifie que la modification d’un enregistrement parent est propagée (en cascade) sur tous les enregistrements enfants. Les relations en cascade sont configurées au niveau de la table. Pour plus d’informations sur les relations de cascade, voir Configurer le comportement en cascade des relations de table.
Mode synchrone et mode asynchrone
Par défaut, les opérations en cascade sont traitées comme une transaction synchrone. Pour une transaction en cascade synchrone, tous les enregistrements concernés sont identifiés par le système. Lorsque les enregistrement sont traités, ils sont verrouillés par le système. Une fois toutes les modifications terminées, les enregistrements sont déverrouillé et la transaction est terminée.
Les transactions synchrones avec un grand nombre d’enregistrements peuvent entraîner des problèmes de performances dans les environnements lorsque de longues transactions échouent en raison d’une interruption du serveur. Les enregistrements sont verrouillés pour empêcher d’autres tâches et transactions utilisateur qui utilisent les mêmes enregistrements de s’exécuter. En outre, les transactions longues peuvent entraîner un retard dans les transactions et les requêtes en attente qui diminuent les performances système et peuvent provoquer un arrêt du travail.
Si un environnement rencontre des interruptions ou des performances détériorées pendant que les opérations en cascade synchrones sont en cours, votre environnement peut bénéficier de l’activation du mode asynchrone. Les principales différences entre les modes sont décrites dans le tableau suivant.
| Mode synchrone | Mode asynchrone |
|---|---|
| Aucune autre tâche ne peut être effectuée dans l’ensemble d’enregistrements sélectionnés (directe ou en cascade) jusqu’à ce que l’opération en cascade se termine. | Pour Attribuer et Supprimer, les modifications en cascade sont groupées, verrouillant uniquement les enregistrements en cours de traitement dans le lot. Cela permet à d’autres tâches de s’exécuter pendant l’opération complète de modifications en cascade. |
| Lorsque la tâche est terminée, toutes les données affichent la nouvelle valeur souhaitée. | À mesure que la tâche s’exécute, chaque lot terminé affiche la valeur souhaitée. Cela signifie que pendant un temps, certaines données indiquent la valeur souhaitée et certaines affichent la valeur d’origine en attendant que l’opération complète se termine. Ceci est appelé « cohérence éventuelle ». |
| Si un seul enregistrement échoue, toutes les données sont restaurées à la valeur d’origine. La restauration nécessite une nouvelle édition de tous les enregistrements terminés, ce qui prend plus de temps. | Si une seule tâche échoue, elle est réexécutée plusieurs fois pour tenter de la terminer. Si la tâche ne peut pas être terminée, l’échec est enregistré dans la zone Tâches système. Notez que les enregistrements terminés avec succès conservent la nouvelle valeur. |
| Si l’un des enregistrements de la liste en cascade a une valeur différente de la valeur attendue, la tâche échoue et est restaurée. Par exemple, supposons que l’enregistrement initial appartient à Propriétaire 1 et l’opération en cascade souhaite le modifier en Propriétaire 2. Si l’un des enregistrements associés en aval a été modifié en Propriétaire 3 ou est supprimé avant que le verrouillage ne se produise, toute la tâche est restaurée. | Pour Attribuer, l’opération fonctionne toujours en mode de remplacement en remplaçant la valeur actuelle par la nouvelle valeur basée sur la relation parent-enfant. Il n’y a pas d’échec de tâche en raison d’une non-correspondance de valeur d’origine. Pour Supprimer si un enregistrement qui était prévu dans le cadre de l’ensemble est manquant, tous les enregistrements jusqu’au point de défaillance sont considérés comme terminés. L’utilisateur ou l’administrateur peut réexécuter la tâche ayant échoué, ce qui recalcule la tâche pour continuer sans l’enregistrement manquant. Pour Fusionner, s’il y a un problème avec un enregistrement manquant, une nouvelle tentative est effectuée et la tâche est exécutée sans l’enregistrement manquant. |
Mode Asynchrone
Lorsqu’une transaction en cascade atteint le seuil des enregistrements inclus, les enregistrements sont traités de manière asynchrone,
| Operation | Seuil |
|---|---|
| Assign | 1 000 enregistrements |
| Delete | 5,000 enregistrements |
| Fusionner | 1 000 enregistrements |
Suivi de la progression de l’opération asynchrone
Les administrateurs peuvent surveiller le traitement d’opérations asynchrones dans la zone Paramètres.
Connectez-vous au Centre d’administration Power Platform.
Sélectionnez Environnements dans la zone du navigateur. Ensuite, sélectionnez l’environnement souhaité.
Sélectionnez Paramètres, développez Audit et journaux, puis sélectionnez Tâches système.
Les opérations en cascade sont affichées dans la vue Tâches système.
Pour afficher uniquement des opérations en cascade, dans le sélecteur Afficher, sélectionnez Opérations de cascade.
Les opérations en cascade ont l’un des statuts suivants :
- Terminé : tous les lots de la transaction en cascade ont été terminés avec succès.
- En cours : des modifications en cascade sont en cours.
- Échec : après plusieurs tentatives, certaines des modifications en cascade ont échoué.
Note
Il est impossible d’annuler une tâche en cascade asynchrone. Vous devez attendre qu’elle se termine en désignant un statut Terminé ou Échec.
Ouvrir une opération en cascade affiche :
Le nombre de tentatives pour la transaction donnée.
Les dates et heures de création et de fin.
Le créateur de la tâche.
Tous les messages associés à la tâche, par exemple les raisons de l’échec, ou les exceptions.
Quelles transactions en cascade peuvent être traitées de manière asynchrone ?
Les transactions en cascade Attribuer, Supprimer et Fusionner peuvent être traitées de manière asynchrone.
Note
D’autres transactions, telles que Partager/Annuler le partage et Redéfinir la parenté sont actuellement en cours d’examen pour le traitement asynchrone.
Résolution des problèmes liés aux opérations en cascade asynchrones
Lorsque des travaux en cascade synchrones échouent, ils arrêtent et annulent toutes les modifications afin qu’aucun des enregistrements n’inclut les modifications demandées. Ce processus peut prendre du temps, car les restaurations peuvent prendre autant de temps que la tentative d’origine et une nouvelle tentative d’exécution de l’opération redémarre à partir du premier enregistrement.
Les opérations asynchrones sont réexécutées plusieurs fois en cas d’échec. Dans la plupart des cas, la réexécution de la tâche aboutit et la tâche peut continuer jusqu’à son terme. Dans certains cas rares, la réexécution ne résout pas le problème. Lorsque cela se produit, la tâche asynchrone est interrompue et l’administrateur et l’utilisateur peuvent résoudre le problème et reprendre la tâche là où elle a été interrompue.
Causes courantes des échecs dans les opérations en cascade
Les raisons courantes des échecs dans le traitement des opérations en cascade incluent :
- Exceptions de plug-in
- Exceptions de sécurité
Exceptions de plug-in
Des plug-ins sont ajoutés au traitement des opérations en cascade pour effectuer des actions spécifiques lorsque des modifications sont apportées à un enregistrement, telles que l’envoi d’un e-mail ou le déclenchement d’une mise à jour différente sur d’autres enregistrements. Ceux-ci peuvent être fournis par des tiers ou développés en interne. Si un plug-in génère une exception, l’opération en cascade échoue. Selon la raison de l’exception, une nouvelle tentative peut résoudre le problème. Si la tâche en cascade asynchrone est interrompu en raison d’échecs, validez tous les plug-ins associés aux opérations pour vous assurer qu’ils ne génèrent pas d’exceptions. Une fois corrigée, la tâche peut être reprise.
Exceptions de sécurité
Les exceptions de sécurité se produisent lorsque l’utilisateur qui a exécuté l’opération en cascade ne dispose pas de privilèges suffisants pour apporter une modification à un ou plusieurs enregistrements, ou lorsque l’utilisateur est désactivé ou supprimé du système.
Si l’utilisateur est toujours présent dans le système, vérifiez qu’il dispose des privilèges nécessaires pour modifier les enregistrements et qu’il est autorisé à exécuter les actions spécifiées. Une fois ce problème résolu, reprenez la tâche.
Si l’utilisateur a été désactivé ou supprimé du système, la réactivation ou le rajout de l’utilisateur résout le problème et la tâche peut reprendre. Cependant, si l’utilisateur doit être supprimé ou désactivé ou n’est pas censé disposer des autorisations pour les actions ou les enregistrements, la tâche doit être annulée et redémarrée par une personne disposant des autorisations appropriées.
Pour tout autre problème lié à des tâches ayant échoué, contactez le support. Microsoft Pour plus d’informations, voir Vue d’ensemble du support
Résolution des problèmes de suppression de fichiers lors de la fusion en cascade
Si vous rencontrez des échecs avec les opérations de fusion en cascade parce que les fichiers sont supprimés pendant l’exécution de la tâche, vous pouvez ignorer la vérification parentale. Cela permet à votre fusion de continuer même si quelqu’un supprime un enregistrement de l’ensemble pendant que la tâche s’exécute en arrière-plan. Lorsque vous choisissez de fusionner des enregistrements, en bas de la fenêtre de fusion, désactivez l’option La vérification de la parenté est activée par défaut. Décochez cette case pour ignorer la vérification de la parenté.
Exemple de fusion d’enregistrement
Imaginez que vous avez des comptes avec une relation de contact, qui a une relation avec les commandes. Vous souhaitez fusionner deux enregistrements de compte.
Si la tâche s’exécute avec succès, la fusion affecte tous les contacts associés et leurs commandes au compte cible.
Si, au cours du processus de fusion d’enregistrements, un autre utilisateur supprime un enregistrement de contact associé, mais que des enregistrements de commande existent toujours en rapport avec l’enregistrement de contact, la tâche de fusion échoue, car un parent d’un enregistrement enfant est manquant. Si vous choisissez d’ignorer la vérification de la parenté pendant la fusion d’enregistrements, les commandes avec l’enregistrement de contact manquant sont fusionnées dans l’enregistrement de compte cible. Cependant, aucun enregistrement de contact associé n’est attribué au compte cible et la tâche est terminée.
Fusion provoquant des verrous qui empêchent d’autres modifications d’accès
L’opération de fusion en cascade accorde l’accès au nouveau propriétaire de la table subordonnée. Pour ce faire, l’opération de fusion en cascade accède et apporte des modifications à la table d’objets principaux qui nécessitent un verrou. Si une opération de fusion contient de nombreux enregistrements (en fonction de la relation en cascade), ce verrou peut être en place pendant une durée prolongée. Cela peut entraîner une erreur si une opération tente d’accorder ou de révoquer l’accès à un enregistrement non lié pendant l’exécution de la fusion. Si cela se produit, essayez d’exécuter la fusion à un autre moment, afin que le blocage puisse être réduit.