Migration du package

Si vous avez des modifications de code, vous pouvez faire un pull (merge) de votre esup-uportal pour récupérer la 4.3 - vous aurez alors forcément des conflits à résoudre.

Dans la majorité des cas, il sera cependant plus simple de repartir d'une version esup-uportal 4.3 fraiche.

L'implémentation du thème étant complètement refondue (university -> respondr), vous devrez réimplementer complètement vos ajustements graphiques.

Le fichier de configuration principal filters/esup.properties est par contre "très" semblable et vous pouvez le reprendre complètement a priori.

L'intégration du driver correspondant à la base de données choisi (postgresql par exemple) se fait maintenant non plus dans le pom.xml principal mais dans uportal-db/pom.xml.

Migration des données

Le changement de thème en respondr est l'occasion de revoir votre ENT. Comme conseillé sur les documentations Jasig https://wiki.jasig.org/display/UPM41/Database+Changes et https://wiki.jasig.org/display/UPM42/Upgrade+Data+Import il semble préférable de repartir d'une base vierge (initdb).

Suivant l'importance (en quantité) des données (nombre de portlets définis, de groupes ...) il peut être intéressant de récupérer tout de même les anciennes données dans votre nouvel ENT.

Les documentations Jasig (pages données ci-dessus) doivent vous aider à faire cela. Nous allons ici tenter de donner quelques informations également vous facilitant cette tâche.

La démarche est très similaire aux migrations précédentes : export depuis la version précédente pour import dans la nouvelle version - cf la page "Retour expérience - migration ENT UNR RUNN" qui concernait une migration de 3.5 vers 4.0.

Mode opératoire

L'idée est de conserver un ENT dans l'ancienne version - nos tests ont été faits ici avec un esup-uportal en version 4.0  (version uportal-4.0.15-esup-2 dans nos tests).

Depuis cet ancien ENT, on va procéder à des exports de données.

On procédera aux imports sur le nouvel ENT (4.3).

Entre deux, on devra parfois modifier la structure des fichiers pour les passer d'une structure de 4.0 à une structure de 4.3 - on utilisera pour ce faire des commandes bash ou scripts python.

Groupes PAGS

On récupère les groupes PAGS de notre 4.0 en récupérant simplement le fichier uportal-war/src/main/resources/properties/groups/PAGSGroupStoreConfig.xml

Les groupes PAGS sont maintenant stockés en base de données, on peut les importer via une commande ant data-import, mais il faut pour ce faire disposer d'un fichier XML PAGS par groupe.

Cf la doc Jasig derrière le lien suivant https://wiki.jasig.org/pages/viewpage.action?pageId=65274412 , la structure du xml a de plus quelque peu changé, il faut donc retravailler vos blocs xml en plus de les découper.

Si vous avez beaucoup de groupes, il est intéressant de procéder à cette restructuration par scripts - comme ici : 

#!/usr/bin/env python                                                                                                                                                                                                                       
# -*- coding: utf-8 -*-    
                                                                                      
import libxml2, sys

doc = libxml2.parseFile("PAGSGroupStoreConfig.xml")
mapId2Name = {
    'desktop_device_access':'Desktop Device Access',
    'mobile_device_access':'Mobile Device Access',
    'respondr_theme_users':'Respondr Theme Users'
}

for n in doc.xpathEval("//group"):
    mapId2Name[n.xpathEval("group-key")[0].getContent()] = n.xpathEval("group-name")[0].getContent()

for n in doc.xpathEval("//group"):
    n.setName('pags-group')
    n.setProp('script', 'classpath://org/jasig/portal/io/import-pags-group_v4-1.crn')

for n in doc.xpathEval("//member-key"):
    n.setName('member-name')
    n.setContent(mapId2Name[n.getContent()])

for n in doc.xpathEval("//group-name"):
    n.setName('name')

for n in doc.xpathEval("//group-description"):
    n.setName('description')

for n in doc.xpathEval("//group-key"):
    n.unlinkNode()

for group in doc.xpathEval("//pags-group"):
    name = group.xpathEval("name")[0].getContent()
    f = open( name + '.pags-group.xml','w')
    group.saveTo(f)
 

 

Puis on réimporte les groupes PAGS ainsi :

ant data-import -Ddir=/tmp/ent42/pags

 

 

Notez bien que le group-key a disparu, il ne reste plus que le (group) name !

Cela peut avoir une forte incidence sur les configurations (descripteurs xml, configs en BD comme pour CalendarPortlet, ....) des portlets - notamment les configurations dans lesquelles on spécifie des identifiants de groupes : en effet vous ne pouvez plus identifier un groupe par (exemple) pags.member-univ-rouen mais par son nom directement uniquement ("Université de Rouen" par exemple).

Aussi pour esup-filemanager par exemple (c'est valable pour plein d'auters portlets !), dans le fichier drives.xml vous devrez éventuellement changer les identifiants des groupes - exemple :

<property name="group" value="pags.univ-rouen" /> pourra devenir <property name="group" value="Université de Rouen" />

 

 

