Règles de pérennisation des développements spécifiques

Introduction

Lorsque des développements spécifiques doivent être réalisés, il convient de s’organiser pour que ceux-ci soient le plus pérennes possibles vis à vis des changements de version. La première partie de ce document détaille les façons de faire.

Indépendamment de ce premier point, une question d’organisation technique des dossiers où les développements sont faits peut également se poser. Cette question est abordée en deuxième partie de la documentation.

Protection des modifications faites

Le progiciel permet d’encapsuler des développements spécifiques au sein d’un standard, notamment en modifiant à un niveau fin certains éléments du standard afin de répondre à des besoins que le standard ne couvre pas.

Afin de faciliter la maintenance de ces spécifiques en les pérennisant tant que faire se peut, un certain nombre de règles doivent être respectées. Ces règles sont au nombre de 5, et sont rappelées ci-dessous. Leur respect permettra de limiter au maximum les problèmes en cas de patch ou de mise à jour.

Mais, avant de commencer il faut savoir qu’il existe des limites incontournables. Quelle que soit la sophistication du système des codes activité, il y a des développements qu’il vaut mieux réaliser par réécriture plutôt que par modification d’un OBJet standard. Ainsi, si un écran a été tellement modifié (en particulier si les blocs ont été modifiés) qu’il n’est plus facile à maintenir par différence avec l’écran standard, il vaut probablement mieux en créer un nouveau. De même, si une fonction standard est modifiée de façon radicale, il vaut probablement mieux réécrire une fonction spécifique, en s’appuyant sur des sous-programmes standards documentés par ADONIX.

C’est un élément à considérer avant tout développement spécifique : vaut-il mieux réécrire ou modifier les éléments fournis par le standard ?

Une fois cette question tranchée au cas par cas, les règles de pérennisation sont les suivantes :

Règle numéro 1 : Ne jamais modifier un source standard

La méconnaissance de cette règle est le meilleur moyen d’obtenir un dossier impossible à maintenir.

En effet, le fait qu’un source standard soit livré ne signifie pas que ce source doive être modifié.Les sources standards livrés le sont à des fins documentaires.

Cette limite n’est pas pour autant une limite très gênante. En effet, dans la plupart des cas, un traitement spécifique dédié est appelé s’il existe. C’est notamment le cas :

 en gestion d’OBJet, à côté du traitement SUBXXX, XXXétant le code de l’OBJet, il existe un traitement SPEXXX pour gérer le spécifique.

 en consultation, à côté du traitement standard (nommé en général CNSXXXSTD, XXX étant le code de la consultation), on peut saisir le nom d’un traitement spécifique (en général CNSXXXSPE).

 dans le dictionnaire des actions, si l’action est de type Traitement standard, et que le nom du traitement commence par SUB, le traitement équivalent commençant par SPE peut aussi être utilisé ; si le nom du traitement (TRAITE par exemple) ne commence pas par SUB, le traitement spécifique associé se nomme XYTRAITE et permet donc de réaliser des spécifiques sans toucher au code d’origine.

 dans le dictionnaire des actions, si l’action est de type Saisie fenêtre, la fenêtre principale s’appelant par exemple FENETRE, un traitement spécifique, de nom XWFENETRE, permet de réaliser des spécifiques sans toucher au code d’origine.

Au delà, si un spécifique nécessite, pour intervenir, la modification d’un traitement standard, la seule manière admissible pour résoudre les problèmes de pérennisation consiste à demander un point d’entrée à l’éditeur ADONIX.

Règle numéro 2 : utiliser strictement les règles de nommage pour tous les éléments rajoutés

Il est impératif, pour éviter des collisions éventuelles avec des versions futures du progiciel, de nommer les éléments ajoutés par des noms commençant par X, Y, ou Z. On entend par élément tout ce qui se trouve dans le tableau suivant :

(*) Une exception est faite pour les fenêtres commençant par O, qui sont associées à un OBJet dont le nom commence par X, Y, ou Z.

Des règles de nommage particulières existent pour certains éléments. En effet :

 des paramètres spécifiques doivent impérativement être ajoutés dans des chapitres dédiés, dont le code doit commencer par X, Y, ou Z.

 des messages spécifiques doivent être impérativement ajoutés dans les chapitres dont le numéro est compris entre 160 et 169.

 les menus locaux spécifiques, et les tables diverses spécifiques, doivent utiliser les plages de numérotation comprises entre 1000 et 1999.

Enfin, le nom des champs ajoutés dans des tables ou écrans standards doivent commencer par X_, Y_, ou Z_.

Règle numéro 3 : protéger par un code activité, mais au niveau le plus fin

