Vendredi dernier nous avons fait un nouveau déploiement sur notre Docker Simplicité. En faisant un export XML du module et un export des data via les boutons Simplicité prévu dans le module comme habituellement.
Nous nous sommes rendu compte que nos modèles de données créé via le modeler ne se sont pas bien importés. En effet, le nombre d’item sur le modèle est le même; mais ce ne sont pas les mêmes items qui s’affichent par rapport à l’ancien déploiement.
Nous n’avons pas encore utilisé les nouvelles fonctions du modeler sur la prod, c’est juste des modèles via le paramétrage Simplicité classique.
Avez-vous des idées de pourquoi les modèles ne se sont pas bien importés ?
Le modeleur tente de retrouver le row_id à partir des données de la clé fonctionnelle stockée dans le des meta-data du fichier SVG.
S’il trouve la clé fonctionnelle de l’objet issu du fichier SVG, il utilise le nouveau row_id trouvé : ceci implique que votre modèle métier soit compatible entre votre source et votre base cible (même nom d’objet + même clé fonctionnelle composite)
Puis il tente un select sur le row_id (retrouvé à partir des champs clés ou à défaut celui fourni dans le SVG), s’il ne trouve pas le row_id il retire l’objet du modèle.
Le code Simplicité a été renforcé :
pour rendre thread-safe la lecture d’un objet par le modeleur côté back (les appels étaient synchronisés par la UI c’était peut être insuffisant).
pour sérialiser la clé en JSON plutôt qu’avec des “;” dans le service qui synchronise les données
(si une de vos données contenait des “;” il se peut que ça ait décalé les champs clés)
Il faut donc dans un premier temps comparer vos modèles métier source/cible. Il est possible de corriger un modèle SVG à la main (renommer les objets…) puisque ce format est textuel/xml.