Intégration de patch
Les progiciels utilisant la technologie SAFE X3 intègrent une fonction permettant d'intégrer des correctifs ou des évolutions fonctionnelles délivrées sous forme de fichier archives nommés « patches ». C'est ainsi qu'un développement tiers peut être intégré, que des données supplémentaires peuvent être chargées dans une table, que des correctifs peuvent être apportés.
Un patch peut contenir un ou plusieurs éléments tels que des écrans, des définitions de tables, des codes activités, des types de données, des objets, des menus locaux, des chapitres de messages, des traitements, des demandes d'exécution de traitements, des données...
L'intégration d'un patch modifie le dictionnaire et la base de données des dossiers sur lesquels il est appliqué. Une seule exception à ce principe : les traitements livrés par patch ne sont installés que sur le dossier superviseur (sauf cas particuliers explicités plus loin).
Cas particulier : Intégration d'une table
L'intégration d'une table se fait en deux étapes :
1. Mise à jour de la description de la table dans SAFE X3.
2. Validation de cette table (exécution du valfil) : durant cette dernière étape, si des statistiques bdd (base de données) existent sur cette table, elles peuvent être supprimées.
Ceci dépend des types de modifications de la table.
Exemples :
- Ajout d'un champ en fin de description de la table : les statistiques bdd sont conservées.
- Insertion d'un champ entre deux autres : les statistiques bdd sont perdues sur toute la table.
En effet la table est supprimée puis recréée.
Fichiers
Un fichier patch se caractérise par un nom intégrant en principe une séquence de numéros, afin de permettre de contrôler, lorsque plusieurs fichiers existent, que les patches sont bien intégrés dans l'ordre.
Le cas des patches correctifs livrés en standard est géré de la façon suivante :
- les fichiers sont définis avec le nom P_nnnn_vvv.dat, nnnn étant un numéro chronologique, et vvv la version majeure sur laquelle le patch peut s'appliquer (jusqu'à présent, vvv peut être égal à 110, 120, 130, 140, 150). Un fichier de ce type contient un ensemble d'objets ou d'éléments constitutifs d'un correctif ou d'une évolution fonctionnelle (par exemple, la livraison d'un nouveau point d'entrée).
- plusieurs fichiers de patches (en général au moins une dizaine, mais cela peut être bien davantage) sont organisés sous la forme d'une liste qui est disponible auprès des partenaires d'ADONIX.
- la mise en place d'une ou plusieurs listes se fait par cette fonction, qui intègre les fichiers dans l'ordre séquentiel des numéros chronologiques, un certain nombre de contrôles de cohérence étant réalisés (numéro de version sur laquelle le patch s'applique, séquentialité depuis la dernière mise à jour de patches).
Il est conseillé aux partenaires Sage désirant livrer des fonctionnalités sous formes de patches d'adopter la même politique de nommage des fichiers, en utilisant une première lettre différente (par exemple X, Y, ou Z). En effet, un contrôle de séquentialité est fait dès lors que le nom du fichier intègre les caractères _ (underscore) en position 2 et 7 du nom du fichier : les caractères 3 à 6 sont alors un numéro séquentiel sur lequel (à racine égale) va se faire un contrôle de séquentialité, et les caractères au delà du huitième (extension exclue) sont contrôlés par rapport au numéro de version majeure.
Pré-requis
Autres pré-requis
Il faut avoir au préalable installé le ou les fichiers de patch à intégrer dans un répertoire du serveur. Si plusieurs patches doivent être installés simultanément, il faut s'assurer qu'il n'y a que les fichiers constitutifs du patch à intégrer dans le répertoire (car dans ce cas, on va donner comme paramètre le nom du répertoire).
Il est conseillé (même si cela n'a rien d'obligatoire) de se connecter sur le dossier superviseur (qui se nomme, selon les progiciels, X3, PAYE, GX...) pour intégrer les patches. En effet, réaliser toute gestion ou maintenance de dossier à partir du dossier de référence est un bon principe.
Avant d'intégrer des patches, il faut s'assurer en outre que :
- Les tâches comptables de tous les dossiers sont arrêtées, ainsi que tout autre tâche batch.
- Le serveur batch est inactif (par mesure de sécurité au cas où une tâche batch serait en attente). Ce conseil est bien sûr valable si on n'intègre pas les patches en batch !
- L'intégration des patches se fait en mono utilisateur pour l'environnement et à partir du dossier superviseur (ce contrôle est assuré lorsque l'on intègre les patches en batch).
L'intégration d'un patch standard s'applique au minimum au dossier superviseur, et généralement à l'ensemble des dossiers se trouvant dans l'environnement concerné. En effet, si un dossier n'est pas mis à niveau des patches, il risque de ne plus fonctionner correctement, car un traitement présent uniquement dans le dossier superviseur peut s'appuyer sur une structure de données modifiée dans le même patch. Or un traitement de dossier superviseur sera automatiquement hérité dans tous les autres dossiers, alors que la structure de données sur laquelle il s'appuie n'aura pas été intégrée dans le dossier en question, ce qui provoquera une incohérence. De ce fait, si le dossier superviseur ne fait pas partie des dossiers de la liste, les traitements ne sont pas patchés.
Des cas particuliers existent :
- si un dossier est de type Test (ce flag est défini dans les paramètres de gestion du dossier), les traitements seront intégrés dans le dossier lui-même. Ainsi, si l'on désire réaliser un test de fonctionnement d'un patch (par exemple sur un dossier intégrant beaucoup de spécifiques) sans perturber l'environnement d'exploitation, il est possible de n'intégrer le patch que sur ce dossier : les traitements et le dictionnaire seront alors patchés, ce qui permettra de réaliser un test complet. Attention toutefois, le fait d'installer des traitements standard sur un dossier rend ensuite ce dossier particulier : l'application uniforme d'un autre patch sur l'ensemble des dossiers y compris celui-ci risque de na pas être opérant sur le dossier de test (car les traitements existants dans le dossier de test ne sont pas hérités du dossier superviseur).
- si un patch intègre des traitements spécifiques (commençant par X, Y, ou Z, ou encore par SPE, ou SPV, ou bien obéissant au modèle CNS???SPE), ces traitements ne seront intégrés dans le dossier que s'ils existent déjà ; sinon, ils seront intégrés dans le ou les dossiers de type Développement (ce flag est défini dans les paramètres de gestion du dossier). Ceci est valable pour un patch de type standard, spécifique, ou vertical (cette distinction ne servant qu'à gérer correctement les actions spécifiques et verticales dans les écrans).
- si un patch est de type Superviseur, il n'est intégré que dans le dossier superviseur. C'est notamment le cas de certains patches contenant des mises à jour de la documentation standard, ou de jeux de paramètres par défaut.
Si une mise à jour sur tous les dossiers est faite (ce qui est le cas le plus fréquent), les dossiers qui auraient un niveau de patch inférieur à celui du dossier superviseur devront être revalidés pour être en adéquation avec l'environnement.
Gestion de l'écran
Ecran de saisie
Présentation
On saisit, dans la fenêtre qui s'ouvre, les informations relatives à l'intégration de patch désirée, puis on valide l'écran.
L'intégration se fait alors; elle peut être longue si de nombreux fichiers patches sont présents, mais une barre de progression permet de suivre le processus d'intégration.
A la fin de l'intégration des patchs, on obtient un fichier trace qui se situe physiquement dans le répertoire trace du dossier d'où s'est lancée l'intégration. Une visualisation attentive de ce fichier est conseillée pour repérer les erreurs éventuelles.
Fermer
Champs
Les champs suivants sont présents dans cet onglet :
Fichier
|
|
|
|
|
Permet de saisir le répertoire ou le chemin du fichier à intégrer. Si on désire n'intégrer qu'un seul fichier, on tapera le nom de ce fichier (par exemple D:\adonix\patches\P_0048_130.dat). Si on veut intégrer la totalité des patches contenus dans un répertoire, on tapera le chemin du répertoire. Il est à noter que la sélection permet de déplier l'arborescence des fichiers du serveur jusqu'au répertoire concerné. |
Bloc numéro 2
|
Si ce champ n'est pas coché, l'intégration sera simulée. Dans ce cas, l'intégration est tracée mais les transferts ou mise à jour ne sont pas réalisés. |
|
Cette case à cocher est utile si l'on intègre les patchs dans un environnement étranger. Si elle est cochée, le fichier trace du résultat de l'intégration sera en anglais. |
|
Tableau Dossiers
|
Permet de donner la liste des Dossiers sur laquelle l'intégration des patches va être faite; par défaut l'ensemble des dossiers se trouvant dans l'environnement est proposé pour l'intégration des patches, mais il est possible d'en supprimer de la liste. Sauf cas particuliers, il est nécessaire qu'au minimum le dossier superviseur soit patché. |
Fermer
Tâche batch
Cette fonction peut être lancée en batch. La tâche standard PATCH est prévue à cet effet.
L'intégration des listes de patch peut s'effectuer en batch sur 50 dossiers maximum.
Cette option est très intéressante car l'intégration des patchs peut être effectuer la nuit après la sauvegarde alors que l'exploitation n'a pas repris. En effet, l'intégration des patches peut être une opération longue. La consultation du fichier trace pourra alors se faire directement depuis le gestionnaire des requêtes de la tâche batch.
Attention, un patch standard déjà intégré ou qui n'est pas en séquence ne pourra pas être intégré en batch : ce qui n'est qu'un message d'avertissement qui peut être forcé lorsque le patch est intégré directement devient une cause d'arrêt automatique en cas d'exécution batch.
Patch de documentation
L'installation d'un patch de documentation suit le même procédé que celui expliqué ci-dessus et s'applique aux dossiers sélectionnés.
Les fichiers sont définis avec le nom Dy_nnnnn_vvv_ppp.dat, 'y' étant l'abrégé du produit, 'nnnnn' étant le numéro chronologique, 'vvv' la version majeure sur lequel le patch peut s'appliquer, et 'ppp' le code législation.
Il existe un seul fichier par législation qui contient l'ensemble des documentations créées ou modifiées depuis le précédent patch.
Les patchs de documentations sont livrés en même temps que les patchs applicatifs. Ils peuvent être intégrés avant ou après le patch applicatif. Le système vérifie la chronologie des numéros.
L'intégration d'un patch de documentation met à jour le dictionnaire des documentations mais ne touche pas aux documents déposés sur le serveur de documentation. Pour que ces derniers soient mis à jour, il faut lancer une génération de la documentation.
Génération de la documentation
Si vous utilisez le mode d'accès au format compressé (CHM), vous devez avant de lancer la mise à jour des documents automatisés, exécuter une décompression de votre fichier de documentation (cf serveur de documentation).
Si vous utilisez le mode d'accès au format éclaté (HTML), vous pouvez directement lancer la mise à jour.
Mise à jour des documentations automatique
Dans la fonction de documentation, cliquer sur le bouton Génération et saisir les données suivantes selon votre code langue :
N.B : le répertoire est issu du paramètre utilisateur DIRDOC.
Relancer ensuite 3 autres générations avec les mêmes paramètres sauf le type de donnée ou vous indiquerez successivement AML puis ATB puis ATY.
Génération des documents sur le serveur de documentation
Pour faire la mise à jour des documentations sur le serveur de documentation, lancer la génération suivante, selon votre code langue :
Si vous utiliser l'accès à la documentation en mode compressé, vous devez recompresser les fichiers (cf serveur de documentation).
Si vous utiliser l'accès en mode éclaté, la mise à jour est terminée.
Messages d'erreur
Messages d'erreur au lancement de la fonction
Outre les messages génériques, les messages d'erreur suivants peuvent apparaître lors de la saisie :
Pas de patch dans le répertoire
On a indiqué un répertoire vide.
Messages d'erreur dans la trace
Les autres messages d'erreur sont tous affichés dans le fichier trace. Parmi ceux-ci, on trouvera les messages suivants :
Le dossier doit être au moins dans la version nnn
Le patch ne peut pas être appliqué, car la version minimale requise des dossiers n'est pas respectée.
xxxxx : module non implanté dans le dossier
Le patch n'a pas été appliqué sur le dossier, car le module fonctionnel n'est pas utilisé.
Fin de fichier anormale
Structure fichier incorrect
Le fichier de patch est probablement corrompu, le processus d'intégration n'a pas pu relire jusqu'au bout les données correspondantes, ou est tombé sur une structure non conforme.
Gestion de fichier XXX : <<message d'erreur>>
Une erreur de type transactionnelle s'est produite durant la mise à jour du dictionnaire
Erreur en ligne NNN : <<message d'erreur>>
Une erreur s'est produite à l'exécution d'un traitement accompagnant le patch.
Patch plus récent déjà intégré
Il manque des patches, le dernier intégré est ###
Patch normalement inclus dans la version NNN
Ces trois messages concernent la vérification de séquentialité de passage des patches. Normalement, si le patch standard numéro N est le dernier à avoir été passé, on s'attend à ne pas passer un patch plus ancien (message numéro 1), ni de patch de numéro strictement supérieur à N+1 (message numéro 2). Par ailleurs, l'installation d'une version intermédiaire inclut de fait des patches standard qu'il ne faut donc pas intégrer (message numéro 3). En tout état de cause, en mode interactif, ces messages ne sont pas bloquants, et il est possible de continuer quand même, en répondant Oui à la question Voulez-vous continuer malgré les erreurs ?.
Tables mises en oeuvre
Les tables suivantes sont mises en oeuvre par la fonction :
| Table |
Intitulé Table |
|---|---|
|
APATCH [APT] |
Même si une seule table est mentionnée dans les tables mises en œuvre, il faut noter que l'intégration de patches est susceptible de mettre à jour la totalité des tables de la base, et notamment :
- les tables du dictionnaire (celles qui stockent les méta-données associées au progiciel tels les écrans, les fenêtres, les actions…).
- la structure des tables (si une nouvelle description de table est envoyée).
- des données de paramétrage (potentiellement dans n'importe quelle table).
Dans le cadre de la livraison d'une liste de patches standard, il est conseillé de lire les fichiers accompagnant cette livraison : ils décrivent le contenu de la liste.
Il est important de savoir que certains champs des tables du dictionnaire ne sont pas mis à jour lors de l'intégration des patches, parce qu'ils sont considérés comme relevant du paramétrage. On en trouvera le détail dans une documentation annexe.