patches et spécifiques > - logtimiz...une remarque importante est à faire : quand on parle de...

Patches et spécifiques > Principes de base

Sage X3 V 6

Date : August 26, 2009 Writer : Dominique Bopp Distribution : Public

2 / 33 Livre blanc spécifiques et verticaux.doc - document indicatif fourni sans engagement ni garantie -

Sommaire

Sommaire .................................................................................................................................... 2

Introduction ................................................................................................................................ 4

Principes de base ...................................................................................................................... 5

Développements spécifiques .................................................................................................. 5

Développements verticaux ...................................................................................................... 5

Ce que peuvent inclure des spécifiques ou verticaux ........................................................... 5

Codes activité ........................................................................................................................... 6

Utilisation du code activité ....................................................................................................... 7

Gestion des textes du dictionnaire (ATEXTE) ....................................................................... 7

Gestion des menus locaux et messages (APLSTD) ............................................................. 8

Conflits potentiels de points d’entrée ...................................................................................... 9

Documentation spécifique ....................................................................................................... 9

Comment réaliser un développement spécifique ............................................................. 10

Principes de base ................................................................................................................... 10

Règles de dénomination ........................................................................................................ 11

Protection par code activité ................................................................................................... 11

Comment faire évoluer un développement spécifique ou vertical ................................ 12

Mise à jour d’une version ....................................................................................................... 12

Le testeur de patch ................................................................................................................ 12

La livraison d’un spécifique sur une version donnée ........................................................... 13

La livraison d’un vertical sur une version donnée ................................................................ 13

Procédure pratique pour la gestion d’un environnement d’exploitation sur lequel des spécifiques sont installés ...................................................................................................... 14

Organisations préconisées pour les environnements clients .............................................. 14

Architecture à deux niveaux ......................................................................................... 14 Architecture à trois niveaux ......................................................................................... 15

Procédure d’installation d’un patch standard ....................................................................... 16

Procédure d’installation d’un patch standard ....................................................................... 17

Procédure d’installation d’une nouvelle version mineure .................................................... 21

Quel environnement préconiser pour gérer des développements verticaux .............. 22

L’environnement de développement .................................................................................... 22

La procédure d’extraction pour livraison ............................................................................... 22

Les environnements de maintenance et de support ........................................................... 23

Les erreurs à ne pas commettre (pour les spécifiques comme pour les verticaux) .. 24

Oublier de protéger un champ commençant par X, Y ou Z ................................................ 24

Modifier des traitements standards ....................................................................................... 24

Ne pas vérifier ses valeurs de code activité ......................................................................... 24

Bien faire attention à la valeur des codes activités livrés .................................................... 24

Multiplier les « petits » spécifiques partout ........................................................................... 24

Protéger trop globalement un élément ................................................................................. 25

Ne pas tester ses spécifiques après une mise à jour .......................................................... 25

Ne pas gérer correctement les actions sur champ SPE ou SPV ....................................... 25

Patcher des écrans générés par des transactions .............................................................. 25


Annexes .................................................................................................................................... 26

Sous-programme de recherche d’un texte dans un écran.................................................. 26

Gestion d’un traitement vertical de point d’entrée pour permettre un chaînage ................ 27

Normes de numérotation et de dénomination ...................................................................... 29

Codes activités ........................................................................................................... 29 Champs, écrans, objets ............................................................................................... 29 Messages (ATEXTE) .................................................................................................... 29 Menus locaux et chapitres de messages ........................................................................ 29 Tables diverses ........................................................................................................... 29

Sous-programme de protection d’un vertical ....................................................................... 30


Introduction

Ce document présente un certain nombre de conseils pour faciliter la mise en œuvre et la pérennisation des verticaux et spécifiques. Il présente l’état de l’art de la version V6 (version dont le nom de code est Béryl), mais s’applique également (sauf exceptions signalées) pour la version V5.

Il préconise des implémentations pour des environnements destinés à permettre le développement, la maintenance, et le suivi d’un développement vertical, et propose également des implémentations chez des clients. Ces implémentations, destinées à assurer un suivi rigoureux des évolutions, peuvent être allégées lorsque le projet n’est pas complexe.

Il faut noter que le fait de suivre ces conseils permet de faciliter notablement la mise en œuvre de spécifiques lorsqu’un vertical est installé. Il ne prétend pas proposer une méthodologie de cohabitation entre verticaux, ce qui est plus complexe, et nécessite une coordination entre deux créateurs de verticaux, dans la mesure où :

� les verticaux sont potentiellement créés par des fournisseurs différents

� ils modifient souvent des éléments communs (notamment des tables de base)

� que rien ne garantit que les règles fonctionnelles qu’ils implémentent en plus ne sont pas incompatibles entre elles

� qu’on ne peut garantir des règles de dénomination empêchant tout conflit entre eux.

Pour résoudre ces problèmes de cohabitation, Sage peut, sur demande d’un partenaire, attribuer des plages de codification dédiées. Ceci permet de garantir au partenaire que tout autre partenaire ayant demandé une plage de codification d’éviter tout conflit.

Une remarque importante est à faire : quand on parle de technologie X3, cette technologie concerne un ensemble de produits (paye, ERP, gestion d’entrepôt, immobilisations). Il ne faut donc pas le prendre dans l’acception réductrice de « ERP Sage X3 ». De même, lorsqu’on parle du dossier "X3", il s’agit du dossier racine du progiciel. Selon les produits, il s’appelle X3, GX, PAIE, ou ABELX3.

Ce document présente des préconisations et des propositions de mise en œuvre. Ces préconisations sont fournies à titre indicatif, sans aucun engagement ni aucune garantie de quelque sorte de la part de Sage, et sont susceptibles d’évoluer sans préavis.


Principes de base

Développements spécifiques

Un développement spécifique est défini comme étant :

� Un ensemble d’éléments techniques (ie. du code et des données), usuellement fournis dans un format de fichier particulier nommé patch.

� Permettant de répondre à un besoin fonctionnel.

� Défini de telle façon qu’il puisse être installé de façon pérenne dans un environnement donné.

� Installable de façon autonome dans un environnement donné (ie. à un niveau de version donné).

Développements verticaux

Un développement vertical est un développement spécifique qui a vocation à être installé chez un ensemble de clients. En soi, il n’y a pas de différence fondamentale entre les deux. Mais comme on part du principe que l’objectif d’un développement vertical est d’être partagé, et d’être packagé pour pouvoir être facilement installé en plusieurs exemplaires, on utilisera des normes de développement un peu différentes (règles pour nommer les éléments) et on dispose dans le dictionnaire, d’informations spécifiques marquées comme verticales, afin de permettre une cohabitation entre spécifique et vertical. De même, les principes de déploiement pourront être différents, surtout si on désire gérer de façon rigoureuse la cohabitation entre vertical et spécifique.

Par ailleurs, une large diffusion suppose la mise en œuvre d’un suivi rigoureux des maintenances du vertical et de leur synchronisation avec les versions standard, afin d’en permettre une diffusion large à l’instar de ce qui est fait pour les maintenances standard.

Ce que peuvent inclure des spécifiques ou verticaux

De façon plus précise, un développement spécifique ou vertical est composé :

� d’éléments autonomes du dictionnaire (ie. entièrement spécifiques ou verticaux) : tables, écrans, fenêtres, actions, objets, tables diverses, fonction, menus locaux, paramètres, dictionnaire d’états…).

