Conception de personnalisation évolutive dans Microsoft Dataverse

Dataverse se protège et ses utilisateurs contre les activités longues qui pourraient affecter les temps de réponse pour l’utilisateur effectuant une requête et la stabilité et la réactivité du système pour d’autres utilisateurs.

Un défi rencontré par certaines personnes qui implémentent des solutions Dataverse est des erreurs levées par la plateforme ou la base de données Microsoft SQL Server sous-jacente lorsque ces mesures de protection prennent effet. Ces erreurs sont souvent interprétés comme si la plateforme ne pouvait pas se mettre à l′échelle ou mettait fin ou limitait les demandes de manière incorrecte dans le système.

Ce contenu est basé sur des expériences d’examen et de résolution des véritables causes sous-jacentes de la plupart de ces types de défis. Ces articles décrivent comment la plateforme se protège contre l’impact de ces demandes imposées sur le système et explique pourquoi ce comportement est le plus souvent le résultat d’implémentations personnalisées qui ne comprennent pas l’impact sur le blocage et l’utilisation des transactions au sein de la plateforme.

Ce contenu décrit également comment l’optimisation d’une implémentation personnalisée pour éviter ces types de comportements n’évitera pas seulement les erreurs de plateforme, mais permet également d’améliorer les performances et les expériences des utilisateurs finaux en conséquence. Il fournit de bonnes pratiques de conception et identifie les erreurs courantes à éviter.

Le défi

L’examen et la résolution des problèmes dans ce domaine commencent généralement lorsque certains types d’erreurs et de symptômes apparaissent dans le système. Ces erreurs et symptômes sont souvent perçus comme des problèmes dans la plateforme et l’étape corrective nécessaire consiste à relâcher les contraintes de plateforme qui déclenchent généralement une demande d’exécution lente pour devenir une erreur signalée.

En réalité, bien que les erreurs puissent être évitées à court terme en assouplissant certaines des contraintes de plateforme, ces contraintes sont là pour de bonnes raisons et sont conçues pour empêcher une action excessivement longue d’affecter d’autres utilisateurs ou performances du système. Bien que les contraintes puissent être assouplies pour éviter les erreurs, les utilisateurs subissent toujours des temps de réponse lents, et ces problèmes de performances affectent également l’expérience d’autres utilisateurs du système.

Par conséquent, il est préférable d’examiner les causes racines de la raison pour laquelle ces contraintes sont déclenchées et provoquant des erreurs, puis d’optimiser les personnalisations du code pour les éviter. Cette approche offre un système plus cohérent et plus réactif pour les utilisateurs.

Symptômes courants

Ces types de problèmes présentent généralement une combinaison de symptômes courants, comme indiqué dans le tableau suivant.

En réalité, une combinaison de ces symptômes peut et souvent être signalée ensemble lorsque ces défis sont rencontrés. Ce n’est pas toujours le cas que ces symptômes sont un indicateur de problèmes avec la conception. D’autres problèmes, tels que les limitations d’E/S de disque dans la base de données ou un bogue de produit, peuvent entraîner des symptômes similaires. Mais la cause la plus courante de ces types de symptômes, et par conséquent, une vérification digne d’intérêt, concerne directement la conception de l’implémentation personnalisée et la façon dont elle affecte le système.

Pourquoi devrions-nous nous inquiéter ? Dataverse ne s’occupe-t-il pas de cela... ?

C′est le cas dans une certaine mesure... Mais il utilise le verrouillage et les transactions pour protéger le système contre les conflits si nécessaire.

Nous vous proposons également des options permettant de faire des choix sur votre scénario particulier et de décider où il est important de contrôler l’accès aux données. Mais ces choix peuvent être faits de manière incorrecte et il est possible d’introduire des conséquences inattendues dans le code personnalisé. Ces problèmes ont généralement un impact sur l’expérience utilisateur par le biais de temps de réponse plus lents afin de comprendre les implications de certaines actions peut entraîner des résultats plus cohérents et meilleurs pour les utilisateurs.

Comprendre les causes

Les symptômes courants ont des causes qui forcent des demandes spécifiques à s′exécuter lentement et à déclencher ensuite des contraintes de plateforme. Le diagramme suivant présente des symptômes typiques avec certaines des causes racines courantes de ces symptômes.

L’impact sous-jacent des transactions longues, du blocage de base de données et des requêtes complexes peut se chevaucher et amplifier leurs effets pour provoquer ces symptômes. Par exemple, une série de requêtes longues qui sont indépendantes les unes des autres peut entraîner des temps de réponse utilisateur lents, mais seulement une fois qu’ils ont besoin d’accéder aux mêmes ressources, les temps de réponse deviennent si lents qu’ils deviennent des erreurs.

Conception pour les contraintes de plateforme

La plateforme Dataverse a de nombreuses contraintes délibérées qu’elle impose pour empêcher toute action ayant un impact trop néfaste sur le reste du système et, par conséquent, sur les utilisateurs. Bien que ce comportement puisse être frustrant, car il peut empêcher l’exécution de requêtes spécifiques et conduit souvent à des questions sur la possibilité de lever les contraintes, il s’agit rarement d’une bonne approche lorsque vous tenez compte des implications plus larges.

Lorsque la plateforme est utilisée comme prévu et qu’une implémentation est optimisée, il est rare qu’il existe un scénario où ces contraintes seraient rencontrées. L′exécution dans la contrainte est presque toujours une indication de comportements qui relieront ressources excessivement dans le système. Cela signifie que d’autres requêtes provenant du même utilisateur ou d’autres utilisateurs ne peuvent pas être traitées. Ainsi, bien qu’il soit possible de relâcher la contrainte sur la demande bloquée, ce que cela signifie réellement est que les ressources qu’il consomme sont liées pour encore plus longtemps, ce qui entraîne des impacts plus importants sur d’autres utilisateurs.

Au cœur de ces contraintes, l’idée que la plateforme Dataverse est conçue pour prendre en charge une application transactionnelle multi-utilisateur où la réponse rapide à la demande des utilisateurs est la priorité. Il n’est pas destiné à être une plateforme pour un traitement par lots ou à long terme. Il est possible de piloter une série de courtes requêtes vers Dataverse, mais Dataverse n’est pas conçu pour gérer le traitement par lots. De même, lorsqu’il existe des activités exécutant un traitement itératif volumineux, Dataverse n’est pas conçu pour gérer ce traitement itératif.

Dans ces scénarios, un service distinct peut être utilisé pour héberger le processus de longue durée, conduisant à des requêtes transactionnelles plus courtes vers Dataverse lui-même. Par exemple, l’utilisation de Flow ou l’hébergement de Microsoft SQL Server Integration Services (SSIS) ailleurs, puis envoyer des requêtes individuelles de création ou de mise à jour vers Dataverse est un meilleur processus que l’utilisation d’un plug-in pour parcourir des milliers d’enregistrements créés dans Dataverse.

Il vaut la peine d’être conscient et de comprendre les contraintes de plateforme qui existent, afin que vous puissiez les autoriser dans la conception de votre application. En outre, si vous rencontrez ces erreurs, vous pouvez comprendre pourquoi elles se produisent et ce que vous pouvez modifier pour les éviter.

Étapes suivantes

Pour comprendre comment les contraintes de plateforme sont appliquées, il est nécessaire de comprendre les transactions de base de données. Plus d’informations : Conception de personnalisation évolutive : Transactions de base de données