Outils Ingenierie Livre Blanc Specifiques Et Verticaux PDF

Patches et spécifiques >
Principes de base
Sage X3
V6
Date : August 26, 2009

Writer : Dominique Bopp
Distribution : Public
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
2 / 33 Livre blanc spécifiques et verticaux.doc - document indicatif fourni sans engagement ni garantie -
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 :
Dossier de Dossier de référence

référence "X3" "X3" (*)
EXPLOIT DEMO TESTSPE DEMOTEST

(dossier (dossier (dossier de test (dossier de test
d’exploitation standard de des des patches)
client) démonstration) spécifiques)
(**) 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.
Le schéma est alors celui-ci :
Environnement Environnement
(« solution ») (« solution ») de
d’exploitation développement
Dossier de Dossier de référence

référence "X3" "X3" (*)
VERTICAL DEMO DEMOTEST

VERTITEST (dossier de test
(dossier où le vertical et (dossier (dossier de des patches)
le spécifique partenaire standard de développement et de test
sont installés) démonstration) des verticaux et
spécifiques partenaire)
EXPLOIT EXPLOITST
(dossier (dossier de test
d’exploitation des spécifiques
client) client)
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 VERTITEST VERTICAL Comparaison de dictionnaire

préliminaires pour vérifier que l’on part
bien du même état
Vérifications VERTITEST DEMOTEST Comparaison de dictionnaire

préliminaires pour s’assurer que tous les
développements sont bien
référencés
Vérifications VERTITEST Utilisation du testeur de

préliminaires patch pour identifier les
conflits potentiels
Patch de VERTITEST DEMOTEST Passage des patchs

l’environnement
standard et vertical
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 VERTITEST Actions correctives dans le

vertical vertical si nécessaire
Génération du patch VERTITEST Création d’un patch

complémentaire « 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
Vérifications EXPLOIT EXPLOITST Comparaison de dictionnaire

bien du même état (si ce
n’est pas le cas, faire des
copies du dossier EXPLOIT
vers EXPLOITST)
Vérifications VERTICAL EXPLOITST Comparaison de dictionnaire

développements spécifiques
sont bien référencés
Vérifications EXPLOIT Utilisation du testeur de

conflits potentiels
Patch de EXPLOITST Passage des patchs

l’environnement standard, puis des patchs
d’exploitation test 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 EXPLOITST Actions correctives dans le

vertical spécifique si nécessaire
Installation des VERTICAL EXPLOIT Report manuel (par copie)

patchs standard + des modifications faites
vertical dans EXPLOITST
PROCEDURE DE PATCH DANS LE CAS D’UN SPECIFIQUE (2 niveaux):
Mise à jour du dossier d’exploitation après test
Vérifications EXPLOIT TESTSPE Comparaison de dictionnaire

bien du même état (si ce
n’est pas le cas, faire des
copies du dossier EXPLOIT
vers TESTSPE)
Vérifications EXPLOIT DEMO Comparaison de dictionnaire

développements spécifiques
sont bien référencés
Vérifications EXPLOIT Utilisation du testeur de

conflits potentiels
Patch de TESTSPE DEMOTEST Passage des patchs

l’environnement standard
d’exploitation test
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 EXPLOIT DEMO Report manuel (par copie)

patchs standard 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.
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 144P14
142P10VT 143P11VT 143P12VT
Sage
Division Moyennes et Grandes Entreprises
10 rue Fructidor
75834 Paris Cedex 17
Tel. 0825 007 017
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

Outils Ingenierie Livre Blanc Specifiques Et Verticaux PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Outils Ingenierie Livre Blanc Specifiques Et Verticaux PDF

Transféré par

Droits d'auteur :

Formats disponibles

Patches et spécifiques >

Date : August 26, 2009

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

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

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

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

Ce document présente un certain nombre de conseils pour faciliter la mise en

Ce document présente des préconisations et des propositions de mise

Ce que peuvent inclure des spécifiques ou verticaux

Utilisation du code activité

Gestion des textes du dictionnaire (ATEXTE)

Gestion des menus locaux et messages (APLSTD)

Conflits potentiels de points d’entrée

Protection par code activité

Mise à jour d’une version

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

Organisations préconisées pour les environnements clients

Architecture à deux niveaux

Dossier de Dossier de référence

EXPLOIT DEMO TESTSPE DEMOTEST

Architecture à trois niveaux

Dossier de Dossier de référence

VERTICAL DEMO DEMOTEST

ETAPE DOSSIER 1 DOSSIER 2 Opération

Vérifications VERTITEST VERTICAL Comparaison de dictionnaire

Vérifications VERTITEST DEMOTEST Comparaison de dictionnaire

Vérifications VERTITEST Utilisation du testeur de

Patch de VERTITEST DEMOTEST Passage des patchs

Test des fonctions VERTITEST DEMOTEST Vérifier le fonctionnement

Corrections du VERTITEST Actions correctives dans le

Génération du patch VERTITEST Création d’un patch

ETAPE DOSSIER 1 DOSSIER 2 Opération

Vérifications EXPLOIT EXPLOITST Comparaison de dictionnaire

Vérifications VERTICAL EXPLOITST Comparaison de dictionnaire

Vérifications EXPLOIT Utilisation du testeur de

Patch de EXPLOITST Passage des patchs

Test des fonctions EXPLOITST Vérifier le fonctionnement

Corrections du EXPLOITST Actions correctives dans le

Installation des VERTICAL EXPLOIT Report manuel (par copie)

ETAPE DOSSIER 1 DOSSIER 2 Opération

Vérifications EXPLOIT TESTSPE Comparaison de dictionnaire

Vérifications EXPLOIT DEMO Comparaison de dictionnaire

Vérifications EXPLOIT Utilisation du testeur de

Patch de TESTSPE DEMOTEST Passage des patchs

Test des fonctions TESTSPE Vérifier le fonctionnement

Installation des EXPLOIT DEMO Report manuel (par copie)

La procédure d’extraction pour livraison

142P10 143P11 143P12 143P13 144P14

142P10VT 143P11VT 143P12VT

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

Modifier des traitements standards

Ne pas vérifier ses valeurs de code activité

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

Multiplier les « petits » spécifiques partout

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

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

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

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

# Fonction de recherche de textes dans un écran

# Ouverture des tables si nécessaire

If pat(vireblc(CHAMP,0),”#*”) : # Le champ commence par un chiffre

# Fonction de lecture de textes dans ATEXTE

Gestion d’un traitement vertical de point d’entrée pour