Le respect des règles de nommage ne suffit pas à pérenniser des éléments. Il faut aussi les protéger par un code activité commençant par X, Y, ou Z. Mais il est conseillé de protéger uniquement les modifications faites au niveau de détail le plus fin, afin de bénéficier au maximum des évolutions apportées sur les autres éléments d’un élément du progiciel. Ainsi, il est possible de protéger :

 Un écran tout entier, ou une table toute entière. Dans ce cas, toute modification apportée sur l’écran ou sur la table par patch sera ignorée. Ce type de protection n’est à conseiller que pour les nouveaux écrans ou tables, ou en cas de modification totale d’un écran ou d’une table. Il est alors inutile de mettre un code activité spécifique aux niveau du dessous, sauf si on désire se servir d’un code activité pour disposer de variantes dans l’écran ou la table.

 Le bloc d’un écran. Aucune des zones du bloc n’est alors modifiée en cas de patch. Là encore, c’est un niveau assez élevé de protection, puisque toutes les zones du bloc ne sont plus modifiées en cas de patch. Il vaut donc mieux protéger de façon plus fine quand c’est possible. Reste que c’est le seul niveau acceptable si on modifie la mise en place d’un bloc standard, ou si on cherche à rendre configurable à la gestion de dossier le nombre de lignes d’un tableau qui sinon serait fixe.

 La zone d’un écran, ou le champ d’une table, ou l’index d’une table. C’est le niveau à utiliser dans le cas où l’on modifie les caractéristiques d’un champ (format, type, intitulé, longueur…). Ce niveau de protection est très fin, le seul conflit potentiel en cas de patch portant sur les zones protégées.

 Une table liée, un onglet, une liste gauche dans un OBJet (c’est préférable à une protection globale de l’OBJet).

 Une option, une variable associée à une fonction (c’est préférable à une protection globale de la fonction).

Certains éléments ne peuvent pas être protégés de façon détaillée (c’est le cas des états). Dans ce cas, la seule solution est de protéger globalement l’état, en installant le fichier d’extension rpt au niveau du dossier d’exploitation, sachant que l’on pourra aussi décider de le renommer.

Il y a toute une série de cas où les codes activités ne sont pas utiles, notamment sur les champs des écrans :

 Si on veut ajouter un contrôle supplémentaire sur un champ, et que ce contrôle peut être défini par une table de contrôle, il vaut mieux l’implémenter ainsi : il s’agit en effet alors d’un paramétrage qui n’a pas besoin d’être protégé.

 Il en est de même si on veut restreindre l’accès au champ en fonction d’un utilisateur : les affectations de codes d’accès sont du paramétrage.

 De même, si on veut changer globalement les attributs du type de données associé au champ, il vaut mieux modifier le type de données et le protéger par un code activité : la protection du champ est alors inutile.

 Si on veut ajouter des actions dites « spécifiques » (nommées SPE ou SPX), il faut savoir que ces actions restent inchangées en cas de patch, même si le champ n’est pas protégé. Il n’est donc pas utile d’ajouter un code activité sur le champ si d’autres modifications n’ont pas été faites. Si des actions spécifiques imposent d’ouvrir une fenêtre, ces actions doivent être cataloguées dans le dictionnaire des actions. Par ailleurs, dès lors que le code de l’action commence par X, Y, ou Z , elle est protégée de la même façon sans qu’il soit nécessaire de protéger le champ. Il est par contre nécessaire de protéger l’action par un code activité (elle ne sera appelée que si le code est Actif).

 Si on veut supprimer une action standard sur un champ, il est plus simple de la compléter par une action nommée SPX plutôt que de la supprimer (ainsi, la protection par code activité ne sera pas nécessaire sur le champ).

Règle numéro 4 : Attention aux insertions sur des sous-éléments existants

Les insertions de sous-éléments dans un élément ne permettent pas, dans certains cas, une pérennisation. Ceci concerne les cas suivants :

 ajouter un index dans une table standard doit se faire en fin de la liste des index, et surtout pas au début de la liste des index (le premier index est l’index par défaut). Il n’y a pas de restriction par contre sur les champs. Il est par ailleurs recommandé de ne pas les nommer de façon consécutive sous la forme ABVn, ABV étant l’abréviation de la table et n le numéro de ligne (il est en effet possible qu’une évolution du standard nécessite l’ajout d’un index standard).

 les blocs d’un écran ne sont connus que par leur numéro. Ainsi, si l’on désire ajouter un bloc dans un écran, il faut toujours le mettre en fin (quitte à jouer sur les rangs de saisie). Il n’y a pas non plus de restriction sur les champs.

 il en va de même pour les onglets d’une table, les listes de gauche d’un OBJet (en version 140, on différencie l’ordre de leur ordre d’apparition, puisqu’un zone rang existe).

Règle numéro 5: Avant l’installation de tout patch ou de toute version, utiliser le testeur de patch

