Comparateur de modules (source XML) inopérant en P22

4.0
Tags: #<Tag:0x00007f7d6fbc7048>
Comparateur de modules (source XML) inopérant en P22
0

(Bruno Montagnac) #1

Bonjour,

L’outil de comparaison de modules (format d’export XML) est inopérant en P22.

Dans l’exemple ci-dessous, le module a été importé (import XML suivi d’un purge cache global) avant d’utiliser la fonction de comparaison en fournissant le même fichier XML que lors de l’import.

La fonction de comparaison semble ne pas réussir à faire un diff entre la configuration “en ligne” et celle fournie dans le fichier XML fourni dans le formulaire d’upload.

ps: cela fonctionnait a priori toujours en P20 et P21 et P22 pré-release (dernier usage de la fonction durant les mois de septembre/octobre sur l’instance précédemment nommée renault-dev et désormais nommée bcsi.renault).


(François Genestin) #2

Je ne pense pas qu’on ait touché à ce comparateur entre ces versions. Par contre on a changé l’IHM d’import XML mais cela ne doit pas impacter le contenu du fichier.

On a déjà remarqué que le comparateur considère parfois certains objets en “annule et remplace” mais sur les listes de valeurs.

Je vais refaire des tests sinon il faudra qu’on analyse votre XML unitairement.

Note : L’import de module ne doit pas passer par l’import XML (de données quelconque) qui ne fait pas un diff final de module (si aucune erreur n’est détectée, cela supprime les définitions obsolètes), il faut utiliser la fonction d’export/import depuis l’objet Module avec l’upload du fichier XML ou ZIP.


(Bruno Montagnac) #3

Bonjour François,
merci beaucoup pour ton retour rapide.
Nous n’utilisons effectivement pas l’import XML pour mettre à jour nos modules mais la fonction de comparaison (qui fait un diff).
Afin de vérifier le comportement de cette fonction, j’ai importé un nouveau module contenant une ressource de type script (pour tester) dans l’instance simplicite.io par la fonction import XML puis j’ai utilisé la fonction de comparaison depuis ce nouveau module (après un clear cache) en lui fournissant le même fichier XML en entrée. La comparaison aurait dû retourner “aucune diff” mais au lieu de cela elle retourne deux DEL et deux NEW afférents au nom du module et au script qu’il contient.
Je ne paux pas dire depuis quand ce problème est apparu car nous sommes toujours en P19 sur nos env de recette et de production (nous envisageons toujours un upgrade avant la fin de l’année de ces deux envs) et sur ces environnements, cela fonctionne bien.
ps: comportement reproduit en ui responsive et legacy…


(François Genestin) #4

Problème reproduit lorsqu’on compare avec un fichier XML.

Visiblement l’export du module “en mémoire” n’est pas comparable avec le parsing XML du fichier au niveau des clés fonctionnelles des objets. On va corriger.


(François Genestin) #5

C’est corrigé, il y avait plusieurs problèmes de comparaison entre un export XML du module en mémoire (qui contient plus d’information comme les clés fonctionnelles, les id des documents…) et un fichier plat (qui ne contient que les données non techniques).


(Bruno Montagnac) #6

Bonjour François, merci beaucoup pour ton action. Le problème de diff est corrigé:

Cependant, lorsque je passe à l’étape suivante de génération du patch XML, le contenu du patch est vide:

La trace générée lors du calcul du patch est la suivante:

2018-11-28 17:22:16,093 ERROR [com.simplicite.workflows.WorkflowUser.ModuleDiff] SIMPLICITE|http://renault:10028||ERROR|system|com.simplicite.workflows.WorkflowUser.ModuleDiff|displayResult||Evénement: Error processing diff 
    java.lang.Exception: Empty target 
    	at com.simplicite.workflows.WorkflowUser.ModuleDiff.displayResult(ModuleDiff.java:284) 
    	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
    	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 
    	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) 
    	at java.lang.reflect.Method.invoke(Method.java:498) 
    	at com.simplicite.bpm.Processus.invokePageMethod(Processus.java:449) 
    	at com.simplicite.webapp.ProcessForm.getExternalContent(ProcessForm.java:627) 
    	at com.simplicite.util.tools.JSONTool.activityDataToJson(JSONTool.java:2800) 

ps: je ne trouve plus comment basculer en interface classique sur l’instance cloud (P23)… est-ce annonciateur de la fin de la vénérable interface legacy à partir de cette release?


(Bruno Montagnac) #7

Bonjour François,

à nouveau, merci beaucoup pour ton support et la correction apportée sur la P22.
J’ai encore un problème résiduel sur le diff des scripts: il semble que l’XML généré à la volée sur l’environnement cible n’inclue pas les documents comme cela était le cas précédemment (probablement lié à l’option inlinedocs=true lors de l’appel de la méthode d’export module). De ce fait, l’étape de comparaison trouve une différence systématiquement en comparant l’id du script avec le contenu proposé.

Ce n’est pas bloquant car le patch XML contiendra bien le nouveau code mais ça dégrade notre processus de livraison car le différentiel entre l’ancien et le nouveau code (contenu du script) n’est plus restitué.

NB: comme vu avec David jeudi dernier, nous nous appuyons sur cette fonction pour identifier précisément et contrôler ce qui sera déployé sur notre environnement de production (et accessoirement en extraire les inputs de notre release note).


(François Genestin) #8

Exact il doit y avoir une erreur de sérialisation des documents. je vais regarder ça.
Pour les contenus binaire (image, pdf ou autre) on va devoir comparer les encoding en base64 si c’est possible.


(François Genestin) #9

En fait le patch en mémoire était bon, c’est l’affichage de cette activité qui était fausse.
J’ai corrigé ce problème pour mieux visualiser les contenus à l’écran

  • des document avec l’affichage du diff textuel (et non un doc Id à gauche)
  • et des images (on compare le base64 et non la ressemblance des images ;-)

Ce sera à tester dans la prochaine prerelease qui ne devrait pas tarder à partir en release.


(David AZOULAY) #10

Poussé sur la branche prerelease (et donc sur l’image Docker “beta”)


(Bruno Montagnac) #11

Bonjour François, David,

merci beaucoup pour votre réactivité. Le fix est redéployé et validé sur nos environnements de DEV et de recette. Nous mettons à niveau l’environnement oper actuellement en P19 demain midi (afin de revenir dans les clous!).

Bruno