Validation de dossier : annexe technique

Introduction

L'opération de validation de dossier est lancée à partir de la gestion de dossier dans le dossier de référence.
Elle peut être lancée en mode batch. Elle a pour objectif d'effectuer les opérations qui rendent le dossier utilisable : il sera possible de se connecter et d'effectuer des opérations normales sur le point d'entrée correspondant.

La validation de dossier est un processus complexe qui gère plusieurs cas :

• la création complète du dossier quand il n'existe pas,
• les changements de structure d'un dossier qui existe déjà, quand :
• le dossier de référence a été mis à niveau,
• la configuration des codes activité a changé,
• de nouvelles langues ont été paramétrées,
• de nouveaux modules sont activés,
• un dossier historisé a été mis à jour, etc.

La création d'un dossier historisé est effectuée à partir de la fonction Création dossier historisé.

La description du traitement s'effectue sur plusieurs étapes, décrites ci-dessous.

Étapes de traitement

1 - Pré-requis pour dossiers historisés

Si un dossier historisé existe sur un dossier donné, sa revalidation s'effectue en deuxième étape, voire plus tard (si par exemple l'environnement où le dossier historisé est installé est autonome). Cependant, un dossier historisé peut uniquement être migré après migration du dossier auquel il est lié.

La revalidation d'un dossier historisé est uniquement disponible pour une migration de version 150, version 6, version 7 ou mise à jour 8 vers la mise à jour 9 (et supérieur). Attention : en fonction de la version, un certain nombre de patchs et maintenances seront requis.

La liste suivante donne les pré-requis :

2 - Contrôles préliminaires

La validation de dossier teste en premier lieu le paramètre de validation en appliquant les actions suivantes :

• Si un dossier historisé est validé, le dossier de référence est activé sur le dossier d'exploitation associé.
• Le dossier de référence est vérifié (il doit être au niveau de la version actuelle).
• Si le dossier existe déjà, il s'agit d'un processus de revalidation ; s'il n'existe pas c'est une validation.
• Les valeurs du code activité sont contrôlées :
  - si un code activité n'est pas actif dans le dossier de référence, il est désactivé,
  - en cas de revalidation, la liste de codes activité modifiés est mise à jour,
  - la liste de code activité législation à jour est gérée séparément (certaines mises à jour de paramétrage sont liées aux législations),
  - les valeurs évaluées de code activité (via des formules de dépendance) sont calculées,
  - les codes activité présents sont identifiés et vérifiés.
