Validation de dossier en mise à jour

Introduction

La validation de dossiers est un processus complexe, qui permet, à partir d'une fiche dossier, de créer un dossier (aussi bien les fichiers physiques contenant les données, que la structure logique de la base, que les paramètres qui s'y trouvent), à partir d'un dossier existant pour la structure et d'un dossier éventuellement différent pour les paramètres.

Mais le processus de validation est encore plus complexe dans le cas de la revalidation d'un dossier existant. En effet, ce processus permet de garantir une mise en conformité d'un dossier par rapport à un autre (en particulier du point de vue du changement de version, de la mise à jour du dictionnaire avec le transfert d'éventuels développements spécifiques).

Il est utile de détailler techniquement le processus complet suivi par cette revalidation de dossier, et en particulier de bien distinguer les éléments éventuellement transférés du dossier modèle (le dossier superviseur , ou un dossier de développement) vers le dossier à revalider. C'est ce que cette documentation décrit.

Distinction entre les architectures à 2 et à 3 niveaux

Il est important de noter d'abord que l'on peut être dans une architecture à deux niveaux (ie. une architecture où le dossier en cours de revalidation a pour dossier de référence le dossier superviseur), ou dans une architecture à trois niveaux (dans ce cas, le dossier de référence, qui n'est pas le dossier superviseur, en dépend lui-même directement).

Les différentes architectures possibles sont décrites par le schéma ci-dessous :

Lorsqu'on veut créer un dossier totalement standard, il suffit de créer ce dossier à partir du dossier superviseur, en copiant éventuellement des données à partir d'un dossier de copie se trouvant au même dossier que le dossier superviseur. Il s'agit du Dossier d'exploitation standard défini dans le schéma ci-dessus.

Lorsqu'on veut utiliser des spécifiques, deux approches sont possibles :

 soit on utilise une architecture à 2 niveaux. Dans ce cas, on installera un dossier de développement spécifique et de test, et on recopiera les spécifiques par copie ou patch. Cela n'interdit pas de réaliser à la fois des spécifiques et d'installer des verticaux, la distinction pouvant être réalisée par des normes de nommage à définir par l'intégrateur (par exemple, X pour les verticaux, Y pour les spécifiques). Compte tenu de la lourdeur de mise en oeuvre de la solution à 3 niveaux décrite ci-dessous, cette implémentation est recommandée dans la plupart des cas.

 soit on désire avoir une approche verticale dans laquelle on autorise des spécifiques faits par le client. Il peut alors être intéressant de séparer les couches de développement en se créant un Dossier de développement vertical qui peut aussi servir de dossier de test. Ce dossier contient à la fois des développements verticaux, des paramètres dédiées et des données de test. Il peut être installé sur une machine dédiée, et va être copié à un moment donné sur le serveur d'exploitation, mais à un niveau intermédiaire : le dossier d'exploitation sera à un niveau inférieur et héritera de ce Dossier de référence vertical. Des transferts ultérieurs (lorsque le dossier de développement vertical évolue) sont possibles soit par copie (si les serveurs sont en ligne), soit par patch.

Mais attention, dans cette architecture à 3 niveaux, la copie sera délicate (il faudra copier les éléments du dictionnaire dans les deux dossiers, et les traitements et états uniquement dans le dossier de référence), et le patch devra être installé dans les deux dossiers. En cas d'installation d'une nouvelle version, il faudra revalider successivement le dossier de référence, puis le dossier d'exploitation.

Tout ceci rend donc cette architecture beaucoup plus lourde, alors qu'une distinction entre les verticaux, les spécifiques réalisés par un intégrateur, et les spécifiques réalisés par un client peut être induite par des règles de nommage différentes.

Il reste que si cette architecture est choisie, on placera les verticaux dans le dossier de référence, les spécifiques faits par le client lui-même dans le dossier d'exploitation, et les spécifiques faits par l'intégrateur dans l'un des deux dossiers (dans le dossier de référence si ces spécifiques sont communs à plusieurs dossiers d'exploitation). Dans ce dernier cas, il est tout de même prudent de prévoir au 3ème niveau un dossier de test (non représenté ici) à côté du dossier d'exploitation.

Quelle que soit l'architecture retenue, le processus de revalidation réalise donc, entre autres tâches, une remise à jour des dictionnaires (tables, écrans, fenêtres…) afin de reporter les modifications (de version, liés à des spécifiques, à des patches) du dossier de référence. Cette mise à jour n'est pas une copie des structures, car elle fait intervenir les codes activité. En effet :

 tout élément non porteur d'un code activité est reporté du dossier de référence vers le dossier en cours de validation.

 tout élément porteur d'un code activité standard (ie. dont le code ne commence pas par X, Y ou Z) est mis à jour en fonction de la valeur associée au code activité (actif, inactif, ou une dimension) dans les paramètres du dossier en cours de validation. Ainsi, on peut activer, désactiver, ou dimensionner les éléments du dictionnaire qui le portent.

 la mise à jour des éléments porteurs d'un code activité spécifique (ie. dont le code commence par X, Y ou Z) est faite de la même façon dans une architecture à deux niveaux. Par contre, dans une architecture à 3 niveaux, deux cas se présentent : soit l'élément en cours de mise à jour est présent dans le dossier de référence, mais pas dans le dossier en cours de validation. Dans ce cas, il y a copie de cet élément si le code activité est actif dans les paramètres du dossier. Si l'élément en cours de validation est présent dans le dossier de référence et dans le dossier en cours de validation, alors il y a mise en conformité de cet élément si le code activité est défini, dans les paramètres du dossier, avec le flag Vertical égal à Oui. Si ce n'est pas le cas, il n'y a pas de remise à jour. Ceci revient à dire que l'on reporte un vertical dans tous les cas d'un dossier de développement vers le dossier final, alors qu'un spécifique n'est reporté dans le dossier final que s'il n'y existe pas déjà. Outre des règles de nommage éventuel, un vertical est donc identifié au niveau de son code activité, et se copie quoi qu'il arrive au niveau le plus bas de la hiérarchie des dossiers.

Les différentes phases du processus de revalidation

Il est à noter que les phases de revalidation ne sont pas très différentes des phases de validation d'un dossier non créé. La plupart des différences viennent de la création physique des contenants de la base, et également des conditions d'initialisation (essentiellement grâce aux paramètres de copie).

Le processus détaillé de la revalidation est donc le suivant.

1) Mise à jour avant modification structure

