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

Un scénario illustrant l’incompréhension courante de la façon dont les transactions sont gérées dans Dataverse implémente un schéma de numérotation automatique.

Dans ce scénario, l’exigence est généralement de :

• Générez un nombre unique suivant un modèle particulier.
• Autorisez de nombreuses demandes simultanées à créer le type d’enregistrements associé ; par exemple, les comptes qui ont besoin d’une référence unique.
• Autorisez la numérotation séquentielle des nombres uniques.
• Vérifiez que la génération de nombres est cohérente, mais évolutive et qu’elle n’échoue pas sous la charge. Il doit également s’assurer que les nombres en double ne peuvent pas être générés.
• Générez le nombre lors de la création de l’enregistrement approprié.

L’approche classique implique des variantes des éléments suivants :

• Stockez le dernier numéro utilisé dans un magasin de données d’index de numéros automatiques ; par exemple, une entité personnalisée avec une ligne par type de données.
• Récupérez le dernier nombre utilisé et incrémentez ce nombre.
• Enregistrez le nouveau nombre par rapport à l’enregistrement nouvellement 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 différentes approches qui peuvent être prises dans Dataverse et mettent en évidence les implications, présentant à la fois l’importance et l’avantage de comprendre la façon dont les transactions sont utilisées.

Approche 1 : Sortie d’une transaction

L’approche la plus simple consiste à réaliser que toute utilisation d’une ressource couramment requise introduireait le risque de blocage. Étant donné que le blocage a un impact sur l’extensibilité, vous pouvez décider d’é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 opération en isolation, elle fonctionne correctement. Toutefois, elle ne protège pas contre les erreurs d’accès concurrentiel. Comme le montre le diagramme suivant, si deux requêtes en parallèle demandent le dernier nombre, puis incrémentent et mettent à jour la valeur, vous finissent par des nombres 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 requêtes peuvent se produire, cela pourrait fonctionner correctement en raison de la fenêtre limitée de chevauchement, mais cela repose sur la chance plutôt que sur une bonne conception pour éviter la duplication.

Approche 2 : Dans une transaction de module d'extension

Si vous effectuez la numérotation automatique à partir d’un plug-in inscrit dans la transaction (txn), cela fonctionne sûrement....right ?

Dans les mêmes circonstances de chevauchement des requêtes qui tentent de générer des nombres en même temps, il serait possible que les deux demandes reçoivent un verrou de lecture partagé sur la table de numérotation automatique. Malheureusement, au moment où l’application tente de mettre à niveau ce verrou exclusif, cela ne serait pas possible, car il y aurait un autre verrou de lecture partagé empêchant cela.

Selon la façon dont les requêtes sont générées, le comportement exact peut varier, mais s'appuyer sur ces conditions sans être certain du résultat là où l'unicité est essentielle n'est pas idéal. Même si cela ne génère pas d’échec, la capacité de lecture partagée peut permettre la génération d’un nombre en double si les modes d’isolation ne sont pas corrects. Comme le montre le diagramme suivant, les deux enregistrements se retrouvent avec la même valeur de nombre automatique de 8.

Approche 3 : Pré-verrouillage dans une transaction de plug-in

Comprendre la façon dont les transactions fonctionnent mène à la génération d’un moyen sûr de le faire.

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. Cela se fait en consignant une mise à jour indiquant qu'elle est sur le point de démarrer. Ce processus demande ensuite et prend un verrou d’écriture exclusif sur cette ligne dans la table de numérotation automatique, ce 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 en toute sécurité le numéro automatique mis à jour sans aucun autre processus pouvant interférer.

Cela implique que cela sérialise non seulement les mises à jour de numérotation automatique, mais également les demandes de création de compte, car ces deux étapes se produisent dans la même transaction de plateforme. Si les créations de comptes sont des actions rapides, cela peut être une approche parfaitement correcte et garantit que la création de comptes et la numérotation automatique sont effectuées de manière cohérente ; si l'une échoue, les deux échouent et sont annulées.

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

Si toutefois vous introduisez également d’autres plug-ins ou workflows synchrones qui prennent chacun un temps étendu pour se terminer, la sérialisation peut devenir un véritable défi d’évolutivité, car le processus de numérotation automatique se bloque lui-même et bloque en attendant l’exécution des autres activités.

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 incluez le nombre dans les paramètres d’entrée de l’étape de création et évitez une deuxième mise à jour dans le post-traitement pour enregistrer le numéro automatique généré sur le compte.

Avec les implications de l’extensibilité à l’esprit, s’il existe d’autres traitements complexes dans le processus de création de compte, une alternative consiste à déplacer la génération de nombres automatiques vers un processus post-création, ce qui garantit toujours un processus de mise à jour cohérent. L’avantage serait qu’il réduit la durée pendant la transaction pendant laquelle le verrou d’enregistrement de numéro automatique est conservé, car le verrou n’est pris qu’à la fin du processus. Si la table de numérotation automatique est la ressource la plus contestée et que cette approche est prise pour tous les processus qui y accèdent, cela réduit la quantité de contention globale.

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.