� d’éléments standard du dictionnaire modifiés notamment par l’ajout de champs dans des tables ou des écrans, d’onglets dans des fenêtres, d’actions sur des champs standard d’écrans...

� d’éventuels éléments de paramétrage (tables diverses, modèles d’import-export, données dans des tables).

� de documentations stockées dans la base de données.

� de fichiers de code (fournis sous forme de source ou d’exécutables). Ceci inclut les traitements adonix, les états Crystal Reports. Les traitements spécifiques fournis peuvent être autonomes, ou être


appelés en complément d’un traitement standard à partir de fonctions dont le comportement va ainsi se trouver modifié.

Deux grands types de traitements existent :

• ceux associés à un modèle standard (objet, par exemple). Leur code est appelé automatiquement par l’intermédiaire du modèle. Le nom du traitement utilisé est défini dans le dictionnaire (nom de traitement spécifique ou vertical dans le dictionnaire des objets, des actions, des écrans, des états…)

• ceux qui sont appelés par des branchements standard nommés points d’entrée. Ils permettent d’intervenir dans un contexte d’exécution décrit par une documentation technique, pour en modifier le comportement. Une table de routage associe le traitement standard au traitement dans lequel se trouve le point d’entrée.

Un vertical ou spécifique peut aussi appeler des exécutables (.exe, OCX, DLL) réalisés dans des technologies autres, installés sur le client et/ou le serveur. La diffusion à l’intérieur de ce type d’élément à l’intérieur d’un patch standard n’est pas prévue, il faut donc créer des procédures d’installation dédiées.

Codes activité

Un code activité est un code de 5 caractères permettant de marquer des éléments dans le dictionnaire de Sage X3. En configurant le dossier, on peut :

� activer ou désactiver le code activité

� lui donner une valeur numérique

La valeur d’un code activité est saisie directement en gestion de dossier, ou évaluée par calcul à partir de valeurs d’autres codes activité.

Ceci permet de définir des variantes dans le dictionnaire : les champs, onglets, éléments marqués par un code activité Inactif ne sont pas exécutés ou pas visibles dans le dossier.

Cette notion est utilisée en standard pour disposer de variantes fonctionnelles (ex : utilisation d’une localisation ou d’une fonctionnalité avancée), pour dimensionner des tableaux dans des écrans. Mais le cas d’emploi le plus important concerne le marquage d’un spécifique par un code activité. La règle est alors de créer ces codes activités en les faisant commencer par X, Y, ou Z. Cette règle est testée explicitement dans le superviseur, assurant la protection du code ou des éléments concernés : quand un patch standard est installé, les éléments ainsi marqués sont protégés. En cas de revalidation de dossier, il en va de même. Une norme a été créée à partir de la V5 pour différencier plus clairement les verticaux des spécifiques. Cette norme est la suivante :

� un code activité commençant par X protège des développements verticaux réalisés par un partenaire Sage X3.

� un code activité commençant par Y protège des développements spécifiques faits par un partenaire Sage X3 chez des clients finaux.

� un code activité commençant par Z protège des développements spécifiques faits par un client final pour ses propres besoins.

Outre la protection des éléments marqués vis à vis d’un patch standard, elle permet aussi de définir un critère pour une extraction d’un développement sous forme d’un fichier de patch. Bien entendu, un code activité de ce type


permet d’activer ou de désactiver des éléments, y compris des éléments standard jusque là.

Utilisation du code activité

La protection des éléments par un code activité vertical ou spécifique (commençant par X, Y ou Z) doit se faire au niveau le plus fin possible, ce afin de faciliter les processus de mise à jour en protégeant l’élément marqué vis à vis d’un patch standard. Ainsi :

� un écran ou une fenêtre entièrement spécifique portera ce code activité en tête.

� un onglet spécifique dans une fenêtre standard portera le code activité au niveau de la ligne définissant les onglets.

� un bloc entièrement spécifique dans un écran standard portera le code activité au niveau de la ligne définissant les blocs.

� un champ entièrement spécifique (dans un écran, une table…) portera le code activité au niveau du champ.

� une action spécifique ou verticale définie au niveau d’un champ standard ne porte pas de code activité. Elle peut être définie comme :

o une action générique (SPE si spécifique, SPV si elle est verticale)

o une action verticale (respectivement spécifique) réutilisable, définie dans le dictionnaire des actions, et dont le code commence par X (respectivement Y ou Z).

On peut donner quelques exemples particuliers :

� pour des raisons de cohérence, un champ standard dans un écran standard ne doit jamais être supprimé. Pour inhiber un champ standard, le plus simple est de mettre en place, sur ce champ, un code activité spécifique ou vertical, dont la valeur est définie par la formule de dépendance FAL (code activité standard « toujours faux »).

� pour rendre spécifique ou vertical un champ standard qui est déjà marqué par un code activité standard (par exemple un code de dimensionnement), le plus simple est de définir un code activité spécifique ou vertical, dépendant directement du code activité standard (donc prenant la même valeur). Ainsi, si on modifie des attributs de ce champ, ils seront respectés lors de l’application d’un patch standard ; si on modifie les valeurs du code de dimensionnement, par exemple pour augmenter le nombre de lignes d’un tableau, la valeur associée au code activité spécifique sera réévaluée.

Gestion des textes du dictionnaire (ATEXTE)

Dans l’environnement Sage X3, tout texte associé à un élément du dictionnaire est stocké dans la table ATEXTE ; il est identifié par un numéro unique qui est utilisé par tous les éléments du dictionnaire faisant référence à ce texte. Ainsi, les intitulés des champs dans les écrans et dans les tables, les intitulés des onglets, des boutons sont stockés sous la forme d’un nombre faisant référence à ATEXTE. C’est ce principe de fonctionnement qui permet de garantir la traduction des progiciels en technologie X3 par simple traduction de la table correspondante.


Il faut noter que le numéro attribué est en principe fixe pour les éléments standard dans un progiciel donné, et défini dans une plage de numérotation donnée. Mais dans le cas d’un spécifique, il n’est pas fixe, car l’attribution se fait à la volée au moment de la création du texte, dans une autre plage de numérotation. Or rien n’interdit de livrer par patch un développement spécifique donné, réalisé dans un environnement donné, avec des numéros de texte attribués dans cet environnement. A l’installation du patch, il n’est pas exclu que l’environnement d’arrivée ait déjà utilisé cette plage de numérotation.

Pour gérer cette problématique :

� le fichier de patch contient à la fois le numéro du texte et le texte lui-même (dans toutes les langues livrées dans le patch).

� à l’installation, le numéro de texte est respecté si le texte n’existe pas encore dans la table ATEXTE du dossier d’arrivée, ou si le texte est déjà présent et identique.

� si ce n’est pas le cas, le texte est re-numéroté à la volée et créé ailleurs

Ceci permet de gérer les textes spécifiques de façon entièrement transparente pour le développeur, dès lors qu’il utilise la procédure de patch pour livrer des éléments développés. Mais cela signifie aussi qu’il ne faut en aucun cas faire référence à un numéro de texte ailleurs que dans un élément du dictionnaire gérant des textes (type de données ATX). Notamment, utiliser un numéro de texte dans un traitement pour faire référence à un texte donné est prohibé. Si on veut impérativement faire référence à un texte que l’on sait présent dans un élément du dictionnaire, il faudra relire l’élément en question. On trouvera en annexe un exemple de fonction permettant de rechercher un tel texte.