Groupes locaux

On récupère les groupes locaux depuis la 4.0 via la commande ant data-export -Ddir=/tmp/ent42 -Dtype=group-membership

On peut alors les réimporter directement depuis la 4.3 ant data-import -Ddir=/tmp/ent42/group-membership

Nouveaux groupes dans uPortal4.3

Les opérations de récupération des groupes fonctionnent bien et peuvent être utiles (dans certaines conditions, comme dit ci-dessus) mais elles ont l'inconvénient de ne pas prendre en compte les nouveaux groupes amenés par uPortal 4.3.

Et ces groupes peuvent s'avérer nécessaire pour pouvoir bénéficier pleinement des nouvelles fonctionnalités comme les tenants par exemple.

Ainsi vous devrez (via des export/import depuis l'IHM) redéfinir certains groupes pour mixer vos groupes spécifiques et les groupes issus de 4.3.

Ainsi le groupe "Everyone" contient les groupes "Tenants" et "Tenant Administrators" par exemple qui n'étaient pas présents avant la 4.3.

"PAGS Root" contient quant à lui le groupe "Respondr Theme Users".

Définitions de portlets

On récupère les définitions de portle depuis la 4.0 via la commande ant data-export -Ddir=/tmp/ent42 -Dtype=portlet-definition

On peut alors les réimporter directement depuis la 4.3 ant data-import -Ddir=/tmp/ent42/portlet-definition

Les définitions de portlets peuvent requérir les groupes (et notamment les groupes pags), d'où le fait d'importer les groupes PAGS avant.

Attention également à ce que votre uPortal connaisse bien avant tous les types de portlets que vous cherchez à importer.
La WebProxyPortlet n'est plus connu par défaut en 4.3 (contrairement à la 4.0) - aussi, vous pouvez exporter les "portlet-type" ant data-export -Ddir=/tmp/ent42 -Dtype=portlet-type puis sélectionner les portlet-type voulus (par exemple Web_Proxy_Portlet.portlet-type.xml donc == suppreimer tous les autres fichiers à part celui-ci) pour le réimporter  ant data-import -Ddir=/tmp/ent42/portlet-types
Il nous a fallu également  récupérer le fichier uportal-war/src/main/resources/org/jasig/portal/portlets/webproxy/WebProxyPortlet.cpd.xml depuis une 4.0 pour le copier dans la 4.3

Définition des fragments

Vous pouvez enfin récupérer les fragment-definition en récupérant également avant les user type "lo" (layout owner) - pour ce faire, il faudra faire un export des user ant data-export -Ddir=/tmp/ent42 -Dtype=user puis n'importer que les layout owner (en -lo si vous avez nommé logiquement ces utilisateurs particuliers).

ant data-export -Ddir=/tmp/ent42 -Dtype=fragment-definition puis import comme précédemment.


Si après cela vous avez une erreur du type : 

Could not fetch object for cache entry with key "UserViewKey [ownerId=member-univ-rouen-lo, locale=fr_FR]".

Erreur du même type que pour la migration de données 3.5->4.0. Même symptôme, même "remède" ... : 

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);

 

Ensuite, et en cas d'erreur du type

No INIT_STRUCT_ID in UP_USER_LAYOUT for USER_ID: 14 and LAYOUT_ID: 1

Il faudra alors ajuster de la sorte :

update up_user set user_dflt_usr_id=10 where user_dflt_usr_id=14;

où 10 est le user_id de l'utilisateur ayant pour user_name "defaultTemplateUser"

 

fragment-layout

Vous pouvez enfin récupérer vos fragment-layout de la même manière par ce système d'import/export : 

ant data-export -Ddir=/tmp/ent42 -Dtype=fragment-layout depuis vortre esup-uportal 4.0 donc toujours

ant data-export -Ddir=/tmp/ent42/fragment-layout depuis votre esup-uportal 4.3

Comme pour la migration 3.5 vers 4.0, nous avons dû supprimer dans les (fragment-)layout des références à DLMStaticMissingChannel qui n'existe pourtant plus depuis la 4.0 normalement ...

sed -i 's/.*fname="DLMStaticMissingChannel.*//' fragment-layout/* layout/*

 

 

 

layout

Restent enfin éventuellement les layout de l'ensemble de vos utilisateurs à migrer.

Suivant le nombre de vos utilisateurs, cela peut être un peu long, l'export comme l'import. 

C'est aussi là que vous pouvez avoir beaucoup de "ratés" dans l'export comme dans l'import - notamment si vous n'avez pas réussi à migrer correctement l'ensemble de vos portlets par exemple.

De plus avant d'exporter/importer les layout, il vous faut exporter/importer les user.

Ne pas faire cette migration des layout est donc (évidemment) plus simple et permet dans le même temps de faire une grosse purge de votre base de données. 

L'inconvénient et que l'utilisateur perd ses personnalisations onglets/portlets et ses préférences de portlet (qui peuvent parfois être conséquentes).