Procédures de migration

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, 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é)
• copie des fichiers du dossier à migrer dans la solution V6,
• 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,
• création de la fiche dossier dans l'environnement V6. 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.

 Il est maintenant possible de regrouper ces étapes en une seule. Il faut pour cela utiliser l'assistant d'import distant proposé dans la console de configuration SAFE X3.

Si on utilise la fonction d'import console, le procédure est la suivante:

• lancer la console,
• se placer sur la solution Sage X3 V6 souhaitée et afficher l'écrans "Dossiers",
• cliquer sur le bouton "Import" (dans la tool-bar de l'écran), une fenêtre apparaît,
• choisir le nom du dossier à importer, le répertoire contenant les données à importer (SVG si ce répertoire a été utilisé pour réaliser l'extraction), renseigner les autres champs,
• lancer l'import par le bouton OK.

Le cas échéant, on ajustera ensuite les valeurs des code activité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" (X3 dans le cas de Sage ERP X3).

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 140 ou 5 pour l'amener au niveau de la V6, en transférant au passage les données. Elle se déclenche par l'appui du bouton Validation depuis 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.

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 de Sage ERP 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, 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##, mm et 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.

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

Il sera toujours loisible à l'utilisateur de 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 vont permettre 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. Tant qu'au moins 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 quand même ê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, 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.

Purge finale des tables de mouvement

Cette phase est manuelle. Elle sera 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.

Comme cette phase est irréversible, il importe de s'être bien assuré au préalable que les traitements de migration se sont bien déroulés.

Dans la mesure où le fait de garder les tables temporaires dans le dossier ne constitue en rien un obstacle à la reprise normale de l'exploitation (ceci suppose bien entendu de disposer de suffisamment d'espace disque), il est tout à fait loisible de garder ces tables en ligne pendant quelques semaines d'exploitation. On pourra ainsi, , en cas de problème rencontré quelques semaines 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 à présent 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 pourrait alors ê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 lors que la revalidation de dossier s'est bien 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 à alors à vérifier et à adapter certains paramétrages fonctionnels. Ceci est décrit dans le document décrivant les post-requis fonctionnels.