Si la validation du dossier est faite alors que le dossier à mettre à jour est dans une version antérieure à la version du dossier de référence, cette phase va appeler des traitements normalisés de mise à jour qui doivent être appliqués (s'ils existent) avant que la structure des données n'ait été mise à jour. Lorsqu'on passe d'une version à une version qui n'est pas immédiatement consécutive, les traitements de mise à jour sont exécutés successivement.

2) Création des répertoires

On crée  ici les répertoires qui n'existeraient pas dans la hiérarchie du dossier (par exemple, ceux dépendant de la langue si une nouvelle langue est utilisée dans le dossier).

3) Mise à jour des tables du dictionnaire

Les tables du dictionnaire (ie. celles dont le type est Dictionnaire X3) sont revalidées si leur structure a changé.

4) Copie des textes

On recopie ici la totalité des textes se trouvant dans la table ATEXTE (textes du dictionnaire), du dossier de référence vers le dossier en cours de revalidation. Le processus précis est le suivant :

• on recopie d'abord les textes standard (dont le numéro est inférieur à 100.000). Tous les textes standards existant dans le dossier en cours de revalidation, mais non présents dans le dossier de référence, sont épurés.
• si on est dans une architecture à 3 niveaux, et que l'on revalide le dossier de niveau 3 à partir d'un dossier de référence (qui n'est donc pas le dossier superviseur) au niveau 2, on commence par synchroniser les textes spécifiques (dont le numéro est supérieur à  100.000) en créant dans le dossier de référence les textes du dossier en cours de revalidation qui n'y existeraient pas. Ainsi, dans ce cas, on arrive à une situation où les textes spécifiques sont identiques dans le dossier de référence et dans le dossier en cours de revalidation.
• on recopie ensuite les textes spécifiques du dossier de référence (s'il en existe) dans le dossier en cours de validation.

Il est à noter que cette copie se fait pour toutes les langues standards gérées dans le dossier en cours de validation (et aussi pour la langue d'installation du progiciel, même si cette langue n'est pas gérée dans le dossier en cours de revalidation). Sur les langues spécifiques, aucun traitement de copie n'est fait.

Cette phase de copie des textes (y compris spécifiques) signifie qu'en fin de copie, on aura concordance absolue entre les numéros de textes du dossier de référence et du dossier revalidé, sauf pour les textes qui n'existeraient pas dans le dossier de référence.

Il est à noter que la phase de synchronisation, dans une architecture à 3 niveaux, n'était pas assurée automatiquement en version 130. Les conséquences n'étaient pas neutres pour la gestion des textes spécifiques. Elles étaient les suivantes :

• les textes spécifiques qui se trouvaient dans le dossier de référence étaient recopiés dans le dossier à valider.
• en conséquence, s'il existait des textes spécifiques différents dans les deux dossiers (ie. si on avait réalisé des développements spécifiques à la fois dans le dossier de référence et dans le dossier en cours de validation), il y avait un remplacement de certains textes du dossier revalidé par ceux du dossier de référence, avec perte des textes.
• pour pallier ce problème, un utilitaire de re-synchronisation des textes avait été fourni.

5) Copie des menus locaux et des messages

On recopie ici les menus locaux et les messages du dossier de référence vers le dossier d'exploitation, sauf dans les cas suivants :

• si le menu local existe déjà dans le dossier en cours de validation et est modifiable par l'utilisateur (on considère alors que l'utilisateur peut l'avoir modifié).
• si le chapitre de message est compris entre 160 et 164 (ce sont des chapitres réservés aux spécifiques réalisés au plus bas niveau)
• si le chapitre de message est compris entre 165 et 169 et que le dossier de référence est le dossier superviseur (dans le cas contraire, ils sont copiés : ce sont les chapitres réservés aux spécifiques « verticaux » qui sont transférés vers le 3ème niveau dans le cas d'une architecture à 3 niveaux).
• si le chapitre est protégé par un code activité spécifique.

Cette copie se fait pour toutes les langues standards gérées dans le dossier en cours de validation (et aussi pour la langue d'installation du progiciel, même si cette langue n'est pas gérée dans le dossier en cours de revalidation). Sur les langues spécifiques, aucun traitement de copie n'est fait.

Dans cette phase, le dictionnaire des menus locaux est également mis à jour en suivant les mêmes règles.

6) Mise à jour du dictionnaire des tables

Cette mise à jour va se faire sur toutes les tables de la base sauf celles du dictionnaire. Le principe en est une comparaison du dictionnaire de toutes ces tables, entre le dossier de référence et le dossier en cours de validation :

• si la table existe dans le dossier de référence, mais pas dans le dossier en cours de validation, elle est créée.
• si la table existe dans le dossier en cours de validation, n'est pas protégée par un code activité, mais n'existe plus dans le dossier de référence, elle est supprimée du dictionnaire (la table elle-même ne sera pas supprimée de la base, pour des raisons de sécurité).
• si la table existe dans le dossier de référence et dans le dossier en cours de validation, mais qu'elle est spécifique (ie. marquée avec un code activité supérieur ou égal à X), elle n'est pas mise à jour, sauf dans le cas des spécifiques verticaux transférés sur une architecture à 3 niveaux.
• si la table existe dans les deux dossiers sans qu'elle soit marquée comme spécifique, on va reconduire la même logique de mise à jour : les zones et index inexistants dans la table du dossier en cours de revalidation vont être créées, les zones et index modifiés et non protégés par un code activité spécifique vont être modifiés, les zones et index protégés par un code activité spécifique ne sont pas touchés sauf dans le cas du vertical, et les zones et index standard n'existant plus dans le dossier de référence vont être supprimés.

Attention, dans cette phase, seul le dictionnaire est remis à jour (les tables de la base seront revalidées dans une phase ultérieure).

Par ailleurs, il est à noter que le nombre de fiches, qui peut avoir été saisi dans l'en-tête de chaque table du dossier en cours de validation, n'est pas remis à jour s'il est plus grand que le résultat du calcul de dimensionnement ou que la valeur définie dans le dossier de référence.

7) Copie des autres éléments du dictionnaire

