Développement >  Utilitaires >  Patchs >  Test de patchs  

Ergonomie |  Sommaire

Lorsqu'on réalise des développements spécifiques en modifiant des éléments standards, la règle veut que l'on protège, par un code activité commençant par X, Y, ou Z, l'élément de plus bas niveau possible qui a été modifié (le champ d'un écran plutôt que le bloc ou l'écran lui-même, par exemple). L'utilisation d'un code activité n'est par ailleurs pas nécessaire lorsqu'on utilise, dans un écran, des actions SPE ou SPX, ou commençant par X, Y, ou Z.

Il reste qu'un tel développement nécessite des vérifications à l'installation de patches standards sur un dossier modifié. En effet, il faut s'assurer que les éléments patchés n'entrent pas en conflit avec des éléments modifiés (dans ce cas, les éléments, protégés par un code activité, ne seront pas patchés, ce qui peut poser des problèmes).

Cette fonction permet de réaliser, de façon automatique, une détection des collisions potentielles liées à un ensemble de fichiers de patches présents dans un répertoire. Pour être plus précis, elle réalise les choses suivantes :

• elle lit tous les patches présents dans un répertoire
• pour chaque objet patché, elle recherche s'il y a un conflit potentiel dû à un code activité spécifique (sauf si ce code activité spécifique a été mis en tête du patch comme devant être écrasé).
• elle génère un fichier de trace détaillant les conflits possibles.

 Ainsi, lorsque des développements spécifiques ont été réalisés, et qu'une liste de patch standard (ou spécifique) doit être installée, il suffit de lancer cette fonction :

• si aucune collision n'est détectée, le risque de problème est normalement inexistant (si les normes de développement spécifiques ont été correctement suivies).
• s'il y a des collisions, il n'y a plus qu'à se focaliser sur ces collisions détectées (qui devraient normalement représenter une partie minime des cas).

Si plusieurs listes de patch doivent être installées, il est possible de copier (le temps du test) l'ensemble des fichiers correspondants dans un même répertoire : le testeur est uniquement limité au test de 1000 fichiers de patch simultanés.

Les tests faits sont les suivants :

• les écrans, les tables, les objets, les fonctions, les types de données, les consultations, les fenêtres, les actions patchées et globalement protégées par un code activité.
• les champs et les blocs dans un écran, les options et variables dans une fonction, les champs et les index dans une table, les boutons dans une fenêtre, les listes gauches (onglet browser), onglets, et tables liées dans un objet, lorsque ces éléments sont protégés par un code activité sans que l'élément de niveau supérieur le soit.
• les traitements et états installés localement dans un dossier pour lesquels le patch risque de ne pas être effectif.

Les conflits liés à des codes activités spécifiques (commençant par X, Y ou Z) sont tous détectés, sauf ceux correspondant à des codes activités donnés dans l'en-tête de patch (comme il s'agit dans ce cas d'un patch spécifique, on sait que le patch sera appliqué).

Afin de permettre ce type de test lorsque la mise à jour n'est pas réalisée par l'installation de fichiers de patches, mais par l'installation d'une nouvelle sous-version, on trouvera, à partir du CD de la version 134, dans des répertoires dédiés (les sous-répertoires P132, P133, P134… du répertoire nommé X3patch), une liste de fichiers nommés List_nn.dat, qui contiennent non pas les patches de la liste nn, mais uniquement la liste des objets touchés par la liste de patch, ce afin de permettre de savoir les conflits potentiels existant sur une liste. L'utilisation qui en sera faite peut être expliquée par l'exemple suivant :

• imaginons que le dossier que l'on veut mettre à jour en version 134, soit en version 132 patché jusqu'au niveau de la liste 12.
• le passage en version 134 reviendrait à mettre en place les patches 13 à 18 (ce qui permet de passer en version 133 : les fichiers List_nn correspondants sont dans le répertoire X3patch\P133 sur le CD), et les patches 19 à 31 (ce qui permet de passer en version 134 : les fichiers List_nn correspondants se trouvent dans le répertoire X3patch\P134 sur le CD).
• il suffit donc de copier les fichiers List_13.dat à List_31.dat dans un répertoire temporaire, puis d'utiliser la fonction de test de patches en donnant le nom de ce répertoire. Si des conflits sont signalés, on aura alors dans la trace l'élément en conflit et le numéro de la liste correspondante ; il sera alors possible de tester la liste en question pour en savoir davantage.

Attention, cet utilitaire se contente de donner les conflits potentiels, il n'est pas capable de dire ce qui devrait être modifié dans l'élément devenu spécifique pour que tout marche parfaitement (c'est bien évidemment impossible). Il est par contre possible de réaliser des tests sur les éléments litigieux en utilisant la fonction de comparaison sur les éléments correspondants entre un dossier patché et un dossier non patché.