� en version 5 ou 6, les textes standards sont numérotés de 1 à 99.999 (en version 140, on allait jusqu’à 49.999). Au delà, les numéros sont réservés aux spécifiques et verticaux.

� quand on crée un développement spécifique, les textes sont automatiquement attribués dans une plage située au delà de celle réservée aux textes standards. Cette plage, commence donc à 100.000 en V5 et V6 (c’était 50.000 en version 140). Lorsqu’on revalide un dossier 140 pour passer en V5 ou en V6, la renumérotation des textes spécifiques est faite automatiquement.

Gestion des menus locaux et messages (APLSTD)

Lorsqu’on utilise des champs saisis dans des combo-boxes ou via des boutons radio, les intitulés doivent également pouvoir être traduits. On définit les boutons radios et les combo-boxes par une référence à un menu local (chaque menu local est identifié par un numéro fixe).

De même, on a besoin de pouvoir, pour des messages de service ou d’erreur, disposer d’une référence fixe utilisables dans des traitements.

Ceci est assuré par une deuxième table de textes, la table APLSTD. Cette table est organisée en chapitres, et chaque chapitre contient 1 à N messages. Un chapitre peut contenir soit un menu local, soit une suite de messages dont la caractéristique est d’avoir un numéro fixe (contrairement à ATEXTE). Le fait que ce soit un message ou un menu local est défini au niveau du dictionnaire. Lorsque le chapitre est un menu local, on définit aussi au niveau du dictionnaire s’il est modifiable ou pas.


l’utilisation pratique d’un menu local se fait dans les écrans, en donnant le bon numéro. Par exemple, le menu local numéro 1 contient les choix Non (choix numéro 1) et Oui (choix numéro 2).

la visualisation d’un choix de menu local, hormis le cas où il est présent sur un écran, peut se faire par la formule suivante :

� mess(I,M,1) donne le message numéro I du menu local numéro M dans langue de connexion. Ainsi, mess(2,1,1) renverra "Oui" pour un utilisateur connecté en français.

APLSTD stockant des menus locaux ou des messages, on a réservé certaines plages de numérotation aux messages (par exemple les messages d’erreur).

Pour éviter les conflits avec le standard, certaines plages de numéros sont réservées aux verticaux et aux spécifiques. Elles ont été étendues en V5. Il faut donc prendre garde à les utiliser. On retrouvera en annexe un récapitulatif des différentes normes de numérotation et de dénomination.

Il faut noter que la limite technique de la longueur d’un message de APLSTD est de 123 caractères, ce qui est en principe amplement suffisant pour des menus locaux. Pour des messages, il est toujours possible de gérer plusieurs messages et de les concaténer dans un traitement.

Conflits potentiels de points d’entrée

L’appel d’un point d’entrée par un spécifique se fait via une table qui associe à un traitement standard un et un seul traitement spécifique. Une fois qu’un traitement est utilisé par un vertical, il est donc impossible d’en ajouter un second dans le cadre d’un spécifique. Pour gérer ce cas, une zone supplémentaire a été rajoutée dans la table des points d’entrée. Cette zone, nommée TRTPAR et intitulée paramétrage, peut être structurée pour rajouter des noms de traitements complémentaires à appeler en séquence. On trouvera en annexe une proposition de norme, et un exemple de code à insérer dans le point d’entrée principal pour que le chaînage vers les points d’entrée secondaires puisse être correctement fait.

Documentation spécifique

Les versions 5 et 6 intègrent un outil de documentation qui permet :

� de créer de nouvelles documentations associées à des fonctions, paramètres, actions… spécifiques.

� d’ajouter voire de modifier des paragraphes à des documentations existantes, en les marquant comme spécifiques.

� de livrer par patch des documentations.

La structure de la documentation est stockée dans le dossier X3, et propagée dans tout dossier situé en dessous. Les textes sont stockés uniquement dans le dossier X3, mais des textes spécifiques peuvent être ajoutés dans les dossiers où la documentation spécifique est réalisée.

Il est de même possible de gérer des documentations spécifiques sur champs, à condition de créer des mots-clés commençant par X, Y, ou Z. Dans ce cas particulier, la règle de dénomination suffit à pérenniser les documentations sur champ et l’affectation qui en est faite dans les écrans.


Comment réaliser un développement spécifique

Principes de base

Un développement est considéré comme pérenne si les modifications qu’il comporte, une fois installées dans un dossier donné, ne sont pas altérées lorsqu’un patch standard ou une nouvelle version est installée. Ceci ne signifie pas pour autant que le spécifique va continuer de fonctionner !

En effet, il est possible (par exemple) que les données qu’il manipule, qui peuvent être des données standard, soient complétées, au détour d’une version, de nouvelles informations obligatoires que le spécifique ne renseigne pas…

Ainsi donc, la pérennisation du spécifique ne dispense pas d’un test de son fonctionnement (notamment dès lors que des structures de données standard mises à jour directement par le spécifique sont concernées).

Pour qu’un spécifique soit inaltérable, il faut que trois conditions soient remplies :

� les éléments définis ne doivent pas entrer en conflit avec de nouveaux éléments susceptibles d’être livrés en standard. Ceci impose des règles de dénomination.

� les éléments spécifiques définis, tout comme les modifications spécifiques faites sur le standard, doivent être marquées par un code activité spécifique, et ce, au niveau de détail approprié.

� les traitements standard, même s’ils sont livrés en source, ne doivent jamais être modifiés. La technique de point d’entrée permet d’écrire dans un traitement complémentaire qui ne sera jamais altéré par un patch. Ce traitement complémentaire est susceptible d’être exécuté avant, après, ou en remplacement du code standard dans le cas d’actions sur les champs d’un écran (positionnement du code SPE, indicateur de désactivation d’un code standard et/ou vertical). Dans le cas de points d’entrée, une variable en retour (GPE) dont la valeur peut être testée dans le cadre du point d’entrée permet de désactiver le fonctionnement standard ou de le compléter, selon les cas.


Règles de dénomination

Un élément spécifique doit avoir un nom qui commence par Y ou Z. On entend par élément spécifique un élément qui peut être patché séparément : un type de données, une table, un écran, une fenêtre, un objet, une action, un traitement… A cette règle, il faut noter deux exceptions : sont considérés comme spécifiques les traitements dont le nom commence par SPE, et ceux dont le nom commence par CNS et se termine par SPE (il s’agit de traitements normalisés attachés aux actions spécifiques objet et consultation).

Un sous-élément d’un élément spécifique n’a pas besoin de suivre ces règles de dénomination (par exemple un champ dans un écran ou dans une table). En effet, on peut avoir intérêt à utiliser des codes correspondants à des champs standard, dans le but de faciliter des affectations de classe à classe.

Certains champs techniques servant à l’affichage d’intitulés commençant par Z peuvent exister dans des écrans standard. Pour éviter des conflits, on peut utiliser, dans les écrans standard modifiés en spécifique, des champs préfixés par Z_ pour les champs.

Protection par code activité

Le fait de respecter les règles de dénomination ne suffit pas à pérenniser un spécifique. Il faut en plus que chaque élément du dictionnaire à protéger soit marqué par un code activité spécifique.

Notons qu’il y a trois exceptions :

� la première relative aux actions sur champs commençant par SP, X, Y, ou Z (le code activité n’est pas nécessaire sur le champ si aucune autre modification n’est faite).

� la seconde correspond aux traitements. On ne peut pas associer un code activité à un traitement (source ou compilé). En effet, le code activité qui existe dans le dictionnaire des traitements est purement indicatif : désactiver ce code ne désactive pas l’exécution du code du traitement. Le simple fait que le traitement soit correctement nommé suffit à le protéger.