Les autres éléments du dictionnaire sont mis à jour, dans l'ordre suivant :

ORDRE	ELEMENT DU DICTIONNAIRE
1	Actions
2	Ecrans
3	Objets
4	Fenêtres
5	Types de données
6	Paramètres
7	Fonctions
8	Etats

La règle reste la même : tout élément inexistant dans le dossier en cours de validation est créé, tout élément standard qui n'existe plus dans le dossier de référence est supprimé, tout élément spécifique est respecté, sauf dans le cas de l'architecture à 3 niveaux avec des codes activités verticaux. Cette logique s'étend, de la même façon, aux sous-éléments (ie. une zone d'un écran standard protégée par un code activité spécifique est créée si elle n'existe pas dans le dossier en cours de validation ; si elle existait déjà, aucune mise à jour n'est faite).

Il existe par ailleurs un certain nombre d'informations qui ne sont jamais remises à jour par transfert depuis le dossier de référence (sauf bien sûr si l'élément du dictionnaire n'existait pas avant la validation dans le dossier à valider). Ces informations sont les suivantes :

• le nom des traitements spécifiques et verticaux référencés dans les écrans, les consultations, et dans les actions.
• les codes d'accès et les tables de contrôle associés aux zones des écrans. Ces éléments sont en effet considérés comme du paramétrage susceptibles d'être modifiés par un utilisateur en exploitation, à l'aide des fonctions d'affectation de code accès et d'affectation de tables de contrôle.
• les mots-clés d'aide commençant par X, Y ou Z dans les écrans.
• les actions SPE, SPV et de code supérieur ou égal à X (et leurs paramètres) dans les écrans et les fenêtres.
• les paramètres de la liste gauche des objets (clé, ordre, options standards, clés et expressions de la sélection, nombre de caractères pour la recherche, présence ou absence de l'explorateur de liaisons), ainsi que les états associés, et la case à cocher d'accès aux statistiques. Ces éléments sont considérés comme du paramétrage susceptible d'être mis à jour par la fonction de personnalisation des objets.
• les options des objets commençant par X, Y ou Z.
• pour les états, les zones groupe, code d'accès, les caractéristiques de l'imprimante, le flag Actif, le paramètre de segmentation, le flag batch obligatoire, qui sont considérés comme des éléments susceptibles d'être changés par l'utilisateur dans le cadre de procédures d'exploitation.

Là encore, il faut noter que les dictionnaires sont mis à jour, mais que la validation des écrans, et de façon générale la génération de code associée aux dictionnaires, sera faite dans une phase ultérieure.

8) Mise à jour des valeurs de codes activités

