Je tente une migration sur un projet historique (donc un peu conséquent en terme de code) qui est en version 5.3 vers la version 6.2 de Simplicité.
Pour faire la migration, j’ai exporté mon module depuis mon instance 5.3, j’ai créé une instance simplicité 6.2 puis j’ai importé mon module sur mon instance 6.2.
Après quelques minutes, j’ai cette erreur dans les logs système :
2025-06-03 10:08:25,975|SIMPLICITE|ERROR||http://XXXXXXXXXXXXX:XXXX||ERROR|system|com.simplicite.util.AsyncTracker|error||Event: Error importing module ScenarioNG: Error in import XML, see logs for details
Et donc les autres logs details :
Une multitude de “start import object” puis une erreur à la fin :
Error during XML processing: java.lang.NullPointerException: Cannot invoke "com.simplicite.util.integration.TagXML.setObject(com.simplicite.util.integration.ObjectXML)" because "tag" is null
Je ne sais pas à quel objet ca crash, rien de plus dans les logs…Je n’arrive pas à interpréter la cause de ce problème…pourriez-vous m’aider?
D’ailleurs, je ne vois pas dans la documentation une explication sur une préconisation quant à la façon de faire une migration de version majeure de simplicité.
Je vais tenter en parallèle de faire la méthode inverse : monter un serveur 5.3.71 de dernière version et me connecter a ma base de données en 5.2.4X puis faire de même avec un serveur 6.2.X et me connecter a nouveau a ma BDD qui est en 5.3.71 afin qu’il fasse la maj, ca marche peut-être mieux comme ca.
Il ne sert à rien d’exporter et d’importer votre module, la migration 5.3>6.2 va upgrader directement vos modules en base. L’import d’un “vieux” module exporté dans un modèle plus récent risque de faire perdre des données de paramétrage (les tag XML ne sont plus forcement les mêmes).
Sinon il faudrait récupérer le fichier log d’import XML (menu Exploitation/Supervision des imports). Il donne le détail des objets importés et vous y trouverez quel paramétrage ne s’importe pas bien.
Le reste est généralement une conséquence du premier problème, par exemple si un objet ne se crée pas bien, tout ce qui le référence ne s’importera pas non plus.
Effectivement, ca fonctionne mieux en faisant comme ca. Il serait préférable d’avoir une section dédié dans la documentation pour expliquer la marche à suivre car c’est plutôt contre intuitif par rapport à du développement classique.
Sinon, dans les logs, impossible de debug car aucune indication n’est présente pour expliquer quel objet n’arrive pas à fonctionner (je l’ai mis en quote). Et l’import ne se fait pas dans l’ordre du fichier XML non plus.
Je ne comprends pas la remarque, pouvez vous préciser cet argument ?
Nous allons ajouter une section pour indiquer comment faire la migration, puisque c’est normalement ultra simple : il suffit d’upgrader le socle (via sim ou docker) et de le redémarrer, tous les patchs s’appliqueront au démarrage (ou bloqueront l’installation si votre environnement est non conforme).
Ensuite, dans un monde low-code il y a forcement une phase d’analyse d’impact sur le code, il faut suivre les release notes qui indiquent ce qui est déprécié ou à revoir en terme de breaking change (changement de lib, jdk…). Quand il y a beaucoup de code spécifique, en général il faut refactorer qq packages ou appels de méthodes pour que tout re-compile. Mais il nous est impossible de savoir/documenter ce qui pourrait ne pas/plus fonctionner dans un cas particulier, il faut alors passer par le forum/support, tout comme vous le faites sur stack-overflow, vous ne demandez pas à Oracle de documenter un NPE.
Pouvez vous nous envoyer le fichier de logs d’import ? il suffit de rechercher ERROR.
L’import est multi-threadé pour aller plus vite. Les blocks <data> d’un même <object> sont chargés en //. mais les blocks <object> sont bien chargés dans l’ordre.
Comme je l’ai cité dans mon premier message, c’est la dernière ligne de mon import. Aucune autre erreur avant malheureusement.
C’est contre intuitif selon moi car dans du développement classique, je met à jour mon code source (qui serait mon module) sans toucher mon serveur tomcat ou ma base de données. Mais ce n’est qu’une question de point de vue. Effectivement, c’est ultra simple quand on a l’explication. Et ne pouvant profiter de docker et de SIM, la solution n’était pas évidente pour l’équipe.