Cette page présente un retour d'expérience en cours sur la plateforme ENT UNR RUNN qui devrait migrer de Esup 3.2 à Esup 4 cet été.
Cela correspond donc à notre procédure de migration en cours de mise au point.
Pour infos, l'ENT UNR RUNN utilise une base de données Postgresql 8.4.
Export
Version Esup 3.2.5 -> rel-3-2-patches
La tâche ANT crn-export sur Esup/uPortal 3.2 fonctionne chez nous correctement via différentes mises à jour : il nous a fallu notamment prendre en compte le patch suivant :https://github.com/Jasig/uPortal/commit/584a71aa4b4cc1c056177db502ec05ee6cb8ed9f
-> il me parait recommandé si possible de mettre à jour son portail par rapport à la branche rel-3-2-patches :https://github.com/Jasig/uPortal/tree/rel-3-2-patches
Le ant crn-export est censé ensuite fonctionner.
Cependant, il est préférable si possible d'apporter directement dans la base de données du socle Esup / uPortal 3.2 quelques modifications.
Modifications BD
Supprimer les espaces dans les ss_name des up_ss_theme et up_ss_struct :
update up_ss_theme set ss_name='DLMXHTML' where ss_name='DLM XHTML'; update up_ss_theme set ss_name='UniversalityMobile' where ss_name='Universality Mobile'; update up_ss_theme set ss_name='UniversalityAndroid' where ss_name='Universality Android'; update up_ss_struct set ss_name='DLMTabsColumns' where ss_name='DLM Tabs and columns'; update up_ss_struct set ss_name='DLMMobileColumns' where ss_name='DLM Mobile columns';
De même pour vos thèmes spécifiques, par exemple :
update up_ss_theme set ss_name='UROUENDLMXHTML' where ss_name='UROUEN DLM XHTML';
A VALIDER : Tenter d'éviter les erreurs type "No INIT_STRUCT_ID in UP_USER_LAYOUT for USER_ID: 13820 and LAYOUT_ID: 1"
select count(*) from up_user where user_id not in (select user_id from up_user_layout); insert into "up_user_layout" select '1', user_id, 'default layout', '1' from up_user where user_id not in (select user_id from up_user_layout);
Vérifier et nettoyer les identifiants/noms des groupes et canaux
Il est important qu'aucun groupe (de canaux ou de personnes) n'aie le même identifiant. Cela comprend aussi les groupes PAGS !
Par exemple, si vous avec un groupe de canaux qui s'appelle "Personnel" et un groupe PAGS qui s'appelle également "Personnel" cela posera problème lors de l'import dans uPortal4.
Il fait donc renommer les groupes si besoin, on peut aussi en profiter pour supprimer/nettoyer les groupes qui ne servent pas.
On peut faire cela via l'IHM simplement (sauf pour les groupes PAGS bien sûr).
De même pour les canaux, l'import dans uPortal4 requiert qu'aucun canal n'ait le même nom ...
ant crn-export
ant crn-export -Ddir=/tmp/export_ent_esup_uportal_325 -Dtype=all > /tmp/crn-export.log
L'export de certains éléments peut échouer sans pour autant stopper l'ensemble de la procédure d'export qui se termine donc malgré tout par le message BUILD SUCCESSFUL. En V3, contrairement à la V4, les tâches d'import/export ne gardent pas des logs détaillés dans des fichiers de logs spécifiques -> on redirige donc la sortie de cette commande dans le fichier /tmp/crn-export.log afin de pouvoir le consulter et vérifier que tout s'est bien passé.
On a pus constater que des layout pouvaient ne pas passer, notamment certains layout peuvent être corrompus :
1019775- [java] WARN Corrupt layout detected: one <channel> element inside another 1019776: [java] WARN Layout for user: toto@unicaen.fr is corrupt; layout structures will not be exported
Dans ces cas là, le layout de l'utilisateur toto@unicaen.fr n'est donc pas exporté. Cet utilisateur perdra la personnalisatino de son portail lors de la migration.
Le plus embêtant ici est que le layout d'un utilisateur "owner" (porteur de la définition d'un fragment-layout) ne passe pas :
1019775- [java] WARN Corrupt layout detected: one <channel> element inside another 1019776: [java] WARN Layout for user: affiliate-univ-rouen-lo is corrupt; layout structures will not be exported
A l'import celà posera alors forcément problème à l'import de l'ensemble des layout/utilisateurs qui dépendent du fragment-layout lié à affiliate-univ-rouen-lo
-> il faut dans ces cas-là débuguer (reprendre) le fragment-layout au niveau de votre portail V3 pour le corriger [...], puis refaire l'export ...
Import
Importation "de base" du portail 4
On importe les éléments requis et donnés par défaut d'Esup:uPortal :
ant initdb (voire ant initportal si on veut tout construire au passage)
Modifications de l'export issu du portail 3.2.5
channel-type entity-type
Certains éléments exportés sur la 3.2.5 ne sont plus à importer car dépréciés, et leurs "remplaçants" ont été importés via le initdb.
rm -rf channel-type entity-type
Il faut également supprimer l'usage des vieux channel-type dans les exports des layout :
sed -i 's/.*fname="header.*//' fragment-layout/* layout/* sed -i 's/.*fname="portal_login_general.*//' fragment-layout/* layout/* sed -i 's/.*fname="footer.*//' fragment-layout/* layout/* sed -i 's/.*fname="DLMStaticMissingChannel.*//' fragment-layout/* layout/* sed -i 's/.*fname="person-attributes.*//' fragment-layout/* layout/*
Si on utilisait des types maintenant dépréciés et qu'on ne souhaite (ou peut) pas remplacer, on peut supprimer leur utilisation, exemple :
rm channel/rss-reader.channel sed -i 's/.*fname="rss-reader.*//' fragment-layout/* layout/*
Au lieu de modifier ainsi les layout, on peut également simplement configurer le userLayoutStore pour que la tentative d'importation de portlet non existante ne soit pas considérée comme une erreur (mais un simple warning) :
modification de uportal-war/src/main/resources/properties/contexts/layoutContext.xml
<bean id="userLayoutStore"> + <property name="errorOnMissingPortlet" value="false"/> </bean>
Bug migration uPortal channels
Bugs lors de la migration de l'export xml des channels en portlets (3.2 vers 4) des paramètres
hashelp (devenu hasHelp), hasabout (devenu hasAbout) et hasedit (devenu editable) -> modif de uportal-war/src/main/resources/org/jasig/portal/io/xml/portlet/upgradeChannel_32.xsl nécessaire.
Cf https://github.com/EsupPortail/esup-uportal/pull/10
theme -> stylesheet-descriptor
Le répertoire theme exporté ne sera pas importé car déprécié.
En lieu et place de chaque theme, il vous faut un stylesheet-descriptor.
Voyez notamment le fichier uportal-war/src/main/data/required_entities/stylesheet-descriptor/DLMXHTML.stylesheet-descriptor.xml qui présente le stylesheet-descriptor DLMXHTML.
Cet identifiant DLMXHTML est à mettre en relation directe avec la commande "update up_ss_theme set ss_name='DLMXHTML' where ss_name='DLM XHTML';" donnée ci-dessus.
Pour exporter un thème en stylesheet-descriptor on peut simplement partir d'une copie de DLMXHTML.stylesheet-descriptor.xml et y modifier le tag name en UROUENDLMXHTML par exemple et le default-value du skin (correspond à un identififant de skin).
On ajoutera ces fichiers dans un nouveau répertoire stylesheet-descriptor du répertoire précédemment exporté ( /tmp/export_ent_esup_uportal_325 ).
On peut y supprimer dans celui-ci au passage le répertoire theme ainsi que structure dont le pendant se retrouve aussi dans uportal-war/src/main/data/required_entities/stylesheet-descriptor/ :
DLMTabsColumns.structure -> uportal-war/src/main/data/required_entities/stylesheet-descriptor/DLMTabsColumns.stylesheet-descriptor.xml
DLMMobileColumns.structure -> uportal-war/src/main/data/default_entities/stylesheet-descriptor/DLMMobileColumns.stylesheet-descriptor.xml
Profiles android
Les profiles spécifiques android n'existent plus : un seul profile mobile est maintenant utilisé dans uPortal4.
-> on supprime les profiles android :
find profile -name "*android.profile" -delete
Migration de dlm.xml
La déclaration des "fragments de groupes" donnée dans le fichier dlm.xml est maintenant maintenu en base de données pour uPortal4.
L'export de votre la de données uPortal3.2 contient la définition de ces fragments de groupes, pour que ceux-ci soient bien importés il faut que uPortal4 aient connaissance de leur existence (définition).
On migre donc le dlm.xml avant toute import pour pour voir l'ajouter à l'export.
La migration est assez simple puisqu'elle consiste à éclater le dlm.xml en autant de fichiers qu'il y a de définition de fragments. Si le nombre de fragments est assez faible, le faire à la main est tout à fait possible. Exemple d'un fichier member-univ-rouen-lo.fragment-definition.xml issu du dlm.xml :
<fragment-definition xmlns:dlm="http://org.jasig.portal.layout.dlm.config" script="classpath://org/jasig/portal/io/import-fragment-definition_v3-1.crn"> <dlm:fragment name='Pers UnivRouen' ownerID='member-univ-rouen-lo' precedence='50'> <dlm:audience evaluatorFactory='org.jasig.portal.layout.dlm.providers.GroupMembershipEvaluatorFactory'> <attribute mode='deepMemberOf' name='Personnels - Université de Rouen'/> </dlm:audience> </dlm:fragment> </fragment-definition>
On place l'ensemble de ces fichiers dans un répertoire fragment-definition dans le répertoire correspondant à l'export de la base 3.2 ( /tmp/export_ent_esup_uportal_325 )
ant data-import
ant data-import -Ddir=/tmp/export_ent_esup_uportal_325
A Valider : Debug de la base de données
Après importation, puis démarrage du portail, on obtient la "fameuse" erreur "No INIT_STRUCT_ID in UP_USER_LAYOUT" dans les logs uPortal, le portail étant bugué (écran d'exception uPortal4).
Pour y remédier, on lance :
insert into "up_user_layout" select '1', user_id, 'default layout', '1' from up_user where user_id not in (select user_id from up_user_layout);
-> à débugguer, regarder si une issue est donnée autour de cela dans le JIRA uPortal ...
Problèmes
Voici les problèmes que nous avons pu constater et qui restent à résoudre.
Import layouts :
Sur 9928 layouts d'utilisateurs, 825 ne passent pas à l'importation ; ils perdraient donc leur personnalisation du layout ~ structure de l'ENT.
- Pour 758 d'entre eux, la cause serait (à nouveau) un pb de "No INIT_STRUCT_ID in UP_USER_LAYOUT"
- Pour les autres, a priori ils font références à des channels non importées simplement : uportal-data-dictionary, portal_userpreferences_dlm -> à supprimer dans leur layout ou à rajouter
Préférences portlets personnalisées
Certaines préférences de portlets des utilisateurs ne sont malheureusement pas importées : présence de WARN de ce type :
WARN Unable to resolve pathref 'bonamvin@univ-rouen.fr:/layout/folder/folder[6]/folder[2]/channel' for layoutOwner 'bonamvin@univ-rouen.fr'