Création de patch

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

Cette table 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ées ci-après. La colonne Rang indique l'ordre dans lequel les types d'éléments sont rangés dans le fichier de patch (cf. le paragraphe ci-dessous). Les éléments qui ont le rang 100 dans la table sont toujours placés en fin de patch (dans l'ordre alphabétique des codes des éléments).

Code	Signification	Nom	Rang
AAA	Lignes issues d'un modèle de paramétrage	Format particulier, cf. paragraphe correspondant	100
ABA	Abonnement batch	Code de l'abonnement	46
ABF	Table de fait BI	Code de la table	54
ABG	Groupes de tâches	Code du groupe	47
ABI	Dimension BI	Code de la dimension	55
ABM	Datamart BI	Code du datamart	56
ABO	Etat Business Objects	Code de l'état	58
ABT	Tâche batch	Code de la tâche	45
ABV	Règle de synchronisation BI	Code de la règle	57
ACL	Table de contrôle	Code de la table	18
ACN	Consultation	Code de la consultation	36
ACS	Codes d'accès	Traité sous forme de condition (CODACS="valeur")	14
ACT	Action	Code de l'action	16
ACV	Définition d'un code activité	Code activité	1
ADC	Description d'un traitement (dictionnaire)	Nom du traitement	9
ADF	Liens de documentation	Type ~ Code de l'élément	50
ADI	Contenu d'une table diverse	Numéro de la table	24
ADO	Aide fonctionnelle (tous les paragraphes)	Type ~ Code de l'aide	49
ADP	Paramètre (à la fois sa définition et sa valeur s'il en existe au niveau général)	Code du paramètre	32
ADV	Paramétrage d'une table diverse	Numéro de la table	23
ADX	Traitement (uniquement sous forme compilée)	Nom du fichier de traitement	11
ADZ	Aide sur champ	Code de l'aide	48
AEN	Enchaînement d'import export	Traité sous forme de condition (CODE="valeur")	35
AFC	Fonction	Code de la fonction	17
AGB	Variable globale	Nom de la variable	20
AHH	Hiérarchie BI	Code hiérarchie	59
AHI	Formules d'épuration	Code de la formule	7
AII	Condition préféfinie BI	Code condition	60
ALH	Requêteur	Code de la requête	51
ALQ	Requêteur SQL	Code de la requête SQL	52
ALT	Requêteur graphique	Code de la requête	53
AMK	Ecran	Code de l'écran	28
AML	Menu local	Numéro du menu local	2
ANG	Navigation	Code de la navigation	10
ANM	Définition d'un compteur	Code du compteur	15
ANT	Paramétrage widget Netvibes	Code objet pour widget	65
AOB	Définition d'objet	Code de l'objet	30
AOE	Modèle d'import/export	Code du modèle	34
AOP	Propriétés d'objet	Code de l'objet	31
APH	Modèles de paramétrage	Code du modèle	100
APR	Processus graphique	Code processus	63
ARP	Définition d'état dans le dictionnaire	Code de l'état	29
ASL	Style conditionnel	Traité sous forme de condition (COD="valeur")	19
ASU	Description d'un sous-programme dans le dictionnaire	Nom du sous-programme	21
ASY	Style de présentation	Code du style	61
ATB	Définition d'une table (le contenu n'est pas transféré, la mise à jour de la structure est faite sans perdre les données communes)	Code de la table	25
ATN	Transactions	Code de la transaction	8
ATY	Type de données	Code du type	22
AUR	URL	Code de l'URL	27
AVW	Vue	Code de la vue	26
AWA	Règle Workflow	Code de la règle Workflow	43
AWE	Web service	Nom de publication	64
AWI	Définition de fenêtre	Code de la fenêtre	33
AWM	Modèle de données Workflow	Code modèle	41
AWR	Règle d'affectation Workflow	Code de la règle d'affectation	42
AWW	Paramétrage du plan de travail Workflow	Code du plan de travail	44
BIA	Objets BIAR	Code objet	4
ELT	Elément de l'interface cliente (xsl, image, fichier divers)	Chemin du fichier	3
ETA	Etat Crystal Reports (fichier d'extension rpt)	Nom de l'état	13
EXE	Demande d'exécution d'un traitement	Nom du traitement	6
GAU	Pièces automatiques	Code de la pièce	40
PS1	Déclencheur statistique	Code du déclencheur	37
PS2	Code statistique	Code statistique	38
TAB	Structure et contenu complet d'une table (sa définition « dictionnaire » exclue). Le patch global d'une table est une sauvegarde à plat de ce fichier : comme un .dat d'une sauvegarde de table dans le répertoire SVG. Tous les liens sur cette table ne sont pas pris en compte et en particulier les textes traduisibles contenus dans la table ATEXTRA.	Code de la table	39
TFO	Table des formules	Code formule	62
TRT	Source d'un traitement (le traitement sera compilé à l'installation du patch)	Nom du traitement	12
TXT	Fichier texte (dans le répertoire TXT)	Nom du texte	5
Abréviation d'une table	Contenu partiel de la table	Condition d'extraction (exprimée sous la forme d'une clause Where)	100

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, les éléments du dictionnaire concernant cette table ne sont pas créés, elle peut ainsi ne pas apparaître comme visible. Aussi, ce code est-il bien adapté lorsque vous désirez 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) :

Dossier de départ		Dossier d'arrivée
Code pays	Nom pays	Code pays	Nom pays
AD	Andorra	AD	Andorra
AE	United Arab Emirates	AF	Afghanistan
AL	Albanie	AL	Allemagne
AR	Argentine	AU	Australie
BE	Belgique	BE	Belgique
…		…

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 lignes 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 ou script à exécuter. Malgré son numéro de rang, 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 paramètre correspondant au 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

Comme on peut le voir 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é :

Elément patché	Traitement à lancer	Résultat
Ecran servant de base à une consultation paramétrable	SUBGTC	Validation de tous les écrans de consultation
Styles de présentation	SUBASY	Génération des styles
Transaction système	SUBAMI	Validation des transactions système
Paramètres statistiques	SUBPS2	Revalidation de toutes les statistiques
Ecran de base d'une transaction sur l'objet XXX	SUBXXX	Revalidation des transactions associées à l'objet

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 inexistant va 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

Lorsque vous installez un patch contenant des éléments du dictionnaire, veuillez noter que certains champs, considérés comme des éléments paramétrables du dictionnaire, sont respectés quelles 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.

 Une annexe technique présente 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 :

• 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 ZPATCHC est prévue à cet effet.

Boutons spécifiques

Rappel

Cette fonction permet de rappeler la liste des éléments contenus dans un fichier patch, afin de la compléter le cas échéant et de recréer un fichier patch. La fenêtre qui s'ouvre alors permet de sélectionner le fichier patch à lire.

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