� La troisième correspond à des actions standard pour lesquelles un traitement spécifique a été associé. Si le nom du traitement spécifique n’est pas modifié par rapport à ce qui est proposé, (XYtrtstd, où trtstd est le nom du traitement standard, SPExxx ou rien selon les cas), il n’est pas utile de protéger l’action (mais il faut livrer le traitement spécifique en question). Aussi il est recommandé de ne pas modifier ce nom, quitte, si un traitement de ce type est partagé par plusieurs actions, à ne mettre qu’un appel à un autre sous-programme dans ce traitement spécifique normalisé.

Rappelons que la protection doit être faite au plus bas niveau possible. L’intérêt de cette protection au plus bas niveau réside dans la possibilité de continuer à mettre à jour les sous-éléments standard d’un élément modifié partiellement. Ainsi, par exemple, le rajout d’un champ spécifique sur un écran standard n’altère pas les possibilités d’évolution des autres champs standard de l’écran, si le code activité est porté par le champ spécifique. S’il est porté par l’écran tout entier, l’écran sera protégé en cas de mise à jour standard, et donc les évolutions sur des champs restés standards ne seront pas faites.


Comment faire évoluer un développement spécifique ou vertical

Mise à jour d’une version

Un développement spécifique ou vertical réalisé dans les règles, installé dans un environnement donné, peut évoluer par montée de version standard (soit par installation de patchs, soit par installation d’une nouvelle version) :

� dès lors qu’ils sont correctement nommés, les éléments totalement spécifiques ne sont jamais écrasés par un élément standard. Il doivent normalement fonctionner, mais s’ils mettent à jour directement des tables du standard, il peut y avoir des points d’incompatibilité à vérifier. S’ils passent par des sous-programmes standard, il ne doit normalement pas y avoir de problème.

� les éléments totalement standard seront mis à jour normalement (ce qui ne doit pas poser de problème).

� les éléments standard modifiés, s’ils sont protégés au plus haut niveau, ne sont pas modifiés par le patch. Ceci peut empêcher leur fonctionnement si des modifications auraient dû y être apportées (mais on n’aura rien perdu des éléments spécifiques).

� les éléments standard modifiés et protégés partiellement vont subir les modifications, s’il y en a, sur des sous-éléments non protégés (ce qui là encore peut poser des problèmes de fonctionnement).

En résumé, les conflits potentiels liés à la mise à jour d’une version proviennent essentiellement d’éléments du standard modifiés en spécifique ou en vertical, pour lesquels une évolution standard est livrée. Ces conflits ne sont pas forcément très complexes à résoudre, mais il est impératif de les détecter, de les puis analyser, pour pouvoir faire des tests pertinents.

Le testeur de patch

Cet outil permet de lire un patch ou une série de patchs, afin de lister les éléments inclus dans le patch. Pour chaque élément, une vérification est faite pour savoir si des modifications spécifiques ont été faites dans le dossier en cours de test. Si c’est le cas, un conflit potentiel existe, il est affiché dans la trace détaillée. La personne en charge de mettre les patchs en place peut alors mener des tests sélectifs sur les points potentiels de conflit.

Il est à noter que le testeur de patch ne sait pas distinguer ce qui a changé entre la version précédente et la version patchée ; il s’intéresse simplement au fait qu’il y a du spécifique sur un élément patché, et ne lit en réalité que la « table des matières » du patch pour savoir ce qui est livré.

Il est important de noter que, sur le CD d’une version mineure, on livre un pseudo-fichier de patch ne contenant que la liste des éléments modifiés depuis la précédente version mineure. Le testeur de patch peut donc aussi être utilisé dans ce cas.


La livraison d’un spécifique sur une version donnée

Si un client est dans une version X.Y donnée, et que l’on désire lui installer un spécifique par patch, il importe, si ce spécifique intègre des éléments standard modifiés, que ces éléments aient été extraits d’un environnement de développement dans la même version. Ceci signifie qu’il faut maintenir un spécifique livré chez plusieurs clients dans toutes les versions que les clients utilisent (y compris les niveaux de patch).

Il doit notamment être clair qu’on ne sait pas faire de patch « delta », c’est-à-dire par exemple un patch qui ajouterait un champ sur une table (ie. qui pourrait l’ajouter, dans deux versions différentes de la table, indépendamment de la structure d’origine qui pourrait être différente) ; en fait, le patch décrit la totalité de la structure de la table (il en respecte le contenu…).

La version 5 permet de typer les fichiers de patch. On utilisera donc un patch typé spécifique pour livrer un spécifique (ce qui permet notamment de supprimer par patch une action spécifique, ou de modifier le nom du traitement spécifique associé aux actions, écrans, objets).

La livraison d’un vertical sur une version donnée

Le principe est le même pour mettre à jour un vertical. Il faudra installer des fichiers de patch typés verticaux. On verra dans la suite que la préconisation faite pour l’environnement de développement d’un vertical a des incidences sur la façon dont ces patchs sont gérés.


Procédure pratique pour la gestion d’un environnement d’exploitation sur lequel des spécifiques sont installés

Organisations préconisées pour les environnements clients

L’architecture Sage X3 peut être de deux types différents :

� soit une architecture à 3 niveaux, où l’on retrouve, sous le dossier de référence X3, un dossier « vertical », et encore en dessous un dossier d’exploitation. Cette architecture est recommandée si l’on désire gérer un environnement dédié au développement et à la maintenance de verticaux. Du point de vue de l’exploitation, elle est lourde à maintenir et n’est pas recommandée sur un site en exploitation – même si elle fonctionne techniquement. Elle peut par contre être mise en œuvre lorsqu’un client souhaite avoir un environnement de test et de certification dédié. Cette architecture permet de distinguer les environnements et les développements faits.

� Soit une architecture à 2 niveaux, qui est plus adaptée à des dossiers d’exploitation, surtout si seul un vertical ou un spécifique est installé.

Ces deux architectures sont détaillées ci-dessous.

Architecture à deux niveaux

Dans ce type d’architecture, il est recommandé de disposer d’au minimum quatre dossiers :

� un dossier de test, nommé par exemple TESTSPE, ie. un dossier intégrant tous les spécifiques et pour lequel la case Dossier test est cochée. Ceci permet de déclencher la procédure de patch sur ce dossier indépendamment des autres.

� deux dossiers standards (par exemple ici le dossier de démo DEMO, et une copie DEMOTEST, dont on aura coché la case Test en gestion de dossier, pour pouvoir le patcher indépendamment des autres).

� le dossier d’exploitation que l’on nommera EXPLOIT.


Cette disposition permet de tester de façon sécurisée toute installation de patch avant de la mettre en production. Si on désire sécuriser de la même façon toute installation de version intermédiaire, on disposera ces deux jeux de dossiers dans des environnements X3 différents (dénommés solutions dans la terminologie habituelle utilisée par la console), comme le montre le schéma ci-dessous qui résume l’organisation recommandée :

(**) Le dossier "X3" en question est soit le même que le premier (cas où un seul environnement est installé, pour sécuriser l’installation de patchs), soit un dossier différent avec le même contenu (si on a deux environnements, ce qui est utile si on veut pouvoir installer des versions intermédiaires avec le même niveau de test chez le client).

Architecture à trois niveaux

Ce type d’architecture distingue :

� le dossier X3 standard

