Conception de personnalisation évolutive : exemple de numérotation automatique

Notes

Ct exemple prend en charge une série de rubriques concernant la conception de personnalisation évolutive. Pour commencer dès le début, voir Conception de personnalisation évolutive dans Microsoft Dataverse.

Un scénario qui illustre le malentendu largement répandu sur le traitement des transactions dans Dataverse pour la mise en œuvre d’un schéma de numérotation automatique.

Dans ce scénario, l’exigence consiste généralement à :

• Générer un numéro unique suivant un modèle particulier.
• Permettre à de nombreuses demandes simultanées de créer un type d’enregistrement associé ; par exemple, des comptes qui nécessitent une référence unique.
• Permettre la numérotation séquentielle des numéros uniques.
• Vérifier que la génération de numéros est cohérente, mais évolutive, et ne renvoie pas d’erreur lors du chargement. Il convient également de s’assurer que des numéros en double ne puissent pas être générés.
• Générer le numéro à la création de l’enregistrement adéquat.

L’approche courante comporte des variations des méthodes suivantes :

• Stocker le dernier numéro employé dans une banque de données d’index de numérotation automatique ; par exemple, une entité personnalisée avec un type de ligne par donnée.
• Récupérer le dernier numéro employé et l’incrémenter.
• Enregistrer le nouveau numéro avec le nouvel enregistrement généré.
• Stocker à nouveau le nouveau numéro en tant que numéro employé en dernier dans le magasin d’index de numérotation automatique.

Les sections suivantes décrivent les différentes approches qui peuvent être adoptées dans Dataverse et mettent en évidence les implications, en présentant l’importance et les avantages de comprendre la manière dont les transactions sont utilisées.

Approche 1 : En dehors d’une transaction

L’approche la plus simple consiste à réaliser que toute utilisation d’une ressource couramment requise peut introduire le risque de blocage. Du fait que cela a un impact sur l’évolutivité, vous souhaiterez peut-être éviter une transaction de plateforme lors de la génération d’un numéro automatique. Considérons le scénario de génération de numéros automatique en dehors de la transaction de pipeline dans un plug-in de prévalidation.

Lorsque vous exécutez cette approche en isolation, elle fonctionne parfaitement. Toutefois, elle ne protège pas contre les erreurs de concurrence. Lorsque le schéma suivant s’affiche, si deux requêtes demandent parallèlement le dernier numéro, puis incrémentent et mettent à jour la valeur, vous vous retrouvez avec des numéros en double. Puisqu’il n’existe pas de verrouillage maintenu sur le numéro récupéré, il est possible qu’une condition de concurrence se produise et que les deux threads se retrouvent avec la même valeur.

Dans de nombreux cas, même si plusieurs demandes peuvent se produire, en raison de la fenêtre limitée pour un chevauchement, cela peut très bien fonctionner, mais éviter la duplication repose sur la chance plutôt que sur une bonne conception.

Approche 2 : Dans une transaction de plug-in

Si vous effectuez la numérotation automatique à partir d’un plug-in enregistré dans la transaction (txn), cela doit fonctionner... non ?

Dans les mêmes circonstances de demandes se chevauchant essayant de générer des numéros en même temps, il serait possible que les deux demandes se voient accorder un verrou de lecture partagé dans la table de numérotation automatique. Malheureusement, au moment où l’application essaie de le mettre à niveau vers un verrou exclusif, cela n’est pas possible, car il existe un autre verrou de lecture partagé l’empêchant.

Selon la façon dont les requêtes sont générées, le comportement exact peut varier, mais compter sur ces conditions et ne pas être certain du résultats où l’unicité est essentiel n’est pas idéal. Même si cela ne génère pas d’échec, la capacité de lecture partagée peut permettre de générer un numéro en double si les modes d’isolation ne sont pas corrects. Lorsque le schéma suivant s’affiche, les deux enregistrements se retrouvent avec la même valeur de numéro automatique de 8.

Approche 3 : Verrou préalable dans une transaction de plug-in

Comprendre la façon dont les transactions fonctionnent permet de générer de manière sécurisée.

Dans cette approche, dès le début de la transaction, une mise à jour d’espace réservé est effectuée sur l’enregistrement de numérotation automatique d’un certain champ (par exemple, UpdateInProgress) utilisé uniquement en vue de conserver de la cohérence. Celle-ci est obtenue en écrivant une mise à jour indiquant qu’une mise à jour est sur le point de commencer. Ce processus demande et obtient ensuite un verrou en écriture exclusif sur cette ligne de la table de numérotation automatique, qui empêche d’autres processus de démarrer l’approche de numérotation automatique.

Cela vous permet ensuite d’incrémenter et d’écrire de manière différée en toute sécurité le numéro automatique mis à jour sans qu’un autre processus puisse s’en mêler.

Elle implique la sérialisation non seulement des mises à jour de la numérotation automatique mais aussi les demandes de création de compte, car ces deux étapes se produisent dans la même plateforme de transaction. Si la création de comptes se compose d’actions rapides, cela peut constituer une approche idéale et garantit que la création de compte et la numérotation automatique sont exécutées de manière cohérente ; si l’une d’elles échoue, elles échouent toutes les deux et entraînent une restauration.

En fait, lorsque les autres actions de la transaction sont rapides, cela constitue l’approche la plus cohérente et la plus efficace pour implémenter la numérotation automatique dans les personnalisations.

Toutefois, si vous introduisez également d’autres workflows ou plug-ins synchrones qui prennent chacun beaucoup de temps à s’exécuter, la sérialisation peut devenir un vrai défi en termes d’évolutivité, car le processus de numérotation automatique non seulement se bloque lui-même mais attend que les autres activités se terminent.

En règle générale, la génération de numéros automatiques peut être effectuée dans un plug-in pré-événementiel. Vous pouvez inclure le numéro dans les paramètres d’entrée à l’étape de création et éviter une seconde mise à jour du post-traitement pour enregistrer le numéro automatique généré par rapport au compte.

Avec les implications de l’évolutivité à l’esprit, s’il existe un autre traitement complexe dans le processus de création de compte, une alternative serait de déplacer la génération de numéro automatique dans un processus de post-création, qui garantit toujours un processus de mise à jour cohérent. L’avantage est qu’il réduit la durée pendant laquelle le verrou de l’enregistrement du numéro automatique est conservé dans la transaction, car le verrou est enlevé uniquement à la fin du processus. Si la table de numérotation automatique est la ressource la plus de contestée et que cette approche est adoptée pour tous les processus y accédant, cela permet de réduire la quantité globale de compétition.

Le compromis serait ici la nécessité d’effectuer une mise à jour supplémentaire du compte, tout en réduisant la durée globale du blocage en attendant l’enregistrement de la numérotation automatique.

Notes

Pouvez-vous nous indiquer vos préférences de langue pour la documentation ? Répondez à un court questionnaire. (veuillez noter que ce questionnaire est en anglais)

Le questionnaire vous prendra environ sept minutes. Aucune donnée personnelle n’est collectée (déclaration de confidentialité).