Migration d'un dossier

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 :

• Les contrôles pré-migration dans le dossier d'origine. Ces contrôles peuvent être réalisés sans que l'exploitation de Sage X3 ne soit arrêtée.
• L'installation de la mise à jour 9.0.0 dans un environnement dédié, ou la mise à jour d'un environnement existant.
• 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 de la mise à jour 9.0.0. 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-processeur) 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.

Etapes pré-migration

Les étapes de pré-migration sont lancées sur l'environnement de départ, et peuvent être étalées dans le temps, avant la migration à proprement parler. Elles ne nécessitent en effet pas d'arrêt d'exploitation.

Elles sont décomposées comme suit :

• Vérifiez d'abord que le dossier d'origine est au niveau de patch minimum nécessaire pour pouvoir entreprendre une migration. Ce niveau, qui peut être affiché en V6 via le menu ? > A propos ou ou en Version 7 et en Mise à jour 8 via le menu Administration > Informations version (puis cliquez sur un dossier dans le tableau pour accéder au détail), doit être au moins :
• le patch 29 pour une Version 6,
• le patch 9 pour une Version 7,
• le patch 3 pour une Mise à jour 8,
• Vérifiez ensuite les pré-requis fonctionnels au traitement de migration. Ces pré-requis sont décrits dans la documentation dédiée.
• Vous pouvez ensuite déclencher des procédures automatisées sur le dossier d'origine, par le biais de traitements dont le nom commence par UU, que vous lancez par la fonction dédiée. Ces traitements sont fournis à la demande selon la version comme un patch particulier dédié à la migration. Deux types de procédures sont livrées :
• tout d'abord, des procédures de contrôle des données dans le dossier d'origine. Le résultat de ce lancement peut mettre en évidence des erreurs ou incohérences qu'il faut impérativement corriger avant de lancer la migration. Cette phase de contrôle peut être anticipée plusieurs semaines avant la migration, afin de laisser le temps de corriger les données, mais il faudra la relancer pour vérifier que tout est bien correct juste avant le basculement. Ces procédures sont listées dans le document correspondant.
• ensuite, des procédures d'alimentation optionnelles, qui revalident certaines tables en leur ajoutant des champs supplémentaires, puis en les alimentant. Comme ces procédures sont indépendantes, elles peuvent elle aussi être planifiées sur plusieurs semaines avant la migration (l'exploitation peut reprendre dès que l'ajout des champs est fait). L'objectif de ces procédures est d'accélérer de façon notable les étapes de migration à proprement parler. Mais le fait de ne pas les lancer ne compromet pas le fonctionnement des procédures de migration. Ces procédures sont listées dans le document correspondant.

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

Cette étape correspond au début du basculement. A 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 4 phases dans cette étape :

• extraction des données du dossier à migrer :
• par extraction des données au format "plat" pour les petits dossiers. Pour cela, utilisez 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é),
• copie des fichiers du dossier à migrer dans la solution de mise à jour 9.0.0,
• création d'un dossier copie de l'arborescence du dossier dans le nouvel environnement de la version 9.0.0, et import des données exportées dans le nouvel environnement,
• création de la fiche dossier dans l'environnement de mise à jour 9.0.0. 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.

 Si la procédure doit être relancée à partir de l'import des données dans le dossier de migration, vous devez lancer le traitement TRTMIGDEL pour nettoyer les tables stockant l'état de la migration.

Avant la revalidation des dossiers, la valeur des codes activité doit être obligatoirement ajustée dans la fiche dossier. Ceci met ces paramétrages en conformité avec la licence 9.0.0, par exemple pour mettre en oeuvre de nouvelles fonctionnalités contrôlées par de nouveaux codes activités.La modification de la fiche dossier, ou sa création, se fera en se connectant dans le dossier Superviseur.
La revalidation des dossiers ne pourra pas être déclenchée sans cette mise à jour. Un message d'erreur le rappelle dès le lancement de la validation.

Revalidation de dossier

La revalidation de dossier va transformer la structure du dictionnaire X3, puis des tables de paramétrage, puis des tables de données, de la version antérieure pour l'amener au niveau de la mise à jour 9.0.0, en transférant au passage les données. Elle se déclenche par le bouton Validationdepuis la gestion de dossiers.

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

 Si un premier test de migration est fait sur un dossier incluant des développements spécifiques, et si cette migration est susceptible de s’arrêter sur une erreur, le dimensionnement par défaut de la variable globale GTRALIG à 200 (pour des raisons d’optimisation) ne permet pas d’avoir l’intégralité des dernières opérations faites juste avant l’arrêt.
Vous devez, de façon temporaire, modifier la formule de dimension de la variable globale GTRALIG avec la valeur 1. La valeur 200 doit être ressaisie après la migration.
Attention, vous devez vous déconnecter pour vous reconnecter pour que cette valeur soit prise en compte.

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. Les tables superviseur concernées par cette purge sont les tables suivantes :
      ALSTRD
      ALISTER
      AWRKLOG
      AWRKLOGIND
      AWRKLOGMES
      ATMPTRA
  D'autres tables temporaires fonctionnelles sont également purgées (dans le cas d'Sage X3, les tables sont : LABELPRN, PRTSCRWRK, BALANCE, BALANA, GLCONSO, BALCONSO, GAJOUSTA, FUP, FUPTOT, BATCH, TMPEXPENSE).