� le dossier vertical, situé sous X3, et sous lequel on retrouve le dossier d’exploitation et un dossier de test permettant de tester les spécifiques faits par le client par dessus les verticaux.

� Un dossier de démo standard, situé au même niveau que le dossier vertical.

� Eventuellement un dossier de test des verticaux, et de test des patches standard dans un environnement dédié. Normalement, si le partenaire est dans une logique de verticalisation, ces deux dossiers ne sont pas gérés chez le client lui-même, mais chez le partenaire.

EXPLOIT (dossier

d’exploitation client)

DEMO (dossier

standard de démonstration)

TESTSPE (dossier de test

des spécifiques)

DEMOTEST (dossier de test des patches)

Dossier de

référence "X3"

Dossier de référence

"X3" (*)


Le schéma est alors celui-ci :

VERTICAL (dossier où le vertical et le spécifique partenaire

sont installés)

VERTITEST (dossier de

développement et de test des verticaux et

spécifiques partenaire)

DEMOTEST (dossier de test des patches)

Dossier de

référence "X3"

Dossier de référence

"X3" (*)

EXPLOIT (dossier

d’exploitation client)

DEMO (dossier

standard de démonstration)

EXPLOITST (dossier de test des spécifiques

client)

Environnement

(« solution »)

d’exploitation

Environnement

(« solution ») de

développement


Procédure d’installation d’un patch standard

Les principes de base de la procédure d’installation des patchs restent les mêmes dans un environnement à deux ou trois niveaux. La seule différence consiste dans le fait qu’on a deux étapes avec 3 niveaux, et une seule étape avec deux :

� Etape 1, uniquement dans le cas d’une structure à 3 niveaux : on commencera par valider le fonctionnement du vertical par rapport au standard, ce qui pourra amener à fournir un patch vertical complémentaire (ce test n’étant pas fait en principe dans l’environnement du client final). Puis on analysera l’impact sur le spécifique éventuel (Etape 2).

� Etape 2, dans la structure à 3 niveaux : on valide le fonctionnement du spécifique, le vertical étant l’environnement de référence (dossier VERTICAL). Cette validation est faite en général sur le site du client dans un environnement de test dédié.

� Etape unique dans le cas d’une structure à deux niveaux : on valide le fonctionnement du spécifique, le standard étant l’environnement de référence (dossier X3).

Lorsqu’un patch est livré pour être installé dans des environnements d’exploitation ou de test, il faut lire avant toute chose le fichier d’information qui donne le détail des corrections apportées par une liste de patch. Cela permettra de voir où il faut focaliser les tests. Un point est tout particulièrement à noter : si un patch livre un nouveau code activité, il faut vérifier avec quelle valeur (actif ou inactif) il est livré par défaut, et penser à modifier sa valeur après installation si on désire que ce ne soit pas cette valeur qui soit retenue dans le dossier. La valeur du code activité n’est fixée par le patch que si le code activité n’existait pas au préalable dans le dossier (sinon, on ne touche pas à sa valeur).

Cette lecture faite, il faudra déposer les fichiers correspondants dans un répertoire et lancer le testeur de patch depuis le dossier de test.

Le résultat de cette opération va être une liste de points de conflits potentiels (un écran présent dans le patch sur lequel se trouve un spécifique, par exemple).

Si aucun conflit n’est signalé, on installe le patch dans le dossier de test, puis on fait des tests minimaux. Si l’interaction entre les modifications spécifiques et le éléments patchés est nulle, les régressions éventuelles ne viendront pas du spécifique lui-même.

Si des conflits existent, l’installation du patch peut provoquer des dysfonctionnements dans les éléments correspondants. Il est donc recommandé dans ce cas, pour chacun des éléments signalés comme susceptibles de poser des problèmes, de suivre une procédure de vérification en deux étapes (avant installation, après installation). Cette procédure est détaillée dans les tableaux ci-dessous.


PROCEDURE DE PATCH STANDARD DANS LE CAS D’UN VERTICAL : Mise à jour du dossier vertical, création du patch complémentaire

ETAPE DOSSIER 1 DOSSIER 2 Opération

Vérifications préliminaires

VERTITEST VERTICAL Comparaison de dictionnaire pour vérifier que l’on part bien du même état


VERTITEST DEMOTEST Comparaison de dictionnaire pour s’assurer que tous les développements sont bien référencés


VERTITEST Utilisation du testeur de patch pour identifier les conflits potentiels

Patch de l’environnement standard et vertical

VERTITEST DEMOTEST Passage des patchs

Test des fonctions VERTITEST DEMOTEST Vérifier le fonctionnement correct du vertical, si nécessaire en comparant avec le fonctionnement standard (en testant les éléments issus de la liste donnée par le testeur de patch).

Corrections du vertical

VERTITEST Actions correctives dans le vertical si nécessaire

Génération du patch complémentaire

VERTITEST Création d’un patch « vertical » qui sera installé après le passage du patch standard dans l’environ-nement client


PROCEDURE DE PATCH DANS LE CAS D’UN VERTICAL :

Mise à jour du dossier d’exploitation après test



EXPLOIT EXPLOITST Comparaison de dictionnaire pour vérifier que l’on part bien du même état (si ce n’est pas le cas, faire des copies du dossier EXPLOIT vers EXPLOITST)


VERTICAL EXPLOITST Comparaison de dictionnaire pour s’assurer que tous les développements spécifiques sont bien référencés


EXPLOIT Utilisation du testeur de patch pour identifier les conflits potentiels

Patch de l’environnement d’exploitation test

EXPLOITST Passage des patchs standard, puis des patchs verticaux complémentaires

Test des fonctions EXPLOITST Vérifier le fonctionnement correct du spécifique (en testant les éléments issus de la liste donnée par le testeur de patch)

Corrections du vertical

EXPLOITST Actions correctives dans le spécifique si nécessaire

Installation des patchs standard + vertical

VERTICAL EXPLOIT Report manuel (par copie) des modifications faites dans EXPLOITST


PROCEDURE DE PATCH DANS LE CAS D’UN SPECIFIQUE (2 niveaux):

Mise à jour du dossier d’exploitation après test



EXPLOIT TESTSPE Comparaison de dictionnaire pour vérifier que l’on part bien du même état (si ce n’est pas le cas, faire des copies du dossier EXPLOIT vers TESTSPE)


EXPLOIT DEMO Comparaison de dictionnaire pour s’assurer que tous les développements spécifiques sont bien référencés


EXPLOIT Utilisation du testeur de patch pour identifier les conflits potentiels

Patch de l’environnement d’exploitation test

TESTSPE DEMOTEST Passage des patchs standard

Test des fonctions TESTSPE Vérifier le fonctionnement correct du spécifique (en testant les éléments issus de la liste donnée par le testeur de patch)

Installation des patchs standard

EXPLOIT DEMO Report manuel (par copie) des modifications faites dans TESTSPE


Procédure d’installation d’une nouvelle version mineure

Le principe va être un peu le même, puisqu’une nouvelle version correspond en réalité à un ensemble de mises à jour faites sur une version donnée. Le testeur de patch peut toujours être utilisé pour vérifier les éventuels conflits. En effet, sur tout CD de mise à jour, des pseudo-fichiers de patch, contenant juste la liste des éléments contenus dans le patch, sont livrés.

Le fait d’avoir deux environnements est nécessaire pour travailler de façon étanche dans ce cas. Au lieu d’installer des patchs, on installe la nouvelle version, puis on procède par revalidation des dossiers et ensuite on teste les éléments concernés identifiés par le testeur de patch.

