Procédures de migration

Principales étapes de la migration

Les étapes à suivre, lorsqu'on désire migrer un dossier pour passer d'une version majeure à une autre, sont les suivantes :

• L'installation de la Mise à jour 9 (U9) dans un environnement dédié.
• L'extraction des données à migrer du dossier d'origine, suivie de la réintégration de ces données (l'exploitation doit alors être arrêtée et reprendra lorsque la migration sera terminée). L'extraction des données se fera au format "plat" pour les petits dossiers, et par l'utilisation d'outils d'extraction de base de données dès que la volumétrie est plus conséquente.
• La revalidation du dossier dans l'environnement U9. Cette revalidation peut être segmentée en plusieurs étapes, par le biais du paramétrage de plans de migration. Si le dossier n'est pas très volumineux, la définition de plans de migration n'est pas forcément utile. Elle l'est dès que l'on désire paralléliser les traitements de basculement (pour bénéficier de la puissance d'un serveur multi- processeurs) et contrôler leur enchaînement en ayant des points de reprise.
• Les contrôles post-migration. Il s'agit essentiellement de la vérification et de l'adaptation de paramétrages.

La suite de la documentation décrit l'ensemble des étapes.

Préparation de l'environnement U9

La préparation de cet environnement se fait par l'installation de la solution U9, puis l'intégration de tous les patchs existant dans son dossier X3.
 On ne peut et on ne doit pas installer une solution U9 sur une solution antérieure.

Copie des données et ajustement des paramètres dossier

Cette étape correspond au début du basculement. À ce stade, l'exploitation opérationnelle de la solution doit être arrêtée : elle reprendra lorsque la migration sera terminée.

On peut distinguer quatre phases dans cette étape :

1. Extraction des données du dossier à migrer :

• par extraction des données au format "plat" pour les petits dossiers. Pour cela, on utilisera la fonction d'extraction qui crée les fichiers dans le répertoire SVG par défaut.
• par extraction de base de données dès que la volumétrie est plus conséquente (le format dépendant alors de la base et de l'outil utilisé),

2. Copie des fichiers du dossier à migrer dans la solution U9.

3. Création d'un dossier copie de l'arborescence du dossier dans le nouvel environnement de la version 6, et import des données exportées dans le nouvel environnement.

4. Création de la fiche dossier dans l'environnement U9. Si l'import est fait par la console, la fiche dossier est créée automatiquement, mais si l'import a été fait par des outils de base de données, il faudra créer la fiche dossier manuellement après l'import.

 Vous pouvez regrouper ces étapes en une seule. Utilisez pour celal'assistant d'import distant proposé dans la console de configuration SAFE X3.

Le cas échéant, les valeurs des codes activité doivent être ajustés dans la fiche dossier, par exemple pour mettre en oeuvre de nouvelles fonctionnalités contrôlées par des codes activités nouveaux.La modification de la fiche dossier, ou sa création, se fera en se connectant dans le dossier Superviseur.

Revalidation de dossier

La revalidation de dossier va transformer la structure du dictionnaire Sage X3 People, puis des tables de paramétrage, puis des tables de données, de la version antérieure pour l'amener au niveau de l'U9, en transférant au passage les données. Pour revalider le dossier, cliquez sur le bouton Validation depuis la gestion de dossiers.

La revalidation de dossier réalise la migration superviseur et fonctionnelle du dossier, en comparant le dictionnaire de la nouvelle version et le dictionnaire de la version à migrer.

Grandes étapes de la revalidation

La revalidation de dossier enchaîne les étapes suivantes sur le dossier à migrer :

• Purge de certaines tables temporaires ou de cumul dont la reconstitution sera faite dans des étapes ultérieures. Par exemple, les tables superviseur concernées par cette purge sont les tables suivantes :
      ALSTRD
      ALISTER
      AWRKLOG
      AWRKLOGIND
      AWRKLOGMES
      ATMPTRA
• Migration de l'enveloppe, c'est-à-dire du dictionnaire de données et des tables du superviseur nécessaires au fonctionnement de base (connexion, gestion des utilisateurs, environnement de développement et de paramétrage minimal). À partir du moment où cette migration est faite, une connexion est théoriquement possible, même si les tables contenant les données applicatives de flux sont pour le moment vides.
• Migration fonctionnelle : pour chaque table dont la structure change, la procédure va procéder aux changements nécessaires, le cas échéant en donnant des valeurs par défaut requises, par des procédures enchaînées en étapes et en phases. Ceci est la partie longue de la migration, celle qui dépend du volume de données à migrer.
• Traitement de post-migration. Elles devront avoir été passées pour que la migration soit considérée comme terminée.

Utilisation de plans de migration

Cette migration fonctionnelle peut être très longue lorsque le dossier est très volumineux. En outre, certaines des tables mises à jour sont potentiellement indépendantes, et pourraient donc être migrées en parallèle, tirant ainsi parti des architectures multi-processeurs pour accélérer cette phase.

Pour permettre d'ordonnancer au mieux cette migration, on pourra définir AVANT de lancer la validation de données un plan de migration personnalisé. Ce plan de migration est décrit par la fonction nommée procédure de migration (que l'on appellera depuis le dossier superviseur). Cette fonction permet de définir les étapes, phases et procédures de la migration fonctionnelle et superviseur. Plus précisément, un plan de migration correspond à une définition des paramètres précis de la migration (dossier concerné, nombre de procédures pouvant être parallélisées, politique d'enchaînement des tâches, état d'exécution). Un plan de migration est créé par recopie de l'ensemble des éléments actifs de la procédure de migration. Cet ensemble complet de procédures est fourni en standard, permettant d'enchaîner de façon exhaustive les traitements réalisés par le progiciel standard dans la phase de migration. La description succincte de ces procédures est décrite dans un document dédié.