On commence par effacer toutes les lignes de la table ACTIV du dossier (y compris celles commençant par X, Y, ou Z). Puis on recrée les lignes à partir des nouveaux paramètres du dossier contenus dans la table ADOSACT du superviseur (avec la valeur Actif ou Inactif selon le cas, et les paramètres de dimensionnement associés).

9) Mise à jour des paramètres

On commence par mettre à jour le dictionnaire des paramètres de la façon suivante : tout paramètre inexistant dans le dossier en cours de validation est créé, tout paramètre standard qui n'existe plus dans le dossier de référence est supprimé, tout paramètre spécifique déjà existant n'est pas touché, sauf dans le cas de l'architecture à 3 niveaux avec code activité vertical, tout paramètre standard modifié est remis à jour.

Ensuite, on recopie les valeurs de paramètres définies au niveau du dossier dans le dossier de référence, si elles n'existent pas dans le dossier en cours de validation.

Il est important de noter que, contrairement à la version 130, il est maintenant possible de créer des paramètres spécifiques (commençant par X, Y ou Z), protégés par des codes activités, dans des chapitres standards (avant, il fallait les créer dans des chapitres dédiés commençant par X, Y, ou Z).

10) Mise à jour des tables diverses

On commence par mettre à jour le dictionnaire des tables diverses de la façon suivante :

• toute table diverse non définie dans le dossier en cours de validation est créée (aussi bien son paramétrage que son contenu)
• toute table diverse standard (ie. non marquée par un code activité commençant par X, Y, ou Z) qui n'existe plus dans le dossier de référence est supprimée (paramétrage et contenu).
• toute  table diverse spécifique déjà existante n'est pas touchée
• toute table diverse standard dont la structure est modifiée est remise à jour dans sa structure conformément à la description ci-dessous.

La remise à jour de la structure de chaque table diverse est répercutée sur les codes contenus dans cette table de la façon suivante :