Par ailleurs, il faut faire attention à trois points particuliers lorsqu’on met à jour une version :

� la mise à jour du dictionnaire se faisant par revalidation du dossier ; elle sera donc un peu plus longue (surtout sur 3 niveaux, puisqu’on a 3 dossiers à revalider, le dossier DEMO étant rechargé lors de la mise à jour). Elle suppose de vérifier attentivement avant mise à jour la valeur des codes activité (standard et spécifiques) pour éviter, lors de la revalidation, une désactivation de fonctions utiles, voire la perte de données.

� une mise à jour peut impliquer des modifications de moteurs ou de clients (que l’on peut vouloir tester).

� il faut veiller à supprimer, dans les dossiers de tests, les traitements et états standards qui y sont présents (ceux qui ont été installés lors des derniers tests de mise à jour), car la mise à jour mineure ne touche que les traitements et états du dossier de référence et pas ceux des dossiers de tests.

Sage

Division Moyennes et Grandes Entreprises

10 rue Fructidor

75834 Paris Cedex 17

Tel. 0825 007 017

Quel environnement préconiser pour gérer des développements verticaux

L’environnement de développement

Lorsque l’on crée un vertical, l’environnement concerné est un environnement standard, dans une version et un niveau de patch clairement identifié, sur lequel on dispose d’un dossier de développement, et en principe d’un dossier de test. On travaille dans ce dossier de développement en respectant les normes de développement et de dénomination. Cela correspond au triplet de dossiers nommés X3, VERTISPE, et DEMOTEST dans le schéma décrit en architecture 3 niveaux.

La procédure d’extraction pour livraison

Lorsqu’un développement vertical est prêt à être livré, on extrait de l’environnement de développement un patch (ou un ensemble de patchs) contenant tous les éléments définissant le vertical (éléments modifiés dans le standard, et éléments totalement verticaux).

Ceci sera fait par la suite pour chaque niveau de version géré (et pour chaque liste de patch standard) afin d’être en mesure de livrer le vertical dans un niveau de version mineure et une liste de patch donnés.

Lorsqu’une liste de patch standard est livrée, il peut être nécessaire, ainsi que décrit précédemment, de livrer une liste de patch complémentaire pour tenir compte des incidences du patch dans les verticaux.

Le schéma donné ci-dessous résume l’ordonnancement dans le temps des patchs standard et verticaux (sur une version telle que par exemple la version V140, où on passe ici de 142 à 143 par l’installation de patchs successifs).

Ici, on remarquera qu’après le patch 10, on a créé une liste de patch vertical 10 (intégrant des modifications dues au patch standard, et éventuellement des corrections ou évolutions autres). Les listes de patch 11 et 12 n’ayant pas nécessité de patch complémentaire, on a synchronisé la liste 11 verticale avec la liste de patch 13. Ensuite, on a livré une nouvelle liste de patch verticale 12 pour apporter des correctifs ou des évolutions purement verticales.

142P10 143P11 143P12 143P13

142P10VT 143P11VT 143P12VT

144P14


Les environnements de maintenance et de support

Lorsqu’on gère un vertical, il n’est pas rare d’avoir des clients utilisant ce vertical dans des niveaux de versions et de patchs différents. Il est donc conseillé de disposer d’une copie de l’environnement de développement (dossier de développement et dossier de test) dans chaque version et à chaque niveau de patch en diffusion chez les clients. Ceci suppose de limiter au maximum chez les clients le nombre de versions en diffusion, et aussi d’essayer au maximum de leur imposer un niveau de patch minimal. Au delà, si l’environnement est très particulier, la maintenance et le diagnostic en cas d’incident peuvent aussi être faits directement dans l’environnement du client, avec toutes les précautions que cela suppose.

Une nouvelle version du standard, parce qu’elle est livrée comme un nouveau support, mais aussi parce qu’elle se matérialise par une liste de patch faisant la transition, impose de fait un test et une nouvelle livraison d’un vertical (dès lors qu’il est impacté). Il est donc recommandé aux partenaires développant des verticaux de suivre le rythme des versions et des patchs pour réaliser des versions et des patchs correspondant à leur vertical. Il est bien entendu également possible de livrer des versions de vertical à un rythme plus rapide ; mais toute nouvelle version de vertical se réfèrera à une version et à une liste de patch du standard à partir de laquelle elle a été élaborée.


Les erreurs à ne pas commettre (pour les spécifiques comme pour les verticaux)

Oublier de protéger un champ commençant par X, Y ou Z

Ce n’est pas parce qu’il est nommé ainsi qu’il est protégé, mais bien parce qu’un code activité placé au bon niveau le protège.

Modifier des traitements standards

C’est la pire des choses, parce qu’elle suppose des comparaisons de code à chaque mise à jour de version.

Ne pas vérifier ses valeurs de code activité

En cas de mise à jour de dossier par installation de version, une revalidation de dossier va devoir être faite. Si le code activité spécifique est à Non, les champs spécifiques vont disparaître (des écrans, ce qui est réversible, et de la description des tables : les données ne sont pas perdues, mais si on saisit de nouvelles fiches entre temps, les données correspondantes ne seront pas alimentées, ce qui peut conduire à des incohérences).

Dans certains cas (rares) de mise à jour par patch, un nouveau code activité peut être patché. Là aussi, il faut vérifier avec vigilance la valeur du nouveau code activité patché, afin de vérifier que la fonctionnalité désirée (si elle l’est) sera activée.

Bien faire attention à la valeur des codes activités livrés

A la première livraison d’un code activité, on tient compte de sa valeur dans le patch (si le code activité existait au préalable, cette valeur est ignorée). Ceci permet de livrer des verticaux ou spécifiques inactifs (mais activables) ou actifs au choix.

Multiplier les « petits » spécifiques partout

Par exemple, plutôt que de modifier N champs dans des écrans différents, il vaut mieux agir, quand c’est possible, sur les types de données.

De même, plutôt que de modifier N onglets dans un objet, mieux vaut rajouter un onglet spécifique.

Enfin, si on doit rajouter un grand nombre de champs spécifiques dans une table standard, il est souvent préférable de créer une table complémentaire liée à la première (même si en contrepartie cela complexifiera la gestion standard de l’objet qui gère cette table).


Protéger trop globalement un élément

C’est se couper des évolutions du standard sur des éléments qui auraient pu ne pas être protégés.

Ne pas tester ses spécifiques après une mise à jour

C’est une assurance contre les mises à jour calamiteuses, çà ne prend pas trop de temps si on utilise le testeur de patch.

Ne pas gérer correctement les actions sur champ SPE ou SPV

Ces actions ne sont pas protégées par code activité. Elles sont susceptibles d’être livrées en patch, et peuvent être supprimées par un patch du bon type (un patch typé vertical supprimera les actions SPV non livrées sur un écran présent dans le patch, un patch typé spécifique supprimera les action SPE non livrées dans un écran présent dans le patch)

Patcher des écrans générés par des transactions

Un écran généré par transaction l’est à partir d’écrans de base. C’est donc ces écrans qu’il faut livrer, et pas les écrans finaux.

Pour que les écrans finaux prennent en compte les modifications, il faut penser, à chaque patch, à déclencher la génération de ces écrans. Deux solutions sont possibles :

� déclencher la validation des transactions, via un traitement dans le patch

� alerter les utilisateurs pour qu’ils lancent ces validations (souvent c’est cette solution qui est préférée).