Cet utilitaire a été réalisé pour permettre de mettre en évidence les conflits potentiels lors de l’installation de patch. En effet, il lit l’en-tête des fichiers de patch présents dans un répertoire donné, et affiche dans une trace la liste des éléments présents dans cette liste et ayant fait l’OBJet de spécifiques. Si la liste en question est vide, il n’y a normalement pas de risque de conflit. Inversement, la liste des éléments en conflit est généralement faible, et il suffit alors d’examiner en détail les quelques éléments qui s’y trouvent.

Lorsqu’une version est installée par le biais d’un CD, on retrouve (dans un répertoire dépendant du progiciel, sur la version 130 d'ADONIX X3 par exemple, on le retrouve dans le répertoire X3Patch\X3V130_technical) une série de répertoires nommés en fonction des versions intermédiaires du logiciel (P131, P132, P133…), qui contiennent des fichiers nommés List_nnn.dat. Ces fichiers contiennent uniquement l’en-tête des éléments contenus dans les patches consécutifs permettant de passer d’une version à une autre. On peut donc utiliser ces fichiers de la même façon par le testeur de patch, afin de s’assurer des conflits potentiels (on partira de la liste suivant la liste courante installée sur le dossier à mettre à jour).

Organisation des dossiers en deux ou troisniveaux

Lors de l’exécution du progiciel, le moteur adonix charge et exécute des fichiers contenant un code intermédiaire (le p-code) indépendant de l’environnement. Ces fichiers peuvent être des programmes, des descriptions d’écran, la description des tables (afin de faire une requête sur la table en question). Ces fichiers sont recherchés dans le dossier en cours d’exécution. Mais si un fichier est inexistant dans le dossier, le moteur adonix va le rechercher dans le dossier mère, puis dans le dossier grand-mère… Le moteur adonix est ainsi susceptible de remonter une hiérarchie de 8 dossiers successifs, mais pour des raisons pratiques, on se limite à 3 niveaux (la gestion de dossiers n’en gère que 3).

La conséquence de cette structure est la suivante : un dossier utilisateur créé sous le progiciel va dépendre soit du dossier superviseur, soit d’un dossier dépendant lui-même du dossier superviseur. En effet, si ce n’est pas le cas, des éléments indispensables au fonctionnement du dossier et de son paramétrage, qui ne sont présents que dans le dossier superviseur, ne seraient plus accessibles. Les deux schémas possibles pour un dossier d’exploitation sont donc les suivants :

Le dossier de référence intermédiaire est en général appelé dossier de développement, parce que l’une des implémentations possibles des hiérarchies de dossiers consiste à y implanter les développements spécifiques.

La hiérarchie à 3 niveaux est lourde à maintenir. En effet, l’existence de cette hiérarchie à trois niveaux a des conséquences pratiques : transférer un dossier d’exploitation d’un serveur à un autre suppose, pour que le dossier transféré puisse fonctionner, que la hiérarchie ait aussi été transférée. Dans le cas d’une hiérarchie à deux niveaux, pas de problèmes, puisque le dossier superviseur est forcément présent dans un environnement où le progiciel est installé. Par contre, dans le cas d’une hiérarchie à 3 niveaux, il faut également transférer le dossier de développement.

Par ailleurs, le principe d’héritage, s’il permet de transférer simplement des développements faits par revalidation du dossier d’exploitation, présente quand même des effets pervers, dans la mesure où l’héritage est immédiat si on modifie un traitement dans le dossier de développement… mais différé pour tous les éléments du dictionnaire, qui ne seront transférés qu’en cas de revalidation. On risque donc de se retrouver avec des incohérences temporaires dans le dossier d’exploitation, dès lors que l’on travaille au fil de l’eau dans un dossier de développement.

Cette hiérarchie n’est donc recommandée que dans les cas suivants :

 le client final veut développer ses propres spécifiques, et on souhaite qu’il le fasse de façon bien isolée dans le dossier d’exploitation ; en sachant que par ailleurs que l’on désire des développements faits par un partenaire ADONIX dans le dossier intermédiaire.

 on se trouve dans un environnement de développement de verticaux, et on souhaite utiliser des dossiers d’exploitation à fins de test.

Dans tous les autres cas, il est recommandé d’utiliser une hiérarchie à deux niveaux. Il convient, dans ce cas, d’utiliser un dossier de test à côté du dossier d’exploitation, si on désire réaliser des développements en cours d’exploitation et les tester avant de les implanter (par copie ou patch) dans le dossier d’exploitation. L’utilisation de la fonction de patch est souvent préférable : elle permet en effet de créer des « packages » applicatifs depuis le dossier de développement, et de les intégrer d’un bloc dans le dossier d’exploitation. En outre, la version 130 intègre une nouvelle fonction de création d’un patch incrémental. On peut en effet créer un patch contenant tout ce qui a été modifié sur un dossier depuis une date donnée. Ceci permet très facilement d’isoler les développements et paramétrages réalisés entre deux étapes d’un déploiement.

On trouvera plus d’informations sur le sujet dans la documentation associée à la gestion de dossiers.