Création de patch

Gestion de l'écran

Ecran de saisie

Types d'éléments pouvant être patchés

Ce tableau permet de saisir une liste d'objets à patcher. Cette liste est identifiée par un type d'objet et un nom. La définition des différents types et la signification du nom sont donnés ci-après. La colonne Rangpermet de connaître l'ordre dans lequel les types d'éléments sont rangés dans le patch (cf. le paragraphe ci-dessous). Les éléments qui ont le rang 100 dans le tableau sont toujours placés en fin de patch (dans l'ordre alphabétique des codes des éléments).

Remarques importantes

Transfert total des données d'une table

Le code TAB permet de transférer les données de la table, en la rechargeant dans la base avec sa structure et ses données. Par contre, on ne crée pas les éléments du dictionnaire concernant cette table, ce qu'il fait qu'elle peut ne pas apparaître comme visible. Aussi, ce code est-il bien adapté lorsqu'on désire recharger une table déjà créée dans les dossiers à patcher, et qui n'a pas changé de structure. Si tel n'est pas le cas, il faut mettre deux lignes dans la définition du patch : la première concerne la définition de la table (ATB XXXXX), la deuxième son contenu (TAB XXXXX). Même si elles ne sont pas placées dans cet ordre à la saisie, la fonction de patch va les replacer dans cet ordre. A l'intégration du patch, la table va être créée dans le dictionnaire et dans la base si elle n'existe pas (sinon, sa structure sera mise à jour si elle a varié). Puis le rechargement de la table avec les données sera réalisé.

Transfert partiel des données d'une table

La possibilité de transférer le contenu partiel d'une table est obtenue en donnant dans la colonne type l'abréviation de la table, et en indiquant dans la colonne Nom une condition logique qui sera utilisée pour l'extraction du dossier de départ, et pour l'intégration dans le dossier d'arrivée. Il est important de noter que les données ainsi extraites pourront modifier des données existant avec les mêmes clés, ou créer de nouvelles données. Par contre, et pour des raisons de sécurité, en aucun cas, il n'y aura d'effacement de données lors de l'intégration du patch. Ainsi, par exemple, si on considère la situation suivante, pour la table des pays (d'abréviation TCY) :

Si dans le patch on indique une ligne avec TCY et la condition CRY="AL", le patch ne va contenir que la ligne correspondant au pays Albanie, et l'intégration du patch dans le dossier d'arrivée va réécrire AL , Allemagne pour le remplacer par AL, Albanie.

Si dans le patch on indique une ligne avec TCY et la condition pat(CRY,"A*"), le patch va contenir les 4 lignes AD, AE, AF et AR. A l'intégration, on va créer la fiche AE, United Arab Emirates, la fiche AR, Argentine, remplacer AL, Allemagne par AL, Albanie et garder A, Afghanistan, et AU, Australie, qui n'avaient pas été livrés, mais existaient déjà dans le dossier d'arrivée.

Si dans le patch on indique une ligne avec TCY et la condition find(CRY,"AD","AE","AL"), le résultat aurait été le même, sauf en ce qui concerne AR, Argentine, qui n'aurait pas été transféré.

La seule manière d'effacer des données consiste :

• Soit à remplacer globalement le contenu d'une table complète (patch de type TAB)
• Soit à livrer un traitement par le code EXE (cf. ci-dessous). Par exemple, si on avait voulu s'assurer que dans les pays commençant par A, seuls les pays de code AD, AE, AL restaient présents dans la liste, on aurait livré un traitement (appelé par exemple MAJPATCHnnn) qui aurait contenu les ligne décrites dans l'exemple ci-dessous.

Exécution d'un traitement

Un cas particulier doit être mentionné : le code EXE, qui permet de donner le nom d'un traitement à exécuter. Ce traitement est exécuté en fin d'intégration de patch (il peut exister au préalable ou être livré dans le patch lui-même, puisque l'exécution ne se fait qu'à la fin de l'intégration).

Ce traitement doit intégrer un sous-programme PATCH, avec un argument qui est le code dossier. C'est ce sous-programme qui sera exécuté. Ainsi, pour le cas ci-dessus, on obtiendrait le programme suivant  :

Subprog PATCH(NOMDOS)
Value Char NOMDOS
Local File =NOMDOS+".TABCOUNTRY" [TCU]
Trbegin [TCU]
Delete [TCU] Where pat(CRY,"A*")=1 & find(CRY,"AD","AE","AL")=0
Commit
End

Ainsi qu'on le voit ci-dessus, il est donc nécessaire de déclarer les tables dans ce sous-programme en tenant clairement compte du fait qu'elles doivent être déclarées sur un dossier qui n'est pas forcément le dossier courant (c'est la syntaxe a syntaxe Local File = NOMDOS + ".NOMTABLE" qui l'assure)

Traitements génériques à exécuter

Lorsque des patches sont réalisés sur des éléments modèles de l'interface utilisateur (écrans modèles utilisés pour créer des fenêtres de transaction), une revalidation des écrans en question est nécessaire.

Cette revalidation peut être exécutée en déclarant, dans la maintenance, l'exécution du traitement approprié. On trouvera ci-dessous les traitements standard à lancer selon le type d'élément patché :

Il est important de noter que ce type de fonctionnalité est réalisable également en spécifique (il suffit de rajouter le sous-programme PATCH ainsi qu'indiqué dans le précédent paragraphe).

Patch de documentation

La structure des données de la documentation est un peu particulière. En effet, par défaut les règles suivantes s'appliquent en création ou revalidation de dossier :

• les textes et fichiers de la documentation (tables ADOCBLB et ADOCCLB) sont remplies dans le dossier superviseur et ne sont pas transférées dans les dossiers qui en dépendent (mais il est possible de créer des textes d'aide locaux à un dossier qui seront alors stockés localement).
• la structure de la documentation (liens de documentation, qui sont pratiquement des éléments du dictionnaire, et structure des paragraphes) est stockée dans chaque dossier et copiée dans les dossiers situés en dessous en cas de revalidation (avec le respect de codes activité verticaux ou spécifiques qui auraient pu être définis dans un dossier fille).

Aussi, quand on intègre un patch de doc (type ADO), le principe est le suivant :

• la structure de la documentation est intégrable dans tous les dossiers listés lors de l'application du patch, quel que soit le type de patch (en fonction de la liste des dossiers donnée à l'intégration).
• les textes et fichiers sont intégrés uniquement dans le dossier superviseur si le type de patch est Superviseur (ce qui est le cas pour les patches de doc standard). Si le type de patch est autre, les textes et fichiers peuvent être intégrés dans tous les dossiers.
• le patch de type ADF (liens) est intégrable dans tous les dossiers, même si le patch est de type Superviseur.

Nommage des fichiers de patch

L'intégration de patch vérifie la séquentialité de passage des fichiers de patch, dès lors qu'ils intègrent une séquence numérique dans leur nom. Il est conseillé d'appeler les fichiers de patch en utilisant un nom défini sous la forme X_yyyy_zzz.dat, avec les significations suivantes :

• X est un caractère (différent de P, car P est utilisé pour les patches standard) qui identifie le type de patch
• yyyy est un numéro séquentiel (commençant en principe à 0001).
• zzz est un identifiant de la version à intégrer.

Si cette norme est appliquée, lors de l'intégration d'un ensemble de fichiers de patches dans un répertoire, les contrôles suivants vont être faits :

• on ne mélange pas dans une même intégration des fichiers issus de versions différentes
• on ne saute pas de numéro séquentiel si des patches identifiés par le même caractère et le même numéro de version ont déjà été intégrés. Ainsi, par exemple, si le patch Z_0005_150.dat a été intégré, et si on essaye d'intégrer le patch Z_0007_150.dat sans avoir au préalable intégré le patch Z_006_150.dat, une erreur sera signalée à l'intégration.

Ordre des éléments dans un fichier de patch

Quand on crée un fichier de patch, la norme veut que l'on fasse en sorte que les éléments qui s'y trouvent forment un tout dont l'application laisse un dossier dans un état cohérent. En particulier, si on crée une nouvelle fonction par patch, que cette fonction soit définie par une action, une fenêtre, un écran, une table, et deux traitements, il paraît logique que l'ensemble de ces éléments soient présents dans le patch.

Lorsqu'un ensemble d'éléments sont utilisés pour former un fichier de patch, la fonction de création les range dans un ordre précis de types, afin d'éviter tant que faire se peut les erreurs à l'intégration. En effet, si par exemple on intègre une fenêtre avant les écrans qui la composent, une erreur Ecran inexistantva se produire lors de sa validation. Ainsi, on intègre toujours d'abord les types de données avant les écrans et les tables, les écrans avant les fenêtres, et ainsi de suite.

L'ordre utilisé lors de la génération du patch correspond au rang donné dans le tableau ci-dessus. C'est également l'ordre de proposition qui apparait dans la fonction de patch automatique.

Il faut toutefois remarquer qu'il est impossible de résoudre tous les conflits possibles. En effet, pour prendre un exemple, un type de données peut faire référence à une action, qui fait peut faire référence à une fenêtre, qui peut faire référence à un écran, qui peut faire référence à ce type de données. Pour résoudre ce type de cas de conflit (rare), il peut être nécessaire de décomposer le fichier patch en deux fichiers (le premier livrant tous les éléments avec un type de données ne faisant pas référence à l'action, le second livrant le type de données intégrant l'action, par exemple).

Eléments du dictionnaire non patchés

Lorsqu'on installe un patch contenant des éléments du dictionnaire, il faut noter que certains champs, considérés comme des éléments paramétrables du dictionnaire, sont respectés quels que soient par ailleurs les protections par code activité dont ils bénéficient. C'et le cas par exemple pour une destination par défaut dans un état.

On trouvera une annexe technique le détail des champs respectés.

Format particulier des éléments AAA

Un patch de type AAA correspond à une ligne issue d'un modèle de paramétrage. Elle utilise un format particulier pour le code de l'élément. Ce format est l'un des deux formats suivants :

MODELE~CODE_LEG~CODE_TRS~='FORMULE_SELECTION'

MODELE~CODE_LEG~CODE_TRS~CLE~SOUS_CLE~SOUS_SOUS_CLE...

Dans ces lignes, on a :

• MODELE correspond au modèle de données utilisé pour décrire les tables à extraire
• CODE_LEG correspond au code législation, qui peut être vide (on aura alors deux ~ qui se suivent)
• CODE_TRS correspond au code transaction, qui peut aussi être vide
• FORMULE_SELECTION est une condition de filtrage. Toute chaine littérale doit être exprimée "entre doubles quotes", puisque la formule est encadrée 'entre simple quotes'.
• CLE~SOUS_CLE~SOUS_SOUS_CLE (le nombre de sous-clés étant variable) correspond au cas particulier où on veut simplement sélectionner une valeur de clé correspondant à la table principale du modèle. Ce type de possible uniquement lorsqu'on appelle un modèle (code AAA) depuis la création de patch, et que l'on ouvre la fenêtre qui permet alors de sélectionner le modèle et de renseigne la clé par recherche directe.

Etats

Par défaut, les états suivants sont associés à la fonction :

 PRTSCR : Impression écran

Mais ceci peut être modifié par paramétrage.

Tâche batch

Cette fonction peut être lancée en batch. La tâche standard ZPATCH est prévue à cet effet.

Boutons spécifiques

Messages d'erreur

Outre les messages génériques, les messages d'erreur suivants peuvent apparaître lors de la saisie :

…. : répertoire inexistant

Le chemin d'accès au fichier patch n'existe pas

Type d'objet incorrect

Le type d'objet ne correspond ni à un des types d'objets prédéfinis, ni à l'abréviation d'une table existante.

Dictionnaire des … XXX fiche inexistante

On a essayé d'extraire un objet du dictionnaire inexistant

Valeur incorrecte

La condition d'extraction associée à l'extraction des données d'une table est syntaxiquement incorrecte.

Tables mises en oeuvre

Reportez-vous à la documentation de Mise en oeuvre