Annexes

Sous-programme de recherche d’un texte dans un écran

Ce sous-programme permet de renvoyer les textes affichés dans un écran. Il évite de faire référence, dans un traitement, à un texte spécifique dont le numéro peut varier, mais dont on connaît l’utilisation dans un écran.

# Fonction de recherche de textes dans un écran # Le premier argument est le code de l’écran # Le second est : # - soit le code du champ (on récupère l’intitulé associé) # - soit un numéro (on récupère l’intitulé du bloc correspondent) # - soit vide (on récupère l’intitulé de l’écran) Funprog RDM(MASQUE,CHAMP) Value Char MASQUE(),CHAMP() # Ouverture des tables si nécessaire If clalev([AMK])=0 : Local File AMSK : Endif If clalev([AMZ])=0 : Local File AMSKZON : Endif If pat(vireblc(CHAMP,0),”#*”) : # Le champ commence par un chiffre Read [AMK]CODMSK=MASQUE If fstat=0 If [AMK]TITBLOC(val(CHAMP)-1)<>0 End func RDT([AMK]TITBLOC(val(CHAMP))) Endif Endif Elsif CHAMP<>”” Read [AMZ]CODE=MASQUE;CHAMP If fstat=0 If [AMZ]INTIT<>0 End func RDT([AMZ]INTIT) Endif Endif Else Read [AMK]CODMSK=MASQUE If fstat=0 If [AMK]INTMSK<>0 End func RDT([AMK]INTMSK) Endif Endif Endif End “” # Fonction de lecture de textes dans ATEXTE # (dans la langue courante) # Le premier argument est le numéro de texte Funprog RDT(NUMERO) Value Integer NUMERO If clalev([ATX])=0 : Local File ATEXTE: Endif Read [ATX]NUMERO=GLANGUE;NUMERO


If fstat=0 End [ATX]TEXTE

Else

End “”

Endif

Gestion d’un traitement vertical de point d’entrée pour permettre un chaînage

En version 5 , dans la table des points d’entrée, un champ libre nommé TRTPAR a été ajouté. La manière de l’utiliser est libre (Sage ERP X3 se contente de permettre sa saisie). On propose une norme d’utilisation en positionnant dans cette variable une liste de traitements à appeler sous la forme suivante :

TRAITEMENT1~CODE_ACTIVITE1; TRAITEMENT2~CODE_ACTIVITE2; …

Le sous-programme qui permet de décoder une chaîne de ce type est fourni ci-après. A partir de là, on peut imaginer que le traitement branché sur le premier point d’entrée analyse et appelle successivement les traitements suivants, selon la valeur du code activité.

Le traitement de décodage est le suivant :

# Décodage des points d'entrée complémentaires # Rappelons que la colonne TRTPAR est structurée sous la forme : # PROG1~CODACT1;PROG2~CODACT2; ...... # NBENT : Nombre de points d'entrée # TRTENT : Nom du programme # ACTENT : Code activité associé # VACTENT : Egale 2 si code activité actif ############################################### Subprog ENTREECOMP(PROGSTD,NBENT,TRTENT,ACTENT,VACTENT) Value Char PROGSTD Variable Integer NBENT Variable Char TRTENT()(1..) Variable Char ACTENT()(1..) Variable Integer VACTENT(1..) Raz NBENT,TRTENT,ACTENT,VACTENT If clalev([F:APE])=0 : Local File AENTREE [APE] : Endif If clalev([F:ACV])=0 : Local File ACTIV [ACV] : Endif Read [APE]APE0=PROGSTD If fstat<>0 or [F:APE]TRTPAR="" : End : Endif # Il y a des points d'entrée complémentaires # Stucture : PROG1~CODACT1;PROG2~CODACT2; ...... Local Char TRTPAR(250) Local Integer I,A1(1..10),A2(1..10),D1,DEB TRTPAR=[F:APE]TRTPAR DEB=1 For I=1 To 10


D1=instr(D1+1,TRTPAR,"~") If D1=0 : Break 1 : Endif NBENT+=1 : A1(NBENT)=D1 Next I For I=1 To NBENT D1=instr(D1+1,TRTPAR,";") A2(I)=D1 Next I If A2(I)=0 : A2(I)=len(TRTPAR) : Endif For I=1 To NBENT If I=1 : DEB=1 : Else : DEB=A2(I-1)+1 : Endif TRTENT(I)=mid$(TRTPAR,DEB,A1(I)-DEB) ACTENT(I)=mid$(TRTPAR,A1(I)+1,A2(I)-A1(I)-1) Read [ACV]CODACT = ACTENT(I) If fstat=0 : VACTENT(I)=[F:ACV]FLACT : Endif Next I End


Normes de numérotation et de dénomination

Codes activités

� Commençant par X : verticaux

� Commençant par Y : spécifiques faits par le partenaire pour un client donné

� Commençant par Z : spécifiques faits par le client lui-même

Champs, écrans, objets

