Introduction

La gestion des patches permet d'intégrer des éléments du dictionnaire à partir d'une archive, en respectant :

  • les codes activités spécifiques et verticaux (ie. ceux commençant par X, Y, ou Z, sauf s'ils font partie de la liste explicite donnée en tête de patch pour permettre de modifier des éléments spécifiques).
  • certains champs d'un élément patché considérés comme faisant partie du paramétrage. Ces champs sont susceptibles d'être modifiés par l'utilisateur, et ne sont donc pas modifiés lors d'un patch contenant un élément déjà existant (bien entendu, la première fois que l'élément est patché, ces éléments sont intégrés pour permettre de disposer d'une valeur par défaut).

Ceci signifie qu'une fois un élément patché, certains champs de cet élément ne sont plus modifiables par patch. La seule solution, si on désire absolument modifier un élément, est alors de patcher un traitement modifiant les données, et de l'exécuter en séquence (ce qui est possible via le type d'élément EXE).

Il est enfin à noter :

  • que les champs CREDAT et CREUSR (s'ils existent dans la structure du dictionnaire impacté par le patch) sont mis à jour en cas de création d'un nouvel élément.
  • que les champs UPDDAT et UPDUSR (s'ils existent dans la structure du dictionnaire impacté par le patch) sont mis à jour en cas de modification d'un nouvel élément.
  • que le patch de données dans une table non couverte par la liste standard met à jour les données sans filtre sur les champs.

Ceci étant dit, on trouvera dans la suite, pour chaque type d'élément impacté, la liste des champs qui ne sont pas mis à jour par patch en cas de mise à jour.

Règles générales

L'outil de patch permet de patcher :

  • un ensemble d'éléments de type développement (ce sont les traitements, et tous les éléments du dictionnaire : types, description de tables, écrans, fenêtres, actions...). Ces patches sont identifiés par un code qui correspond à l'objet patché.
    A part les traitements, qui ne sont installés que dans le dossier racine (X3 pour Sage X3), et dans des dossiers marqués "de test", tous les autres éléments sont mis à jour dans les différents dictionnaires des dossiers patchés, avec un filtre tenant compte des codes activités présents sur les différents éléments. Ainsi, un élément protégé par un code activité spécifique ne sera pas mis à jour par un patch standard.
  • un ensemble d'éléments de type paramétrage qui ont un code activité dans leur définition (processus, modèles d'import-export, événements Workflow notamment). Dans ce cas, la même règle s'applique, c'est-à-dire que la présence d'un code activité spécifique permet de protéger ces éléments d'un patch standard.
  • un ensemble d'éléments de type paramétrage qui n'ont pas un code activité dans leur définition. Dans ce cas, le patch s'applique sur les dossiers sur lesquels il a été installé, et ces paramétrages sont toujours remplacés par le contenu du patch. C'est notamment le cas pour les requêtes, les plans de travail Workflow... Il est recommandé, si on souhaite protéger des éléments standard modifiés, de les renommer afin d'éviter de les voir écrasés dans le cas où un patch les modifierait (ce qui est quand même rare).
  • un ensemble de données de paramétrage (basé sur la fonction définissant des modèles de paramétrage). Dans ce cas particulier, l'application de ces patches (codés AAA) se fait en tenant compte à la fois de filtres liés à des codes activités (s'il existent dans les tables patchées), et de filtres de législation (si un champ législation existe dans le modèle de paramétrage, uniquement les données associées à une législation vide ou à une législation présente dans le dossier sont appliqués).
  • des patches de données génériques. Ces patches sont identifiés par l'abréviation de la table qui doit être patchée. Dès lors qu'une abréviation de table ne correspond pas à un type prédéfini de patches, le superviseur considère qu'il s'agit de données à plat d'une table. Ce type de patches s'applique  sans aucun filtrage de code activité.
  • enfin, le cas particulier des pièces automatiques (GAU) mérite d'être noté. Ces éléments ne sont patchés que dans le dossier racine et dans des dossiers de type test, mais jamais dans un dossier d'exploitation. Il appartient aux personnes en charge du paramétrage de comparer les pièces automatiques du dossier X3 et celles du dossier d'exploitation avant de copier ou de transférer les modifications faites, le cas échéant.

Patch des actions

Le champ SPETRT (traitement spécifique) n'est pas remis à jour par un patch standard. Il ne l'est que par un patch spécifique.

Patch des codes activités

Les codes activités sont patchés dans la table ACTIV, et sont également créés dans les paramètres de chaque dossier (table ADOSACT) dans l'état dans lequel ils sont livrés (actif ou non selon le cas). Ceci n'entraîne pas pour autant la revalidation des dossiers en question.

Patch des tables diverses

Le paramétrage des tables diverses (table ATABTAB) peut être patché en création comme en mise à jour. Les champs code d'accès (ACS),  longueur du code (LNG), table de dépendance (DEPNUM), intitulés (LNGDES et SHODES) ne sont pas remis à jour.

En intégration de patch du contenu d'une table diverse (table ATABDIV), les lignes sont mises à jour sans restriction.

Patch des paramètres

Seul le champ code d'accès (ACS) n'est pas remis à jour.

Patch des écrans

Lorsque le patch est de type standard, les actions spécifiques ou verticales (SPE,SPV, code action >=X) sont toujours gardées, ainsi que le traitement spécifique (TRTSPE) et vertical (TRTSPV).

Pour supprimer ou modifier les actions spécifiques (SPE), ou le traitement spécifique (TRTSPE), le patch doit être de type spécifique; pour supprimer ou modifier les actions verticales (SPV), ou le traitement vertical (TRTSPV), le patch doit être de type vertical.

Par ailleurs, sont considérés comme du paramétrage non remis à jour en cas de patch intégré sur un écran déjà existant, les champs suivants :

  • sur les lignes d'écran : CODACC (code d'accès), CODCTL (table de contrôle), STYZON, STYCND, INTSTYL (styles).
  • sur l'en-tête de l'écran : les champs NBRCOL et NBRLIG (dimensions) sont protégés à condition qu'il y ait au moins un code activité spécifique sur l'écran (sur une zone ou un bloc). Sinon, l'écran est considéré comme standard et peut voir son dimensionnement changer au prochain patch.

SEEINFO Les blocs et lignes protégés par un code activité ne sont pas impactés.

Les mots-clés d'aide sont respectés, sauf si le patch est spécifique et que les mots-clés en question commencent par X,Y, ou Z.

Patch des fenêtres

Les écrans spécifiques inclus dans une fenêtre ne sont pas impactés en cas de mise à jour (sauf bien entendu si le code activité qui les protège est référencé dans le patch).

Patch des objets

Les champs suivants, considérés comme du paramétrage, ne sont pas remis à jour en cas de patch d'un objet déjà existant : SELCLE (index), SELORD (ordre), SELTREE (liste hiérarchisée), SELCAR (nombre de caractères pour sélection), RPT1, RPT2 (états associés), LIBSHO (intitulé court), STA (statistiques). Les tables ouvertes en spécifique sont également respectées(sauf bien entendu si le code activité qui les protège est référencé dans le patch).

Le champ SPETRT (traitement spécifique) n'est pas remis à jour par un patch standard. Il ne l'est que par un patch spécifique.

Le champ SPVTRT (traitement vertical) n'est pas remis à jour par un patch standard. Il ne l'est que par un patch vertical.

Patch des états

Les champs suivants, considérés comme du paramétrage, ne sont pas remis à jour en cas de patch d'un état (dictionnaire) déjà existant : GRP (groupe), ACS (code d'accès), PRTNAT (type de destination), PRTDEF(destination par défaut), PRTOBL (flag destination obligatoire), PRTFRM (formule destination), ENAFLG (flag actif), PARSEG (paramètre de segmentation), EXEBAT (flag d'exécution batch), HOR (contrainte horaire).

Le champ SPETRT (traitement spécifique) n'est pas remis à jour par un patch standard. Il ne l'est que par un patch spécifique.

Le champ SPVTRT (traitement vertical) n'est pas remis à jour par un patch standard. Il ne l'est que par un patch vertical.

Patch des tables

En cas de patch d'une structure de table existante (ATB), les éléments suivants ne sont pas mis à jour :

  • le nombre d'enregistrements (NBENREG)
  • la case à cocher concernant les textes traduisibles (GENTRA) est mise à jour si le patch impose une valeur égale à 2.
  • les champs relatifs à l'audit (AUDCRE, AUDUPD, AUDDEL, AUDWRK dans l'en-tête, ainsi que le contenu de la table ATABAUD).

Patch des consultations

Seul le champ PRGSPE (traitement spécifique) n'est pas remis à jour. sauf sur patch spécifique.

Patch des formules d'épurations

Les champs EPU, TIM1, TIM2, FRQ1, FRQ2, DAT1, DAT2 ne sont pas remis à jour en cas de patch d'une formule d'épuration (il s'agit des règles et fréquences d'épuration et d'archivage). Le champs ENAFLG (flag actif) est également respecté.

Le champ SPETRT (traitement spécifique) n'est pas remis à jour par un patch standard. Il ne l'est que par un patch spécifique.

Patch des navigations

Seul le champ ENAFLG (flag actif) n'est pas remis à jour.

Patch des modèles d'import/export

Seul le champ CHRNUM (numéro de chrono export) n'est pas remis à jour.

Patch des élements BI

Les champs suivants, considérés comme du paramétrage, ne sont pas remis à jour en cas de patch :

  • Patch Datamart(ABM) : RESULT(Résultat),DUREE(durée),AUZFCY(Autorisation site),FNC(Fonction)
  • Patch Dimension(ABI) : TYPMAJ(Type de mise a jour)
  • Patch Etat BO(ABO)     : ACS(Code d'accès)