• si on a ajouté une rubrique (Alpha 1 ou 2, Numérique 1 ou 2) dans la définition de la table diverse, on reporte la valeur contenue dans les codes correspondants s'ils existent dans le dossier de référence.
• si on a supprimé une rubrique, on la remet à vide sur tous les codes de la table.

Il est à noter que les tables 901 à 999, réservées au superviseur, sont toujours recopiées (paramétrage et contenu) depuis le dossier de référence (elles ne peuvent jamais être considérées comme spécifiques).

11) Mise à jour des formules d'épuration et historisation

Le principe de mise à jour est le suivant : toute formule non définie dans le dossier en cours de validation est créée, toute formule standard qui n'existe plus dans le dossier de référence est supprimée, toute  formule spécifique déjà existante n'est pas touchée, sauf architecture à 3 niveaux et code activité vertical, toute formule standard modifiée est remise à jour pour tous les éléments de définition (ie. les éléments de date, d'heure, de fréquence ainsi que le flag Actif ne sont pas modifiés).

12) Mise à jour d'éléments divers

Il s'agit ici d'une mise à jour de type dictionnaire : tout élément non défini dans le dossier en cours de validation est créé, tout élément standard qui n'existe plus dans le dossier de référence est supprimé, tout  élément spécifique déjà existant n'est pas touché, sauf architecture à 3 niveaux et code activité vertical, tout élément standard modifié est remis à jour.

Les éléments correspondants sont :

ORDRE	ELEMENT DU DICTIONNAIRE
1	Transactions système
2	Consultations
3	Navigations
4	Transactions applicatives

13) Mise à jour des tables applicatives

La revalidation de toutes les tables applicatives dont la structure a été modifiée dans la phase  (6) est alors faite, en utilisant valfil.

14) Exécution de scripts éventuels

S'il existe des scripts SQL stockés dans le répertoire PCD du dossier de référence, sous la forme de fichiers ascii, commençant par majdos, d'extension sql, ces scripts sont exécutés (en création, la racine des scripts est credos). Ceci permet d'envisager des créations automatisées de vues, par exemple, et n'existait pas en version 130. Il est important de noter que ces scripts :

• peuvent contenir des commentaires, les lignes commençant par le caractère # étant ignorées.

• peuvent contenir le nom du dossier, sous la forme d'une variable nommée %nomap% : la substitution de cette variable sera faite avant l'exécution du script.

• sont limités à 100 lignes (commentaires et lignes vides exclues) de 250 caractères. Mais il est bien entendu possible d'exécuter plusieurs scripts, les scripts étant exécutés dans l'ordre alphabétique des noms de fichiers.

• sont exécutés par l'intermédiaire du moteur adonix (on est donc connecté comme l'user correspondant au nom de dossier, et on dispose des privilèges accordés par les rôles user_ADONIX et admin_ADONIX).

15) Copie de données

La phase de copie de données permet de transférer des données de tables issues du dossier de copie. Cette copie n'est faite, dans un contexte de revalidation, que sur les tables nouvellement activées dans la mesure où, par exemple, on a activé un module qui ne l'était pas. Bien entendu, cette copie peut être automatique ou conditionnelle (ie. dépendant des informations saisies dans l'onglet Init de la gestion des dossiers).

16) Génération de code

Cette phase correspond à la validation des différents éléments du dictionnaire. Seuls les éléments modifiés dans les phases précédentes vont être revalidés (sauf exception, car un changement de version par exemple peut imposer une régénération du code). Les éléments revalidés sont dans l'ordre les suivants :

ORDRE	ELEMENT DU DICTIONNAIRE
1	Ecrans
2	Objets
3	Fenêtres
4	Consultations

Ces validations sont, le cas échéant, réalisées dans toutes les langues du dossier (et aussi dans la langue d'installation si elle ne fait pas partie des langues du dossier).

17) Contrôle des liens

Cette phase fait un contrôle d'intégrité référentielle sur les données copiées lors de la mise à jour du dossier, s'il y en a eu (phase 15). On vérifie donc, pour ces tables, la totalité des enregistrements. Si la valeur de zones liées à d'autres tables ne correspond pas à une valeur de clé existante, l'enregistrement copié est supprimé si le lien est obligatoire ; si le lien n'est pas obligatoire, l'enregistrement est réécrit avec une valeur de clé vide.

