et même principe pour le responsive5 est ce qu’il faut que je supprime toutes les ressources pour que la migration fonctionne car actuellement j’ai le même message d’erreur
UPGRADE FAULT
ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ
This version 6 does not support Rhino script anymore to implements Hooks.\n==> All legacy Rhino scripts have to be refactored to more efficient Java classes.
==> Rhino scripts are only dedicated to expressions, calculated fields and constraints.
ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ
De plus, j’ai regardé dans la table ’ m_script_usage` je n’ai que du code partagé sur des objets métiers mais en java donc est ce que ça peut poser problème étant donné que ce ne sont pas des scripts rhino ?
Merci d’avance et je ne sais pas si j’ai été assez clair
Le message indique qu’il vous reste du code serveur en Rhino (i.e. du JS serveur) rien à voir avec les ressources JS (i.e. du JS client), surtout celle de la disposition qu’il ne faut surtout pas supprimer.
Vous devez vérifier la présence de ces scripts Rhino avant d’envisager un upgrade en v6 où cela sera bloquant.
Vous pouvez identifier ces script Rhino en exécutant la requête:
select dbd_path from m_document
where dbd_path like '%.js'
and dbd_path not like 'Resource/%'
and dbd_path not like 'ModelTemplate/%'
PS: je vois que vous utilisez la révision 5.3.71 de fin mai, celle-ci n’est pas la révision de maintenance à jour de la v5, c’est la 5.3.73, il est important de toujours partir d’une révision parfaitement à jour pour effectuer une migration de version majeure et de même il faut toujours cibler la révision la plus à jour => au jour d’aujourd’hui il faut donc uniquement envisager un upgrade de la 5.3.73 vers la 6.2.12. La page Versions | Simplicité Documentation vous indique les révisions à jour:
Nous avons quelques résultats suite à la requête sql, néanmoins le fichier lié à disposition est tout de même présent est-ce qu’il faut que je le supprime ou non ?
Le .js de la Disposition n’est pas une ressource (sinon son path serait en Resource/*), c’est donc bien un script Rhino.
Tous ces fichiers Rhino sont à supprimer avant upgrade en v6, normalement ils auraient dû l’être à moins que certaines mises à jour v5 ne se soient pas passées correctement, c’est bien dans les patchs de la 5.3, ex:
Merci donc de commencer par vous mettre à jour en v5 = en 5.3.73, ce sera l’occasion du (re)passage des patches de la 5.3, et s’ils sont toujours là à l’arrivée il faudra nous fournir l’ensemble des logs de supervision de l’import des fichiers patches pour voir ce qui a pu se passer de travers
Nous venons de passer en 5.3.73. La requête affiche toujours les mêmes résultats de fichiers.
Quels sont les fichiers à fournir et comment le faire?
Est ce qu’il faut aussi passer les patchs manuellement ou est ce que la montée de version est censé le faire tout seul ?
Ce qui m’interesse ce sont ces records de supervision pour voir si certains sont en erreur et analyser les logs. Merci de m’exporter en XML les records correspondant au dernier upgrade.
Avoir ces fichiers Rhino résiduels est inquiétant car ça pourrait indiquer que d’autres patches système n’ont pas été passés…
Pour voir si le pb n’est pas “juste” un pb de RAZ de fichier, pouvez vous essayez de passer manuellement ce patch unitaire sur l’objet métier WebNews:
Ok pouvez vous essayer avec le patch unitaire suivant (avec balise XML autoclosed pour obo_script_id)? Si ça ne supprime toujours pas le script associé à l’objet WebNews c’est qu’il y a une subtilité qu’on investiguera plus avant (merci de nous fournir le health check complet pour qu’on puisse tester dans des conditions les plus proches possibles des votres)
PS: Au pire vous pouvez toujours supprimer manuellement (via le user designer) les scripts résiduels associés aux objets système en question (cf. le path des résultats de le requête) ex:
S’agissant du health check, peut-on avoir uniquement la version de la base (j’imagine que c’est du PostgreSQL) ?
Après test, l’anomalie est visiblement qu’un patch qui vide l’attribut code (Java ou Rhino) d’un objet ne purge pas le document de la table des documents.
Nous allons regarder ça de plus près et vous fournir un mécanisme de purge adapté de la table des documents (car l’action de synchronisation des docs ne semble pas résoudre le problème).
Merci beaucoup pour la réponse, la version c’est postgresql 15.5.
Nous restons en attente.
En prévision du passage de version pensez vous qu’après ce problème il peut y avoir d’autres problématique?
Nous avons corrigé l’anomalie qui laissait des scripts Rhino orphelins dans la table m_document lors du passage des patches, ce sera livré lors des prochaines révisions.
Dans votre cas le “mal est fait” (= suite au passage des patches système, les objets système patchés ne référencent plus les scripts Rhino mais ceux ci sont encore dans la table m_document or c’est au niveau de cette table que que le test pre-upgrade v6 est fait) => il faut donc purger manuellement ces documents orphelins, voici les requêtes SQL à passer:
delete from m_document d
where d.dbd_path like '%.js'
and d.dbd_object_id = (select row_id from m_object where obj_name = 'ObjectInternal')
and d.dbd_field_id = (select row_id from m_field where fld_name = 'obo_script_id')
and d.row_id not in (select obj_script_id from m_object where obj_type = 'O');
delete from m_document d
where d.dbd_path like '%.js'
and d.dbd_object_id = (select row_id from m_object where obj_name = 'ObjectExternal')
and d.dbd_field_id = (select row_id from m_field where fld_name = 'obe_script_id')
and d.row_id not in (select obj_script_id from m_object where obj_type = 'E');
delete from m_document d
where d.dbd_path like '%.js'
and d.dbd_object_id = (select row_id from m_object where obj_name = 'Disposition')
and d.dbd_field_id = (select row_id from m_field where fld_name = 'dis_script_id')
and d.row_id not in (select dis_script_id from m_disposition);
delete from m_document d
where d.dbd_path like '%.js'
and d.dbd_object_id = (select row_id from m_object where obj_name = 'BPMProcess')
and d.dbd_field_id = (select row_id from m_field where fld_name = 'pcs_script_id')
and d.row_id not in (select pcs_script_id from bpm_process);
delete from m_document d
where d.dbd_path like '%.js'
and d.dbd_object_id = (select row_id from m_object where obj_name = 'Script')
and d.dbd_field_id = (select row_id from m_field where fld_name = 'scr_file')
and d.row_id not in (select scr_file from m_script);
delete from m_document d
where d.dbd_path like '%.js'
and d.dbd_object_id = (select row_id from m_object where obj_name = 'Adapter')
and d.dbd_field_id = (select row_id from m_field where fld_name = 'adp_script_id')
and d.row_id not in (select adp_script_id from m_adapter);
PS: nous avons ajouté ces requêtes de “nettoyage” aux patches des prochaines révisions, leur passage manuel c’est uniquement en attendant la release de ces prochaines révisions
Et ensuite je suis passer en version 6 et j’ai toujours le même message d’erreur j’avoue ne pas savoir quoi faire.
FATAL|UPGRADE FAULTZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ
This version 6 does not support Rhino script anymore to implements Hooks.
==> All legacy Rhino scripts have to be refactored to more efficient Java classes.
==> Rhino scripts are only dedicated to expressions, calculated fields and constraints.
ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ
OK, le patch SQL était sans doute trop compliqué dans un contexte de “purge” de fichiers résiduels dans m_document
Je pense donc qu’il suffit de supprimer les records en question via des deletes SQL avec des where ad hoc sur les paths en question et ça devrait résoudre le problème dans votre cas:
delete from m_document where dbd_path like 'Disposition/dis_script_id/0/%/responsive.js';
etc.
David étant en congé, je reprends la suite de votre ticket.
Voici les requêtes bloquantes exactes du passage en 6.0 si vous avez encore des scripts Rhino. Elles n’ont jamais bloqué les migrations une fois purgée :
Il ne faut plus avoir d’usage de scripts ici :
select * from m_script_usage
ni de hook implémenté en Rhino sur Object internal | external | disposition | process | adapter :
select * from m_document d
where d.dbd_name like '%.js'
and d.dbd_path not like 'Object%/ob%_script_id/%/MD%.js'
and d.dbd_field_id in (select f.row_id from m_field f
where f.fld_name in ('obo_script_id','obe_script_id','dis_script_id','pcs_script_id','adp_script_id'))
Vous avez dû en oublier quelque part, ou alors c’est une nouvelle erreur dans vos logs.