• 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). A 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 idoines, par des procédures enchaînées en étapes et en phases. C'est là, la partie longue de la migration, celle qui dépend du volume de données à migrer.
• Traitement de post-migration (ce sont essentiellement des resynchronisations de tables de cumuls). Certaines de ces étapes peuvent être différées, et l'exploitation reprendre, au prix d'un fonctionnement dégradé du progiciel dans la phase intermédiaire. Elles devront avoir été passées pour que la migration soit considérée comme terminée.
• Suppression finale des tables temporaires. Cette phase est manuelle, et pourra, pour des raisons de sécurité, être différée tant que l'on ne sera pas absolument sûr que la totalité des données de flux a été correctement migré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, vous pouvez 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 (appelée 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, vous pouvez, 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 vous souhaitez personnaliser les options d'enchaînement de migration, vous pouvez 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 4 paramètres :

• 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édures 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à la valeur du paramètre NBRTACSIM ou (s'il n'existe pas) à 2,
• Enchaînement automatique à Oui,
• Opérations post-migration à Oui.

Vous pouvez modifier ces valeurs depuis la fonction de contrôle du plan de migration.

Dans l'écran associé au plan de migration, vous retrouvez 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,
• l'étape post-migration permet de réaliser des opérations de synchronisation ou des mises à jour secondaires dont l'exécution n'est pas obligatoire pour recommencer à fonctionner en mode au moins dégradé. Elle peut être utilisée par exemple pour différer des migrations de données anciennes. Il faut toutefois noter que, même si elle n'est pas obligatoire pour reprendre l'exploitation, elle devra être réalisée ultérieurement pour que l'état d'un dossier soit considéré comme complètement migré. Ces opérations post-migration sont lancées par défaut dans un plan de migration, mais peuvent être débrayées. Elles sont listées dans un paragraphe dédiéde l'annexe décrivant les procédures de migration.

Dans une étape, vous retrouvez 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.

Purge finale des tables de mouvement

Cette phase est manuelle. Elle est déclenchée par l'exécution du traitement TRTMIGDEL depuis la fonction d'exécution de traitement. Son exécution provoque la suppression de toutes les tables portant le code activité MIG.

Cette phase est irréversible, assurez-vous au préalable que les traitements de migration se sont bien déroulés.

Conserver les tables temporaires dans le dossier n'est pas un obstacle à la reprise normale de l'exploitation, il est donc possible de garder ces tables en ligne pendant quelques semaines d'exploitation. Vous pourrez ainsi, en cas de problème rencontré après la migration, disposer des données d'origine à des fins de comparaison ou d'analyse.

Exemple de séquencement sur la migration des flux

Soient les opérations suivantes :

• dans l'étape initialisation, 7 opérations :
• IN1, IN2 dans la phase 1 (de rangs 3 et 7),
• IN3 et IN4, IN5 et IN6 dans la phase 2 (et de rangs successifs 1 3, 5 9),
• IN7 dans la phase 3,
• dans l'étape tronc commun, 6 opérations :
• TC1, TC2, TC3, toutes les 3 dans la phase 1, avec des rangs 3, 6, 9,
• TC4 dans la phase 2,
• TC5 et TC6 dans la phase 3,
• dans l'étape Module, 5 opérations
• l'étape MO1, dans le module Comptabilité,avec la phase 2 et le rang 1,
• les étapes MO2 et MO3, dans le module Stocks, dans les phases respectives 1 et 2, avec les rangs respectifs 1 et 2,
• les étapes MO4 et MO5, dans le module Ventes, avec les phases respectives 1 et 2, avec des rangs 1,
• les étapes MO6 et MO7, dans le module Achats, avec les phases respectives 1 et 5, avec des rangs 1.

Supposons que le plan de migration soit lancé avec un enchaînement des tâches, et un nombre maximum de 2 procédures tournant simultanément. L'enchaînement peut être le suivant :

• les procédures IN1 et IN2 sont lancées dans cet ordre,
• supposons que la procédure IN2 se termine la première. Tant que la procédure IN1 n'est pas terminée, aucune autre procédure ne sera lancée, car les procédures suivantes sont dans une phase ou une étape de rang supérieur,
• lorsque la procédure IN1 sera finie, les procédures IN3 et IN4 seront lancées dans l'ordre,
• si la procédure IN4 se termine avant la procédure IN3, la procédure IN5 sera lancée. Si elle se termine avant que la procédure IN3 ne soit terminée, la procédure IN6 sera lancée et tournera en même temps que la procédure IN3 continue,
• lorsque les procédures IN3 et IN6 seront terminées toutes les deux (et seulement à ce moment là), l'étape d'initialisation sera terminée,
• les procédures de la première phase de l'étape Tronc commun pourront alors se lancer : tout d'abord les procédures TC1 et TC2, puis TC3, qui se lancera dès qu'une des deux procédures précédentes aura été terminée. On attendra que les trois procédures TC1, TC2, TC3 soient toutes terminées pour lancer TC4, qui tournera seule puisqu'il n'y a pas d'autre procédure dans cette phase. Ensuite, on lancera TC5 et TC6 qui tourneront en parallèle,
• lorsque les procédures TC5 et TC6 seront toutes les deux terminées, on pourra passer aux tâches de l'étape modules,
• on lancera d'abord les procédures MO2, puis MO6 (dans l'ordre, ces procédures tournant en parallèle); puis, dès que l'une des procédures MO2 et MO6 sera terminée,  la procédure MO4, qui est la suivante dans l'ordre phase/module/rang, sera lancée en parallèle avec celles des procédures MO2 et MO6 qui n'est pas terminée,
• on attendra ensuite que toutes les procédures précédentes soient finies, puis on lancera les procédures MO1 et MO3, procédures de la phase 2. Lorsqu'une des deux au moins sera terminée, on lancera MO5. Puis on attendra que toutes la tâches précédentes soient terminées,
• on lancera alors MO7, qui est la seule dans la phase 5.

Vérification post-migration

Dès que 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 les post-requis fonctionnels.