18) Mise à jour après modification structure

Si la validation du dossier est faite alors que le dossier à mettre à jour est dans une version antérieure à la version du dossier de référence, cette phase va appeler des traitements normalisés de mise à jour qui doivent être appliqués (s'ils existent) après que la structure des données ait été mise à jour. Ceci intègre par exemple la fixation de valeurs par défaut dans des champs nouveaux de tables standard. Lorsqu'on passe d'une version à une version qui n'est pas immédiatement consécutive, les traitements de mise à jour sont exécutés successivement.

Notez que ceci impose de ne pas créer un champ dans une version donnée, lui donner une valeur dans cette phase de mise à jour, puis le supprimer dans une version ultérieure et être amené à faire ces deux changements de version par une seule migration (car la phase de mise à jour ne va pas trouver le champ en question). Il est à noter que ceci n'est pas le cas en standard, les suppressions de champ étant rarissimes.

19) Génération des transactions

Cette phase va régénérer le code associé aux transactions paramétrables, dès lors que les éléments de base (et en particulier les écrans modèles) ont été modifiés. Cette phase peut être forcée dans certains changements de version.

20) Mise à jour de paramètres divers

Cette phase renseigne divers paramètres : langue par défaut, nom du dossier, modules actifs, indicateur Web, version courante, dossier de test, mise à jour du menu local des axes analytiques si leur nombre change… Il s'agit en général de paramètres non modifiables par l'utilisateur. D'autres mises à jour peuvent se produire dans cette phase en cas de création de dossier (création d'au moins un utilisateur, initialisation des compteurs, création des premiers exercices et périodes…)

21) Validation des menus utilisateurs et création des fichiers de menus locaux

Les menus des utilisateurs sont régénérés dans toutes les langues du dossier : celui de l'administrateur est refait à partir de la table des fonctions qui peut avoir changé, ceux des utilisateurs sont simplement purgés des fonctions qui n'existeraient plus. Il est à noter que les utilisateurs autres que l'administrateur ne bénéficient pas, pour d'évidentes raisons de sécurité, des nouvelles fonctions créées lors de la mise à jour.

De la même façon, on crée un fichier séquentiel par langue, contenant les menus locaux. Ce fichier est téléchargé à la connexion sur les postes clients (cette génération est faite juste avant la validation des écrans dans le cas où le dossier est géré en Web).

22) Mise à jour des informations de version

Dans cette phase, les fichiers PARAM.ini, et version.inf, qui contiennent les paramètres du dossier et le numéro de version courante, sont créés dans le répertoire du dossier sur le serveur d'application.

23) Fin de mise à jour

Dans cette phase, on vide la table des verrous applicatifs (APLLCK), on remet à jour des indicateurs utilisés pendant la mise à jour, on met à jour les paramètres du dossier avec le bon numéro de version, on repasse en mode multi utilisateur, et finalement on affiche la trace de validation si l'on n'est en batch.

Messages d'erreur

Les messages d'erreur susceptibles d'arriver sont extrêmement variés, et il est impossible d'en établir une liste exhaustive. Ces erreurs sont indiquées dans la trace de validation. Toutes ne sont pas graves (par exemple, l'impossibilité de revalider un écran faute de place signifiera simplement qu'il faudra revoir l'écran manuellement). Mais en tout état de cause, il faut examiner soigneusement la trace de validation et toutes les erreurs éventuelles qui s'y trouvent avant de reprendre l'exploitation.

En cas d'erreur grave, il est possible que le dossier soit dans un état incohérent empêchant son utilisation, et même une connexion dessus, le dossier étant verrouillé. On peut alors déverrouiller le dossier avec la fonction de maintenance correspondante, mais il faut être conscient que cette opération ne débloquera que momentanément la situation en permettant une connexion à des fins de diagnostic. En effet, il ne faut jamais considérer que le dossier va à nouveau pouvoir être utilisé normalement. La procédure à suivre est alors de résoudre le problème à l'origine de l'incident (ce peut être un manque de place sur disque par exemple), et de relancer la validation qui va normalement reprendre là où elle s'était arrêtée. Dans le pire des cas, il faudra repartir d'une sauvegarde, qui doit avoir été faite avant le lancement de la validation.

Tables mises à jour

La totalité des tables du dossier peut être mise à jour par ce processus complexe.