• Des contrôles fonctionnels supplémentaires sont effectuées (par exemple, la valeur de certains paramètres).
• Pour la revalidation du dossier historisé, vérifiez certains pré-requis (la visualisation ADOVALHIS doit être présente dans le dossier de référence : c'est le cas si le patch préliminaire adéquat a été installé sur les versions 150, 6, 7 et 8).
• La longueur des tables diverses est vérifiée (type de donnée ADI).
• La version du moteur est vérifiée pour assurer l'exécution de mises à niveau optimisées (plans de migration).

Si certains contrôles préliminaires échouent, le traitement de revalidation s'arrête et le fichier trace affiche les raisons de cet échec.

3 - Étape préliminaire de validation

Si le dossier est revalidé, il doit d'abord être positionné en mode mono-connexion (aucun utilisateur ne peut se connecter au dossier pendant la revalidation). Si un utilisateur est déjà connecté, la revalidation échoue.

Indicateurs définissant si des éléments des dictionnaires doivent être validés. Par défaut, la revalidation est définie à Non, sauf dans le cas d'une création de dossier. Pour les étapes suivantes, l'indicateur peut être positionné sur Oui à partir d'une des procédures de mise à niveau.

4 - Répertoire / Création de base de données

Si le dossier est créé, un ensemble de répertoires sont créés sur le dossier d'application et les scripts de création de l'utilisateur de base de données et les tablespaces correspondants sont également exécutés.

Si le dossier est revalidé, un contrôle est effectué et des répertoires additionnels peuvent être créés (par exemple quand une langue est ajoutée ou si un nouveau répertoire est défini dans le dossier de référence).

Si le dossier validé ou revalidé est un dossier historisé, les éléments de dictionnaire local (désignation table locale) sont créés en fonction des données stockées et les fichiers menu et fichiers texte spécifiques à l'interface utilisateur sont générés.

5 - Transfert de données et épuration

Si les plans de migration ont été activés :

• La liste des tables temporaires est définie :
  - chaque module renvoie la liste des tables à purger,
  - certaines sont temporaires et peuvent être purgées (ALISTER, AWRKLOG, ATMPTRA en superviseur par exemple ou PWRKSTT, PWRKORDERS pour le module achats),
  - d'autres sont purgées, mais reconstruites ensuite. C'est le cas des tables BALANCE, BALANA, GLCONSO pour le module comptable.
• La liste des tables de mouvement est également définie.
• Un point d'entrée permet des développements spécifiques pour ajouter des tables propres à la liste.
• Les tables temporaires sont purgées.
• Les tables de mouvement sont copiées via transfert SQL direct vers les tables de migration dédiées U*.
• Les tables de mouvement sont ensuite purgées.

6 - Migration de table

Les tables sont mises à jour par le traitement AMAJ situé dans les scripts DOSMAJ. Les principes sont les suivants :

• Les indexes et déclencheurs sont supprimés.
• Les colonnes à ajouter sont ajoutées aux tables.
• Les nouvelles tables ajoutées à la nouvelle version sont créées.
• Les scripts de traitement AMAJ dans DOSMAJ* sont exécutés, dans l'ordre adéquat : pour chaque écart de lancement, un DOSMAJ* dédié peut être exécuté. Par exemple, pour passer d'un lancement X1 à Xn, le DOSCMAJ intermédiaire permettant par exemple d'aller de X1 à X2, X2 à X3, soit Xn-1 à Xn sera exécuté consécutivement. Ce traitement permet par exemple d'alimenter une nouvelle colonne (ou table) avec le contenu d'une ancienne colonne (ou table) qui sera supprimée à l'étape suivante.

7 - Mises à jour dictionnaire et changements de structure

Le dictionnaire des tables est désormais mis à jour et la revalidation de l'ensemble des tables modifiées est effectuée. Les colonnes standard qui ne sont plus présentes dans la version ne sont plus utilisées et les tables existantes réindexées.

Cette étape gère également la transformation de tables de mouvement. Cependant, si les plans de migration ont été mis en œuvre, les tables de mouvement seront vides et la mise à jour sera effectuée ultérieurement.

8 - Livrables et gestion des kits

Quand des livrables ou kits sont ajoutés, ils sont copiés depuis le dossier de référence (cette étape n'est pas exécutée sur le dossier historisé).

9 - Mise à jour du dictionnaire

Au cours de la revalidation d'un dossier standard, le contenu du dictionnaire est mis à jour sur tous les éléments. Cela inclut les tables, vues, actions, écrans, objets, fenêtres, types de données, paramètres d'action, fonctions, états, codes activité, paramètres généraux, formules d'épuration, transactions système, consultations, navigations, transactions, codes mémo, prototypes, variables globales, constantes, variables contexte, sous-programmes, contextes d'assistants de formule, URLs, documentations, mots-clés d'aide, points d'entrée, dictionnaires liés aux objets métier.

La mise à jour prend en compte les changements effectués (notamment les nouveaux codes activité et nouvelles législations).

Les tables sont désormais revalidées à partir de la définition du nouveau dictionnaire : les colonnes non utilisées sont supprimées et les indexes recalculés.

10 - Mises à jour paramètres et copie de données

Si un dossier non historisé est mis à jour, selon les changements de paramétrage, certaines données peuvent être copiées à partir du dossier de référence (par exemple, si un code langue a été ajouté, des nouveaux paramétrages sont fournis et copiés). Les opérations appliquées sont les suivantes :

• Les nouveaux paramètres créés au lancement sont copiés et initialisés si nécessaire.
• Les nouvelles tables diverses sont copiées et initialisées.
• Le contenu des nouvelles tables livrées avec copie automatique ou conditionnelle (si la copie est paramétrée) est copié à partir du dossier de référence dans le dossier.
• Les données liées aux kits qui ont été activés sont copiées depuis le dossier de référence.

A cette étape, une procédure de contrôle de lien est exécutée sur toutes les tables, sauf les tables de mouvement si les plans de migration sont utilisés.

11 - Génération de dictionnaire

A cette étape, dans le cas d'un dossier non historisé, les éléments de dictionnaire sont validés :

• Les vues sont générées.
• Les fichiers de menus locaux sont générés.
• Les écrans, objets, fenêtres, consultations sont validés.
• Les éléments de vocabulaire sont validés.

Pour les mises à jour de dossier historisé, seules les tables et vues sont générées et validées (tous les autres éléments de dictionnaire sont hérités du dossier principal).

12 - Mises à jour de données post mise à niveau

En traitement de mise à niveau de dossiers non historisés, les scripts de traitement MAJ dans DOSMAJ* sont exécutés dans l'ordre adéquat : pour chaque écart de lancement, un DOSMAJ* dédié peut être exécuté.
Par exemple, pour passer d'un lancement X1 à Xn, le DOSCMAJ intermédiaire permettant par exemple d'aller de X1 à X2, X2 à X3, soit Xn-1 à Xn sera exécuté consécutivement.
Ce traitement peut, par exemple, effectuer des mises à jour complémentaires. Cette étape s'exécute pour les dossiers historisés et les dossiers standard, mais les scripts exécutés peuvent être différents.

13 - Synchronisation classes et représentation

Quand un dossier non historisé est mis à niveau, les classes et les liens de représentation sont mis à jour et l'indicateur de validation est paramétré pour déclencher la validation ultérieurement.

14 - Opérations finales de dictionnaire

Au cours de la validation d'un dossier non historisé, les opérations suivantes sont effectuées :

• Les transactions sont générées.
• Si un dossier mono-législation est créé, des changements en masse supplémentaires sont appliqués sur certaines données clés liées au multi-législation.
• Si le dossier a été créé via validation, les valeurs paramètre par défaut sont alimentées à partir du dossier de référence ; des périodes par défaut et les valeurs de l'année fiscale sont paramétrées.
• Des fichiers menu sont générés à partir des profils menu.
• Des déclencheurs sont générés sur les tables.
• Les indicateurs de mise à niveau pour les éléments de dictionnaire sont réinitialisés.
• Le paramètre BI et le code génération sont appliqués.
• Les fichiers index de scripts compilés sont regénérés.
• Les indicateurs de statut divers sont mis à jour.
• Le numéro de version actuel est mis à jour.
• Enfin, le dossier est repositionné en mode multi-utilisateur.

15 - Étape supplémentaire de migration avec sélection de plans

Cette étape est pertinente en traitement de mise à niveau quand des plans de migration ont été sélectionnés (sinon, la validation de dossier est terminée).

À cette étape, tous les principaux paramètres et tables de dictionnaire sont à jour, mais toutes les tables de mouvement sont vides et les données correspondantes sont localisées dans les tables U*.

L'exécution des étapes du plan de migration transfère les données par insertion massive dans les dernières tables de mouvement. Cela peut être effectué en plusieurs étapes parallèles et défini dans le paramétrage du plan de migration.

Lorsque cette étape est terminée, le dossier est à nouveau prêt à fonctionner normalement. Les tables U* conservent l'image des données de mouvement avant la migration. Elles peuvent être purgées plus tard (par exemple après une période donnée de fonctionnement normal, pour analyser plus en détail les incohérences de données non détectées).

 Elles doivent être purgées avant le lancement de la mise à niveau suivante. Cette opération s'effectue dans la fonction TRTMIGDEL.

Commentaires complémentaires sur la mise à niveau du dossier historisé

Les limites suivantes s'appliquent à la mise à niveau de table d'application dans les dossiers historisés :

• Seule les tables soumises à une règle d'archivage standard sont migrées.
• Le traitement de post-migration (étape 12 ci-dessus) ne sont pas exécutées sur le dossier historisé, à l'exception de la resynchronisation des balances.

En conséquence, les champs V6 suivants restent vide dans les données archivées :

• FIY et PER dans BUD, GCOMMIT, SINVOICE (Ventes/Crédits), PINVOICE (Achats/Débits) et tables PAYMENTH.
• UOM dans GCOMMIT et tables BUD.

Rappel : les tables de cumul comptable (BALANCE, BALANA, BLACMM, BLAQTY) sont effacées en V6. La procédure de migration resynchronise la table des balances. Pour pouvoir utiliser des données archivées de balance, les tables GACCENTRY* et GCOMMIT* doivent également être archivées.