Même norme pour distinguer les verticaux et spécifiques que pour les codes activité. Sur les champs, il est conseillé de les faire commencer par X_, Y_, Z_. A noter que sur un écran ou une table totalement spécifique, la règle de dénomination n’a pas besoin de s’appliquer sur les champs (c’est d’autant plus nécessaire qu’un écran totalement spécifique présentant des données issues de tables standard va bien entendu reprendre les noms des champs de la table pour bénéficier des mécanismes de transfert de classe.

Pour les traitements spécifiques associés à des écrans standard, on retrouve la règle de dénomination SPxxx.

Messages (ATEXTE)

� Spécifiques et verticaux : numéros supérieurs à 100.000

Menus locaux et chapitres de messages

Les normes sont les suivantes :

� Messages verticaux : 160 à 169, 5000 à 5199

� Menus locaux verticaux : 1000 à 1999, 5200 à 5999

� Messages spécifiques : 6000 à 6199

� Menus locaux spécifiques : 6200 à 6999

Tables diverses

Les normes sont les suivantes :

� Tables diverses verticales : 1000 à 1999

� Tables diverses spécifiques : 6000 à 6999


Sous-programme de protection d’un vertical

Afin de garantir l’investissement qu’un partenaire fait sur un vertical installé chez un client, il peut être intéressant de gérer une protection. La première chose à faire est de ne pas livrer les sources (ou au moins pas tous). La deuxième chose peut être de tester la présence d’un fichier de sérialisation basé sur le numéro de série unique de la licence. Le traitement proposé ci-dessous est un exemple qui peut – et doit – être adapté par le partenaire pour tester la présence d’un tel fichier de sérialisation.

###########################################################################

#

# Gestion de numéros de série pour protéger des verticaux

#

###########################################################################

#

# Ce traitement est fourni à titre d'exemple, sans aucune garantie d'aucune

# sorte. Il contient un algorithme simple de crytage (qui n'est pas celui

# utilisé par Sage ERP X3, et qui n'a pas la prétention d'être inviolable)

# N'importe quel autre algorithme de cryptage du marché pourrait être

# utilisé

#

# Il se base sur le numéro de série unique fourni par Sage lors de la

# livraison d'une licence. Aucune garantie implicite ou explicite n'est

# donnée sur la pérennité de ce numéro, qui peut être amené à

# changer pour des raisons techniques lorsque le client est amené à changer

# les options de sa licence

#

# (C) SAGE 2009

###########################################################################

#

# Principe de base :

# On part du principe que le numéro de licence standard fourni par Sage

# contient 6 chiffres uniques liés au client et à son identité

# (numéro de série du client).

#

# Ce numéro est accessible par la fonction adonix ver$(0)(il s'agit des 6

# derniers chiffres)

#

# On définit deux sous-programmes qui doivent être placés dans deux

# traitements différents,

# et dont les sources ne sont pas livrés :

#

# - le premier (appelé ici CREE_SERIE) crée un fichier de clés qui encode

# un numéro de série donné

#

# - le deuxième (appelé ici TEST_SERIE) lit le fichier de clés et vérifie

# que l'encodage correspond au numéro de la licence

# Le spécifique devra appeler (à des endroits stratégiques non fournis en

# source) ce deuxième sous-programme qui sera intégré dans un traitement

# spécifique non fourni en source, afin de bloquer le fonctionnement si,

# en retour, OK=0

#

# Remarque :

# Il n'est pas recommandé d'appeler trop souvent ce

# traitement, qui fait tout de même une lecture sur le serveur

# d'application et pourrait générer des contentions s'il était utilisé


# dans une boucle trop fréquemment appelée. L'idéal est de l'appeler dans

# une séquence d'initialisation stratégique pour la suite

#

# Les deux sous-programmes proposés ici font le même encodage du numéro de

# série, basé sur 8 nombres premiers quelconques qui seront particularisés

# par chaque partenaire.

#

# Il est suggéré de nommer ce fichier serial_nompartenaire, et de le placer

# dans le répertoire .serialisation du run-time.

#

# Recherche de nombre premiers... (exécuté si on exécute le traitement)

Local Integer NOMBRE, ESSAIS : NOMBRE=1243 : ESSAIS=1

Call RECH_PREM(NOMBRE,ESSAIS)

End

#

# Sous-programme de génération d'un fichier de clés (ici dans le répertoire

# tmp). On précise en entrée le numéro de série (entier sur 8 chiffres

# maximum), et le fichier à créer.

# Ce fichier, renommé comme précisé ci-dessus, devra être installé chez le

# client.

# Ce sous-programme doit rester chez le partenaire ayant créé le vertical

# (sa livraison permettrait à quiconque de créer des fichiers de

# sérialisation)

# Remarque : rien n'empêche d'encoder à la suite un deuxième nombre

# permettant de définir des options secondaires de la licence

#

Subprog CREE_SERIE(SERIE,FICSER)

Value Integer SERIE

Value Integer OPTIONS(8)

Value Char FICSER()

# On sauvegarde les valeurs des séparateurs...

Local Char ZADXIFS,ZADIRS

ZADXIFS=adxifs : ZADXIRS=adxirs

adxirs=chr$(13)+chr$(10)

adxifs=""

# On traite par paquets de 4 chiffres, puisqu'il y a 8 chiffres dans le

# numéro

Local Integer PART1,PART2,PART3,PART4

PART1=mod(SERIE,10000)

PART2=int(SERIE/10000)

PART3=100*int(PART1/100)+int(PART2/100)

PART4=100*mod(PART1,100)+mod(PART2,100)

# On choisit 8 nombres (premiers de préférence) et on les garde secrets

# pour éviter un décodage !

# Il ne faut pas qu'ils soient plus grands que deux puissance 17 (131072),

# ce qui laisse de la marge...

# Il y a en effet 12250 nombres premiers inférieurs à 131072, soit 5*10^32

# combinaisons à tester

Local Integer NOMBRE1,NOMBRE2,NOMBRE3,NOMBRE4,NOMBRE5,

& NOMBRE6,NOMBRE7,NOMBRE8

NOMBRE1=129917

NOMBRE2=129919

NOMBRE3=129951

NOMBRE4=129957

NOMBRE5=131021

NOMBRE6=131027

NOMBRE7=131051


NOMBRE8=131057

# Création du fichier de sérialisation

Openo filpath("tmp",FICSER,""),0 Using [SER]

# Rien n'interdit des variations pourvu que ce soient les mêmes dans le

# programme de test de licence

Wrseq format$("N0:8#",mod(PART1*NOMBRE1,NOMBRE2)) Using [SER]




# C'est fini

Openo Using [SER]

End

#

#

# Sous-programme de vérification du fichier de clés (ici dans le répertoire

# .serialisation)

# Doit être inclus dans un traitement non livré (on peut modifier son nom,

# mais l'algorithme doit être le même que le sous-programme précédent)

Subprog TEST_SERIE(OK)

Variable Integer OK

# On sauvegarde les valeurs des séparateurs...

Local Char ZADXIFS,ZADIRS

ZADXIFS=adxifs : ZADXIRS=adxirs

adxirs=chr$(13)+chr$(10)

adxifs=""

Local Integer SERIE

SERIE=val(right$(ver$(0),8)) : # Le numéro de licence "officiel"

Local Char FICSERIE(20),NUMLU(20)(1..4)

# Vous pouvez prendre le nom que vous voulez... mais pas serial_adonix !

FICSERIE="serial_partenaire"

# Le fichier existe-t-il bien ?

If filinfo(filpath("!.serialisation",FICSERIE,""),0)<0

OK=0

End

Endif

Openi filpath("!.serialisation",FICSERIE,"") Using [SER]

OK=1

Rdseq NUMLU(1) Using [SER]: Rdseq NUMLU(2) Using [SER]

Rdseq NUMLU(3) Using [SER]: Rdseq NUMLU(4) Using [SER]

Openi Using [SER]

#

# Cette partie de l'algorithme est la même que dans le sous-programme

# précédent

#

# On traite par paquets de 4 chiffres, puisqu'il y a 8 chiffres dans le

# numéro

Local Integer PART1,PART2,PART3,PART4


PART1=mod(SERIE,10000)

PART2=int(SERIE/10000)

PART3=100*int(PART1/100)+int(PART2/100)

PART4=100*mod(PART1,100)+mod(PART2,100)

# On reprend les mêmes 8 nombres (premiers de préférence) et on les garde

# secrets pour éviter un décodage !

# Il ne faut pas qu'ils soient plus grands que deux puissance 17 (131072),

# ce qui laisse de la marge...

Local Integer

NOMBRE1,NOMBRE2,NOMBRE3,NOMBRE4,NOMBRE5,NOMBRE6,NOMBRE7,NOMBRE8

NOMBRE1=129917

NOMBRE2=129919

NOMBRE3=129951

NOMBRE4=129957

NOMBRE5=131021

NOMBRE6=131027

NOMBRE7=131051

NOMBRE8=131057

If mod(PART1*NOMBRE1,NOMBRE2)<>val(NUMLU(1)) : OK=0 : Endif




# On restaure les valeurs des séparateurs et on termine ...

adxifs=ZADXIFS : adxirs=ZADXIRS

End

#

# Si votre imagination vous fait défaut pour trouver des nombres

# premiers...

#

Subprog RECH_PREM(NOMBRE,ESSAIS)

Variable Integer NOMBRE

Variable Integer ESSAIS

Local Integer FOUND

NOMBRE+=(mod(NOMBRE,2)=0)

Repeat

Repeat

FOUND=1

For I=3 To int(sqr(NOMBRE)) Step 2

If mod(NOMBRE,I)=0

NOMBRE+=2

FOUND=0

Break

Endif

Next

Until FOUND=1

Errbox num$(NOMBRE)

NOMBRE+=2

ESSAIS-=1

Until ESSAIS<0

End

patches et spécifiques > - logtimiz...une remarque importante est à faire : quand on parle de...

Documents