Rappels concernant les réservations d’entité

Les “réservations d’entités” est le titre d’un fonction/fonctionnement historique des zooms ERP (et d’autres traitements) qui permet de sécuriser les modifications de données en cas d’accès simultané multiple, lorsqu’un utilisateur veut faire une modification sur une entité (article, client, pièce etc. …) .

Ainsi, un zoom ERP (Divalto infinity ou divalto one 'Expérience Classique') utilise les réservations selon un mode “Pessimiste”, c’est à dire que l’on va poser une réservation(=un verrou) sur une entité dès lors qu’un utilisateur entre en modification sur l’entité, et le libérer à la fin de la modification.

Si un autre utilisateur essaie alors d’entrer lui aussi en modification sur la même entité, l’ERP va lui afficher un message indiquant que l’entité est réservée, et il ne pourra pas faire ses modifications (visuellement, l’entité restera affichée en mode consultation) ; le traitement peut aussi sous conditions patienter jusqu'à la libération par le second utilisateur et poser le verrou plus tard.

Les réservations avec divalto one

Avec divalto one arrive un changement de paradigme sur la méthode de réservation des entités.

Lorsqu’un utilisateur veut modifier une entité, les réservations se font sur le mode “Optimiste“, c’est à dire que l’on ne vérifie pas si un autre utilisateur est déjà en modification sur la même entité. La vérification se fait au moment où l’utilisateur va vouloir valider ses changements : l’ERP va alors vérifier si un autre utilisateur a déjà fait (= validé et sauvegardé) une modification entre le moment où l’utilisateur a chargé l’entité et le moment où il veut sauvegarder.

Si une modification a été faite par quelqu’un d’autre entretemps, la validation sera refusée et l’utilisateur devra d’abord recharger l’entité avant de pouvoir faire ses modifications.

Technique pour la réservation divalto one

Ce fonctionnement est assuré par une colonne supplémentaire sur chaque table : xxx_ROWVERSION (où xxx est le nom de la table, par exemple ART_ROWVERSION, ENT_ROWVERSION etc. …).

Au moment où l’utilisateur ‘USER1' va vouloir sauvegarder ses modifications, l’ERP via la couche Harmony va vérifier si le ROWVERSION de l’entité chez l’utilisateur ‘USER1’ correspond au ROWVERSION dans la base. Si ce n’est pas le cas, cela signifie qu’un autre utilisateur ‘USER2’ a entretemps sauvé une version plus récente de l’entité que la version dont dispose ‘USER1’ , et donc il faut d’abord que ‘USER1’ fasse un rafraîchissement de son entité en rechargeant celui-ci (donc les données modifiées par 'USER2’) avant de pouvoir faire ses modifications.

ROWVERSION est donc incrémenté à chaque sauvegarde par un utilisateur, pour chaque entité sauvegardée dans la base.

C’est l’utilitaire XPSQL qui permet via le menu ‘Ajout du champ Rowversion’ qui permet cet ajout