Procédures de mise à jour

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 HR & Payroll ne soit arrêtée.
• L'installation de l'Update 9 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.

Étapes 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.

Les étapes sont les suivantes :

• Vérification 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 en V7 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 28 pour une version 6,
• le patch 4 pour une V7,
• les pré-requis fonctionnels au traitement de migration. Ces pré-requis sont décrits dans la documentation dédiée.
• Les procédures automatisées sont ensuite déclenchées sur le dossier d'origine, par le biais de traitements dont le nom commence par UU, que l'on lance par la fonction Exécution traitement. Ces traitements sont fournis à la demande selon la version comme un patch particulier dédié à la migration. Deux types de procédure sont livrés :
• Des procédures de contrôle des données dans le dossier d'origine (traitements de contrôle dont le nom commence par UUMGCTL). 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.
• Des procédures d'alimentation optionnelles, qui revalident certaines tables en leur ajoutant des champs supplémentaires, puis en les alimentant (traitements de pré-migration dont le nom commence par UUMGPRE). 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. À 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 ou 7, 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.

Revalidation de dossier

La revalidation de dossier va transformer la structure du dictionnaire Sage X3 HR & Payroll, puis des tables de paramétrage, puis des tables de données, de la version antérieure pour l'amener au niveau de l'Update 9, en transférant au passage les données. Pour revalider le dossier, cliquez sur le bouton Validation depuis la gestion de dossiers ou lancez la tâche VALDOS dans la gestion des requêtes. 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 et 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. 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.
• 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##, 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é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 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.

Purge finale des tables de mouvements

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.

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.