migration

Le cycle de vie d'un modèle induit trés fréquemment des modifications de la structure du modèle. Comment rendre compatibles les contenus existants avec changements?

Le modélisateur a la possibilité de définir des sripts de migration dans le wspDef, déclanchant une mise à jour des contenus si nécessaire coté utilisateur.

Avant de faire celà, il est vivement recommandé d'avoir mis en place une politique de versionning de son modèle strict et en accord avec la politique générale de versionning de SCENARI versionning.

Propriétés des migrations :

• Elles sont cumulatives. Soit un modèle dans sa version 1.0.3, et des migrations paramétrées suivantes :
  • mig1 : passe de la version 1.0.1 à 1.0.2
  • mig2 : passe de la version 1.0.2 à 1.0.3

Les ateliers de version 1.0.0 ou 1.0.1 seront soumis aux migrations mig1 et mig2; Les ateliers de version 1.0.2 ne seront soumis qu'à la migrations mig2. Il est donc nécessaire de laisser déclarée la totalité des migrations, pour permettre à tout utilisateur disposant d'une version trés ancienne du modèle de pouvoir bénéficier des migrations.

• Elles sont non réversibles. L'utilisateur n'a pas la possibilité de revenir en arrière. Il est donc indispensable d'apporter la plus grande vigilance à l'écriture de ces sripts.
• Les migrations sont pilotées par un fichier [ant] : build.xml. Celà permet de déclancher une multitude de traitements :
  • execution d'XSL;
  • renommage de fichiers;
  • ...
• Elles ne sont pas appliquées dans SCENARItest; Il est donc nécessaire de créer un wspPack (via le .wspExport) et de l'installer dans SCENARIchain pour la tester.

Procédure :

• Paramétrer l'élément "sm:update" dans le wspDef comme suit :

• sm:update pointe vers un .doss qui contient au minimum un fichier build.xml (); ce fichier est à écrire.
• Tester votre migration dans SCENARIchain.