Il est possible, à ce stade, de définir des procédures spécifiques moyennant l'écriture de traitements complémentaires conformément à la méthodologie définie dans l'annexe suivante. Ces procédures spécifiques seront insérées entre les procédures standard de façon appropriée.

Dès lors qu'un plan de migration a été défini, on peut, depuis ce plan, procéder à son lancement, à son interruption temporaire, à la reprise de son exécution, à la visualisation de son état d'avancement.

Lorsqu'un dossier est un dossier d'une volumétrie raisonnable, dont la migration ne nécessite pas de planification particulière, il est inutile de créer un plan de migration. En effet, en l'absence de plan de migration défini, l'opération de validation du dossier va créer automatiquement un plan de migration. Ce plan de migration aura pour code le code du dossier, sauf si ce code correspond déjà à un plan de migration qui ne soit pas dans le statut En attente. Si cela était le cas, le plan serait créé avec un code prédéfini sous la forme MIGmmddM##, mmet ddétant les numéros du mois et du jour de lancement, ## étant un numéro séquentiel.

Par contre, si on souhaite personnaliser les options d'enchaînement de migration, on pourra créer un plan de migration dont le code correspond obligatoirement au nom du dossier. Cette création sera faite dans le dossier superviseur avant le lancement de la validation de dossier. Dès lors qu'un tel plan de migration existe avec le statut En attente, il sera utilisé pour la migration fonctionnelle du dossier.

 Un plan créé avec un nom différent du nom de dossier à migrer ne sera jamais utilisé par les automatismes de la validation de dossier. Un tel plan est réservé pour un lancement manuel.

Déroulement des opérations dans un plan de migration

Un plan de migration est caractérisé par un code dossier, et les quatre paramètres suivants :

• Un intitulé indicatif.
• Le nombre de procédures susceptibles d'être lancées simultanément. Ce nombre constitue un maximum possible. Seules des procédures parallélisables seront lancées simultanément. Attention, ce nombre est limité par le nombre de tâches batch susceptibles d'être exécutées simultanément (définis dans la fonction de paramétrage du serveur batch), lui-même limité par la licence d'utilisation.
• Un indicateur spécifiant si les procédures doivent être lancées automatiquement en s'enchaînant selon la logique définie par le plan. Si ce n'est pas le cas, l'enchaînement des procédure décrites dans le plan devra être fait manuellement.
• Un indicateur signalant si les procédures post-migration doivent être enchaînées à la migration elle-même. Ces opérations sont caractérisées ci-dessous.

Si le plan de migration est créé par défaut à la revalidation du dossier, il est créé avec les valeurs :

• Nombre de tâches simultanées avec la valeur du paramètre NBRTACSIM ou (s'il n'existe pas) à 2,
• Enchaînement automatique avec la valeur Oui,
• Opérations post-migration avec la valeur Oui.

L'utilisateur peut modifier ces valeurs depuis la fonction de contrôle du plan de migration.

Dans l'écran associé au plan de migration, on retrouve la liste ordonnée des procédures du plan. Des boutons permettent de contrôler globalement l'exécution du plan :

• en lançant son exécution,
• en suspendant le lancement de nouvelles procédures,
• en interrompant toutes les procédures en cours,
• en relançant son exécution.

Chaque ligne du plan matérialise une étape de l'exécution, caractérisée par :

• le code de la procédure, et son intitulé,
• l'étape et la phase dont fait partie la procédure,
• le module fonctionnel auquel est rattachée la procédure,
• le rang d'exécution.

Les étapes de la migration permettent de découper la migration fonctionnelle. Si une procédure liée à une phase donnée n'est pas terminée, les phases suivantes ne peuvent pas être lancées. Les phases sont rattachées aux étapes suivantes :

• L'étape d'initialisation est une étape préliminaire qui s'exécute en tout premier. Elle n'est pas utilisée à ce jour et permet à des procédures spécifiques de s'exécuter avant la migration en elle-même.
• L'étape de tronc commun permet de migrer des données utilisées par les étapes suivantes.
• L'étape module permet de réaliser les migrations liées à chaque module fonctionnel. Une opération de cette étape est associée à un module fonctionnel : cette association est purement documentaire, et ne contraint pas l'exécution. Ainsi, des migrations de données liées à des modules différents peuvent être exécutées en parallèle si elles sont dans la même phase. Leur lancement se fera dans l'ordre des modules, puis des rangs d'exécution.

Dans une étape, on retrouve des procédures unitaires organisées en phases et en rangs.

• Deux procédures définies dans la même phase sont réputées être exécutables simultanément, et doivent donc être indépendantes. L'affectation d'une procédure standard à une phase donnée ne peut pas être changée. Tant que toutes les procédures d'une phase ne sont pas terminées, la phase suivante ne peut pas être lancée.
• L'ordre de rang est simplement un ordre préférentiel de lancement, mais il peut être changé, y compris pour des procédures standard, lors de la définition du plan.

Vérification post-migration

Lorsque la revalidation de dossier est terminée, le dossier est accessible sans restriction pour son utilisation (il peut l'être de façon restreinte si certaines opérations post-migration ont été différées).

Il reste à vérifier et à adapter certains paramétrages fonctionnels. Ceci est décrit dans le document décrivant les post-requis fonctionnels.