DevelopRules Forextensions

Développer des extensions
A partir de la version 7
02 2016
La couche verticale, présente depuis les premières versions de l'application, a été
créée pour faciliter le travail des partenaires en permettant le déploiement facile de
tout développement sur différents sites clients.
Depuis lors, le marché a connu des évolutions qui nous ont amené à ajuster ce
modèle pour l'adapter au besoin des clients d'installer des extensions provenant de
partenaires multiples (les législations en particulier).
Nous avons défini des règles afin d'éviter les conflits lorsque des extensions
développées par différents partenaires sont déployées dans les mêmes dossiers.
Nous avons introduit le concept de 'Add-ons' pour désigner les extensions qui
respectent ces règles. De plus, nous nommons 'Assets' les extensions qui ne suivent
pas ces règles.
L'objectif de ce guide est d'expliquer les règles de développement à appliquer pour

faciliter l'intégration de plusieurs extensions de développement dans un dossier
client unique.
Il s'applique aux solutions basées sur la plateforme technologique commune fournie

par Sage pour le développement de logiciels applicatifs.
Nouveautés
La version 7 et les mises à jour suivantes offrent :
• des capacités de codification étendues,
• de nouvelles fonctions de développement,
• de nouvelles fonctionnalités de plateforme,
Ces améliorations nous permettent de répondre à ces nouvelles exigences et facilitent
l'adoption des règles d'Add-on.
En savoir plus
Ce document explique les principales règles de développement d'add-ons, mais ne
remplace pas la formation officielle sur la plateforme technologique Sage qui est
nécessaire à la bonne compréhension et application de ces concepts.
Développer des extensions Page 2 sur 43

Table des matières
Nouveautés 2
En savoir plus 2
LA PLATEFORME TECHNOLOGIQUE 5
REGLES DE NOMMAGE 8
Éléments ajoutés dans une entité standard 10
Nouvelle entité définie dans le dictionnaire 11
Menus locaux et tables diverses 12
Code source 12
Données d'administration 12
Factory ID 13
Bonnes pratiques de nommage pour les données d'administration 14
REGLES DE DEVELOPPEMENT 18
Principales règles de développement à appliquer 18

Actions sur champ 18
Comment gérer la couche verticale avec modèle d'objet et points d'entrée 19
Gérer la couche verticale avec d'autres modèles : programme d'aiguillage 23
États de développement 25
Points d'attention 26
Interactions avec le standard 27
Test 27
OUTIL DE LICENCE PARTENAIRE 29
Fichier partenaire 29
Créer vos fichiers de règles 30
Créer un fichier de licence 31
PROGRAMME DE CONTROLE DES DEVELOPPEMENTS 33

Introduction 33
Lancer l'outil 33
Détail des règles 34

Convention de nommage 34
Restrictions sur les dictionnaires classiques 35
Restrictions sur les dictionnaires Syracuse 36
Modifications autorisées sur les dictionnaires classiques 37
Modifications autorisées sur les dictionnaires Syracuse 37
Règles supplémentaires ou commentaires 38
EMBALLAGE 40
Cartographie de votre add-on 40
Règles de qualité pour la documentation 40
Patching 41
Maintenance et support 42

La plateforme technologique
La plateforme vous permet de développer des extensions pour Enterprise Management. Il

est important de comprendre les capacités de la plateforme et de partager le même
vocabulaire lors du développement de solutions.
Les développements sont stockés et isolés dans trois couches différentes.
• Standard : développés et maintenus exclusivement par Sage

• Verticale : développés et maintenus par les tiers. Les partenaires de Sage
peuvent développer des assets et add-ons commerciaux en utilisant la plateforme
dans la couche verticale. Ils peuvent être packagés et partagés. Sage fournit à la
demande de chaque partenaire un identifiant unique pour les add-ons
commerciaux (pour éviter les conflits de nommage).
Catégories d'Assets et d'Add-ons commerciaux :
o Spécifique à une industrie : fonctionnalité basée sur une forte expertise
du flux métier pour une seule industrie
o Généralisée aux industries : fonctionnalité générique qui s'applique à
toutes les industries
o Marchés locaux : fonctionnalité assurant la conformité avec les besoins
des marchés locaux
• Spécifique : développements sur mesure créés pour un client donné et qui ne
sont pas conçus pour être partagés avec d'autres clients. Ils peuvent être
développés par un partenaire et/ou par le client lui-même.
Les développements dans les couches standard et verticales peuvent être partagés et
installés à plusieurs emplacements. Les développements spécifiques ne sont
généralement pas partagés et sont normalement installés sur un emplacement client
unique (ce dernier peut être sur plusieurs dossiers selon le déploiement).
Vous pouvez utiliser la plateforme pour isoler et patcher un développement. Les codes
d'activité sont utilisés pour baliser des éléments ajoutés ou modifiés afin de :
• les protéger de l'application de patch standard ;
• pouvoir les récupérer facilement ;
• pouvoir les désactiver pour certains dossiers.
La plateforme fournit aux partenaires des fonctionnalités pour développer des extensions
tout en ajoutant de nouvelles fonctions ou en personnalisant les fonctions existantes :
• Le code source est séparé et utilise des points d'entrée prédéfinis lors
d'interactions avec le standard ;
• Des actions dédiées, séparées de la couche standard, sont utilisables ;
• Un large ensemble de paramètres est disponible pour personnaliser aisément
l'application :
o Des transactions sont disponibles pour les objets les plus pertinents ;

o L'authoring facilite la personnalisation de la mise en page pour l'utilisateur
final afin de répondre à des besoins spécifiques ;
o Des pré-paramétrages et options fonctionnels permettent de créer un
dossier adapté aux besoins du client.
• La gestion des langues et de la documentation est incluse dans la plateforme ;
• La gestion des patchs est disponible et permet d'isoler et protéger les
personnalisations ;
• Les web services sont disponibles pour interagir avec l'application.
Les règles de développement des add-ons sont conçus pour éviter les conflits
d'installation ou d'application de patch entre plusieurs add-ons dans un dossier client
unique. Toutefois, l'application de ces règles ne garantit pas que plusieurs add-ons
concernant le même objet fonctionnel interagiront correctement.
Les conflits fonctionnels entre deux add-ons doivent être gérés au cas par cas par
l'équipe de mise en œuvre du projet.
Les règles de développement des add-ons sont conçues pour évoluer au fil du temps afin
d'enrichir les possibilités de co-développement et de prendre en compte les améliorations
de la plateforme.
Ce document décrit les nouveaux concepts introduits dans le modèle de données Version
7, en particulier les fonctionnalités d'administration stockées dans la base de données
MongoDB, ainsi que les nouvelles capacités de développement d'add-ons offertes par la
dernière version d'Enterprise Management.
Les fonctionnalités les plus intéressantes pour le développement d'extensions sont :
A partir de la Version 7
• Extension de codification
• Capacités d'authoring
• Contrôle du développement des programmes
• Nouvelles capacités de modélisation : classes et représentations
A partir de l'Update 8
• Programme d'aiguillage automatique pour les objets et les points d'entrée
• Factory ID
• Outil de licence pour add-ons
La Version 7 apporte des extensions de codification qui nous permettent de proposer une
gamme de codification dédiée pour chaque add-on, évitant les conflits de nommage :
Éléments V6 (Remise1) A partir de V7
Code objet 3 caractères 8 caractères
Abréviation table 3 caractères 7 caractères
Abréviation masque 4 caractères 8 caractères
Type de données 3 caractères 8 caractères

Code de la consultation 3 caractères 5 caractères
Menus locaux 10 000 menus 32 000 menus
Tables diverses 10 000 tables 32 000 tables
De nouveaux éléments stockés dans la base de données MongoDB sont définis sans
limite de taille de codification.
Les codifications réservées, les règles de développement renforcées, le programme de

contrôle et l'amélioration des capacités d'application de patch vous aideront à développer
des add-ons en tout sécurité.

Règles de nommage
Les règles de nommage empêchent les conflits entre les extensions de développement
de différents partenaires afin que des extensions ne soient pas écrasées par d'autres
dans la couche verticale.
Depuis la première version de l'application, les plages de nommage étaient les suivantes :
• Couche standard : A-V (A réservé pour le module superviseur)
• Couche verticale : X-Y
• Couche spécifique : Z
Tous les éléments commençant par W correspondent à des éléments générés
automatiquement (comme les transactions).
Il existait des plages dédiées aux menus locaux et aux tables diverses pour la couche
verticale.
Il est facile de comprendre que ces règles sont correctes lorsqu'un partenaire est seul sur
un dossier client.
Cependant, aujourd'hui, nos clients s’attendent à trouver sur le marché différentes
extensions provenant de plusieurs partenaires pour les installer simultanément dans leur
environnement.
Sans fixer de règles, il n'est pas possible de répondre à ces attentes du marché qui créent
des opportunités commerciales pour nous tous.
‘Add-on’ ‘Asset’
Dossier Dossier
d'application d'application
standard standard
Add-on 1 Add-on 2 Asset 1 Asset 2
Zone de conflit de
nommage
Pour répondre à ce nouveau besoin d'installer différentes

extensions partenaires dans le même dossier, nous devons nous assurer qu'ils n'utilisent
pas les mêmes noms.
C'est pourquoi Sage a créé le concept d'identifiant unique.
Les extensions de code livrées avec la V7 nous permettent de fournir, sur demande, à
chaque partenaire :
• Un identifiant unique, généralement un code alphanumérique de quatre chiffres ;

• Une plage de menus locaux et de tables diverses.
Cet identifiant (par exemple, XX12) doit être utilisé au début de chaque nom que vous
créez dans le dictionnaire et dans vos programmes.
Cette règle de nommage s'applique à tous les éléments de dictionnaire qui utilisent la
codification alphanumérique comme les écrans, les classes, les représentations, les
codes d'activité, les actions, le code source, etc.
Vous devez utiliser ces conventions pour toutes les clés, les abréviations, ainsi que les
paramétrages des éléments.
Les nouvelles plages de nommage sont donc :

• Couche standard : A-V (A réservé pour le module superviseur)
• Couche verticale :
o Add-ons : X*** (identifiant unique, si les règles de nommage sont
respectées, pas de conflit de nommage)
o Assets : Y (des conflits peuvent se produire si vous installez différents
assets dans le même dossier)
• Couche spécifique : Z (les éléments sont spécifiques aux clients, pas de conflit à
gérer)
Pour les menus locaux et les tables diverses, les plages 13000-13999 et 18000-29999
sont réservées. Une plage dédiée, en cohérence avec vos besoins, vous sera réservée
sur demande.
L'équipe Sage Global Product Delivery est en charge de l'allocation de code suite à une
demande partenaire.
Les codes sont stockés dans une base de données unique pour empêcher les allocations
doubles.
Les données d'administration (authoring, badges, items de menu, etc.) sont stockées
dans la base de données MongoDB.
Chaque élément de données d'administration doit également être unique et doit contenir
l'identifiant unique (au début, ou inclus dans certains cas spécifiés ci-après).
À partir de l'Update 8, nous encourageons fortement les partenaires à utiliser le Factory

ID pour baliser leurs éléments. Le Factory ID a le même rôle que le code d'activité pour
les éléments stockés dans la base de données MongoDB (voir section Factory ID).
Remarque : Il n'existe pas de limite de taille de codification pour les identifiants

stockés dans la base de données MongoDB.
Si vous possédez une extension existante, créée avant que les nouvelles règles ne soient
définies, il vous faudra bien sûr effectuer un renommage avant de pouvoir commencer le
programme d'add-ons, mais cela vous permettra ensuite d'accéder à de nouvelles
opportunités commerciales.
Si vous développez une nouvelle extension, nous vous conseillons de suivre dès
maintenant les règles de nommage et de développements d'add-ons.

Des conflits pourraient se produire si vous installez dans la couche verticale une
extension qui ne suit pas les règles de nommage de certains add-ons.
Elle doit être gérée par projet, quand le conflit se produit, car il ne peut pas être anticipé.
La position de Sage est de promouvoir les add-ons et d'exiger que les codes des assets
soient renommés.
Important ! Tout ce que vous développez doit commencer par ou contenir votre
identifiant unique attribué par Sage.
Par exemple, l'identifiant unique pour Sage Portugal est XX04 et tout ce qui est développé
au Portugal doit commencer par XX04.
Sur demande, Sage fournit à chaque partenaire une plage de menus locaux et de tables
diverses, adaptés selon les besoins. Par exemple, pour Sage Portugal, cette plage est
13220-13259.
Remarque : Pour les tables Transcodage import/export, une règle devrait être livrée
pour empêcher les conflits. Le besoin étant rare, elle n’a pas encore été mise en
œuvre.
Nous allons examiner dans les prochains paragraphes comment procéder pour suivre les
règles de nommage.
Éléments ajoutés dans une entité standard

Lorsque vous ajoutez des champs à une entité standard (un écran dans l'exemple) :
• Le nom des champs doit commencer par votre identifiant ;
• Un code d'activité, qui commence également par votre identifiant, doit aussi être
paramétré pour chaque champ ajouté.
Dans la capture d'écran ci-dessous, X1QT représente l'identifiant unique à quatre chiffres
pour le partenaire.
Convention que vous pouvez utiliser :

Pour faciliter l'identification, vous pouvez utiliser cette convention de nommage pour les
champs que vous créez en complétant les éléments de dictionnaire standard (tables,
écrans, etc.) et qui n'existent pas encore dans l'application : commencez par l'identifiant
suivi de underscore " _ "

Dans l'exemple, ce pourrait être X1QT_MAX.
Nouvelle entité définie dans le dictionnaire

Pour une nouvelle entité, comme une table ou une classe dans l'exemple :
• Le nom et l'abréviation doivent commencer par votre identifiant ;
• Un code d'activité, qui commence également par votre identifiant, doit aussi être
paramétré pour l'élément.
Pour les sous-éléments, comme les colonnes,

• vous pouvez utiliser une codification libre : les sous-éléments ne seront pas en
conflit avec d'autres extensions partenaires car ils appartiennent à votre propre
entité ;
• vous n'avez pas besoin de protéger les sous-éléments avec un code d'activité car
ils sont protégés par le code paramétré au niveau parent.
Permettre une codification libre pour les colonnes facilite l'utilisation des affectations de
classe, ce qui simplifie le codage.

Menus locaux et tables diverses
Sage affecte aux partenaires une plage de menus locaux et de tables diverses à utiliser
pour le développement.
Utilisez les valeurs de la plage et paramétrez un code d'activité commençant par votre
identifiant pour les éléments que vous créez.
Code source
Le nom de tous les scripts que vous créez doit commencer par votre identifiant.
Exception : Lorsqu'un programme d'aiguillage est nécessaire (voir définition ci-dessous),

il doit garder le même nom standard car il est partagé par différents partenaires.
Pour éviter tout problème, un programme d'aiguillage ne doit pas être patché, mais
modifié manuellement sur un emplacement client.
REMINDER
Les entités spécifiques à un client (scripts et dictionnaires) doivent commencer par Z (et être
protégées par un code d'activité pour les entités de dictionnaire).
Une exception existe pour les scripts : un nom qui commence généralement par SPE est
automatiquement proposé pour les développements sur mesure. Comme il n'y en a qu'un, il
n'est pas nécessaire de le modifier.
Données d'administration

Nous rassemblons dans cette catégorie tous les éléments stockés dans la base de
données MongoDB.
Beaucoup de ces éléments seront livrés aux clients, dans le cadre de votre add-on, et
nous devons empêcher les conflits de nommage avec d'autres éléments issus d'autres
extensions partenaires lorsque vous installez un package sur un site client.
La solution est d'utiliser votre identifiant unique quelque part dans le nom (au début ou au
milieu).
Nous examinerons plusieurs thèmes dans les pages qui suivent et nous vous donnerons
des recommandations.
Un point important est la possibilité d'utiliser le Factory ID (à partir de la mise à jour 8), qui
permet de baliser les éléments que vous possédez et d'empêcher leur modification
lorsque vous n'êtes pas connecté avec le même Factory ID.
Factory ID
Avec la mise à jour 8, toutes les données d'administration peuvent être balisées avec un
Factory ID.
Pour activer cette fonctionnalité, vous devez modifier le fichier nodelocal.js et autoriser
cette fonctionnalité.
Cela vous apporte deux avantages :

• Ce que vous développez sera protégé contre les modifications des clients ; Ils peuvent
seulement dupliquer ou renommer le développement si besoin.
• Vous pouvez facilement extraire tous les éléments liés à un Factory ID donné, dans un
seul patch.
Paramétrer le Factory ID partenaire
En tant que partenaire, vous pouvez définir votre Factory ID dans un profil Sécurité (si
votre fichier nodelocal.js autorise cette option).

Un utilisateur avec ce profil Sécurité peut indiquer "factory" sur des données.
Vous pouvez faire cela sur les entités principales du module Administration, et vous
pouvez indiquer "factory" pour des pages personnalisées.
Sage utilise cette méthode pour protéger des données livrées et pour empêcher le client
d'effectuer une mauvaise mise à jour. Les données peuvent être dupliquées ("Enregistrer
sous"), mais pas modifiées, ni supprimées.
Ci-dessous se trouve un exemple vous expliquant comment visualiser les éléments

marqués d'un Factory ID et le propriétaire lié, Sage dans ce cas.
Nous vous conseillons de donner à votre Factory ID un code commençant par (ou
incluant) votre identifiant unique.
Bonnes pratiques de nommage pour les données d'administration

Nous allons examiner les principales catégories de données que vous allez créer.
Pour toute autre catégorie non listée, l'objectif est le même : donner un nom qui ne produit
pas de conflit lors d'installation dans un dossier client où d'autres extensions partenaires
peuvent être présentes.
La meilleure solution est d'inclure votre identifiant unique dans le nom.
Entrées de menu, modules et sous-modules de menu

Nous devons prendre en compte qu'il existe deux manières de créer ces éléments :
• Une création directe en utilisant l'entité Syracuse,
• L'outil d'import,
et nous voulons adapter les règles dans un souci de cohérence.
L'outil d'import crée des entrées de menu uniquement pour les fonctions classiques et les
vignettes V6.
À partir de l'Update 9, la règle de nommage pour les éléments créés sur mesure ou les
éléments verticaux est la suivante (FUNCTION représente le code de la fonction) :
• SPE_X3_ERP_FUNCTION pour les fonctions Enterprise Management sur mesure

• SPE_X3_HRM_FUNCTION pour les fonctions Enterprise Management HR sur
mesure
• VER_X3_ERP_FUNCTION pour les fonctions d'add-ons ou verticales Enterprise
Management
• VER_X3_HRM_FUNCTION pour les fonctions d'add-ons ou verticales Enterprise
Management HR
Il n'est pas nécessaire d'ajouter votre identifiant unique car il devrait déjà être inclus
dans le nom de la fonction.
La différence entre le nommage vertical et spécifique pendant l'import est liée au

paramètre utilisé lorsque la copie est lancée :
• Si le rôle est associé à un profil Sécurité ayant un Factory ID, la case à cocher
Marquer les éléments importés en Factory est présente sur la page de
lancement.
Si cette case à cocher est sélectionnée, le préfixe de nommage "VER_" sera
utilisé ;
• Sinon, la règle de nommage qui s'applique est le préfixe "SPE_".
Cela signifie que durant l'exécution de cet outil, un seul type de nommage est utilisé,
indépendamment du nom des fonctions. Par exemple :
• VER_X3_ERP_ZFUNC pourrait être créé dans une exécution d'import si la case à
cocher est sélectionnée, même si la normalisation des fonctions verticales ne
devrait pas utiliser un préfixe Z.
• VER_X3_ERP_XFUNC pourrait être créé dans une exécution d'import si la case à
cocher n'est sélectionnée, même si la normalisation des fonctions sur mesure ne
devrait pas utiliser un préfixe X.
Pour conserver la cohérence globale, nous vous suggérons d'utiliser les mêmes règles si
vous créez une entrée de menu pour une fonction classique, au lieu d'utiliser l'outil
d'import.
Pour les fonctions Syracuse que vous êtes susceptible d'ajouter, il n'existe pas de
fonction d'import qui créera l'entrée pour vous. Vous devrez créer directement votre item,
sous-module ou module de menu.
La normalisation n'est pas encore définie, mais nous vous suggérons :
• D'insérer votre identifiant unique dans le code (au début ou au milieu) ;
• D'inclure le nom de votre add-on dans le titre ;
• D'utiliser le Factory ID pour baliser l'élément.

Pages d'authoring
Lorsque vous effectuez un authoring de pages, vous devez fournir :

• Un code : nous vous suggérons de commencer votre code par votre identifiant
unique (ou de placer cet identifiant dans le code) ;
• Titre et description : choix libre, le nom de votre add-on pourrait être inclus dans le
titre qui est la seule information vue par l'utilisateur final (le code n'est pas affiché)
;
• Enregistrer sous : Si vous choisissez "factory",
ce choix ne sera disponible que si :
o La fonctionnalité EnablePartnerID est paramétrée ;
o Votre profil Sécurité est défini par un Factory ID paramétré.
Le Factory ID associé à votre profil Sécurité sera paramétré pour l'élément (vous
n'aurez pas à saisir de valeur).

Autres données d'administration
Nous suggérons que :

• Vous commenciez votre codification par votre identifiant unique ;
• Ou que vous incluiez votre identifiant unique dans la clé.

Règles de développement
Pour empêcher les conflits techniques dus à la cohabitation d'extensions, un ensemble de

règles doit être respectées.
Dans ce chapitre :
• nous nous concentrerons sur les règles principales que vous aurez à appliquer ;
• nous aborderons certaines limitations qu'il vous faudra prendre en considération ;
• nous vous donnerons quelques conseils pour concevoir et tester vos
développements.
Tous les thèmes décrits sont disponibles à partir de la Version 7.
Principales règles de développement à appliquer
Actions sur champ

La plateforme vous permet de définir des actions sur champs dans les écrans.
Une fonctionnalité vous permet d'utiliser une action verticale (SPV) sur chaque
événement (init, contrôle, etc.) de chaque champ.
Toutefois, il ne peut y avoir qu'une seule action de ce type pour chaque champ.
Ainsi, pour empêcher les conflits, vous devez utiliser les actions de dictionnaire car, en
mode add-on, un dictionnaire est partagé par tous les partenaires.
De plus, dans le dictionnaire des écrans, le script vertical est un programme unique et ne
peut être partagé facilement par différents partenaires.
Le nom des actions de dictionnaire devrait commencer par votre identifiant et être protégé
par un code d'activité.
Cette règle s'applique à toute action que vous ajouterez dans un champ des écrans
standard.
Pour vos propres écrans, protégés par votre code d'activité, vous pouvez utiliser les
actions SPV lorsqu'il n'existe pas de verticalisation pour eux et que vous êtes le seul à
travailler sur le script vertical.

Utilisez uniquement des actions de dictionnaire pour vos propres actions sur des champs.
N'oubliez pas de paramétrer un code d'activité sur l'action dont le nom devrait également
commencer par votre identifiant unique.
Comment gérer la couche verticale avec modèle d'objet et points

d'entrée
Chacune des trois couches, spécifique, verticale et standard, est gérée par un script
séparé.

Dans chaque script, les développeurs utilisent les points d'entrée fournis par les différents
modèles dans lesquels ils travaillent.
Le code source du modèle, objet par exemple (qui est le plus utilisé), n'est pas fourni.
La documentation donne la liste des points d'entrée disponibles et fournit un ensemble de
variables que vous pouvez utiliser pour interagir avec le standard.
Il existe un seul script vertical pour une fonction.
Il ne pouvait donc pas être partagé facilement par différents acteurs et il fallait créer et
utiliser un programme d'aiguillage (géré manuellement) qui appelle de manière
séquentielle les scripts des différents partenaires.
Pour cela :
• Avant l'Update 8, vous deviez gérer le programme d'aiguillage manuellement
(cela provoquait beaucoup de problèmes) ;
• À partir de l'Update 8, le programme d'aiguillage est géré automatiquement par le
superviseur pour les objets et points d'entrée (ce qui est une importante
amélioration de simplification).
Couche verticale avec des objets

Auparavant, le nom du script vertical était défini dans l'objet (il devait correspondre au
nom du programme d'aiguillage qui autorise les appels verticaux).
Désormais, une case à cocher se trouve dans la définition de l'objet et si elle est
sélectionnée, cela signifie qu'il existe au moins un objet vertical.
Un bouton info vous donne les noms de tous les processus verticaux définis pour cet
objet.

La définition des scripts verticaux à utiliser sur un objet est déterminée dans la table des
points d'entrée.
L'ordre dans lequel les différents scripts devraient s'exécuter est également défini dans
cette table.
Attention :
• La table des points d'entrée est chargée comme un ensemble de variables
globales lorsque vous créez une session classique. Si vous modifiez la liste des
points d'entrée, vous devrez vous déconnecter et vous reconnecter pour que la
modification soit prise en compte.
• Lorsque la table est chargée dans la mémoire, un contrôle vérifie que le script
(adx) défini dans la liste de points d'entrée existe. Si ce n'est pas le cas sur le
dossier ou sur un des dossiers parents, le script n'est pas ajouté dans la table
mémoire. Tant que vous ne vous êtes pas déconnecté et que vous n'avez pas
recréé la table mémoire, le script ne s'exécute pas, même si vous l'ajoutez après
la création de session.
Comprendre les ordres d'exécution de différentes couches

La même logique s'applique pour tous les points d'entrée.
Le modèle appelle dans l'ordre suivant et s'ils existent :
• Le script spécifique ;
• Tous les scripts verticaux selon leur rang ;
• Le script standard.
Il existe deux variables globales utilisées pour contrôler l'exécution des différents scripts.
• GPV : empêche l'exécution de la couche verticale lorsque paramétrée à 1
• GPE : empêche l'exécution de la couche standard lorsque paramétrée à 1
Ces deux variables sont paramétrées à 0 par le standard avant l'exécution de la boucle
globale.
Puis :
• Si GPV est paramétrée à 1 dans le script spécifique, tous les scripts verticaux
seront ignorés sans s'exécuter (ce comportement devrait être validé au cas par
cas sur un site client).

• Si GPE est paramétrée à 1 dans le script spécifique ou dans l'un des scripts
verticaux, la couche standard ne s'exécutera pas (ce comportement est
exceptionnel, il est généralement adopté lorsque la couche standard doit
s'exécuter avant la couche verticale ou spécifique. Il n'est jamais recommandé de
passer la couche standard).
Important ! Attention, lorsque plusieurs scripts (un spécifique et possiblement

plusieurs verticaux) s'exécutent, la valeur de la variable GPE sera la dernière à être
paramétrée. C'est pourquoi, dans les cas d'interaction complexes, le comportement
doit être validé par le site client.
Cas complexes en exécution de points d'entrée

Lorsque l'un des scripts verticaux nécessite l'exécution préalable de la couche standard.
Exemple :
Trois scripts verticaux sont définis pour l'objet BPC.

Supposons que le script XY23BPC2 requiert, dans le point d'entrée PICKE, que le
standard soit d'abord exécuté.
Dans ce cas, vous aurez dans le script
$ACTION
Case ACTION
When “PICKE” : Gosub ETIQP
………
Endcase
Return
$ETIQP
# Execute the standard code first
Gosub ACTION From SUBPTH
GPE=1 :# Avoid to reexecute the standard
# Vertical code
……
……
Return
Dans ce cas, il est nécessaire que le troisième script vertical XX34PH78 s'exécute après.
Sur un site client, l'ordre d'exécution des différents scripts verticaux doit être élaboré en
fonction des besoins.

Si l'un des scripts verticaux nécessite que le standard soit exécuté d'abord, et que ce n'est
pas le cas pour les autres, ce script vertical doit être exécuté en dernier, et l'ordre
d'exécution doit donc être adapté.
Vérifiez également qu'un autre script vertical :
• ne paramètre pas GPE à 0 après que votre script l'a paramétré à 1. Dans ce cas,
le standard s'exécutera deux fois ;
• Ne s'exécute pas avant le standard.
Ce sont des cas exceptionnels et ils doivent être vérifiés sur un site client car il n'est pas
possible de gérer et d'anticiper toutes les combinaisons de scripts verticaux.
Remarque : Dans des cas vraiment exceptionnels, où l'ordre doit être différent en
fonction du point d'entrée, un des scripts verticaux doit être séparé pour répondre à ce
besoin spécifique sur le site client, car il n'existe aucune modélisation pour gérer cette
exigence.
Patching des points d'entrée à partir de l'Update 8
• Patching des points d'entrée :

L'ordre d'exécution n'est jamais modifié par un patch, mais lorsqu'un nouveau
point d'entrée est patché, l'ordre d'exécution est paramétré, si défini.
• En revalidation de dossier :
Le script vertical, lorsqu'il existe sur un objet, est automatiquement inséré dans la
table des points d'entrée.
Gérer la couche verticale avec d'autres modèles : programme

d'aiguillage
Avec les autres modèles, pour lesquels le programme d'aiguillage n'est pas créé
automatiquement, vous devrez gérer l'aiguillage manuellement.
D'un point de vue théorique, ce travail doit être fait pour les :
• Actions
• Consultations
• Modèles import / export
• États
D'un point de vue pratique, les consultations, les modèles d'import/export et les états sont
généralement dupliqués lorsque vous souhaitez les personnaliser. Il faut donc vous
concentrer principalement sur les scripts associés aux actions.
Pour ces différents éléments, il n'existe pas de couche verticale.

Le seul script disponible est le "Script spécifique" qui sera utilisé comme un aiguillage
polyvalent.

Prenons un exemple pour mieux comprendre.
Traitement d'aiguillage et traitements applicatifs
Exemple : Les add-ons X1 et X2 sont développés sur la Consultation core CSO :
X1CNSCSOSPE Traitement applicatif de

l'add-on X1
CNSCSOSPE
YCNSCSOSPE Traitement applicatif de
Traitement d'aiguillage l'add-on X2
Vous devez conserver un programme "neutre" en script spécifique : CNSCSOSPE par

exemple.
Ce programme ne sera pas patché, mais doit être livré séparément et géré manuellement.
Pour garder le même ordre d'appel pour chaque action du modèle, utilisez cette syntaxe
simple pour le programme d'aiguillage :
CNSCSOSPE
X1CNSCSOSPE
$ACTION
Gosub ACTION From X1CNSCSOSPE $ACTION

Case ACTION
Gosub ACTION From YCNSCSOSPE When “OUVRE” Gosub OUVRE
…
When Default
Endcase
Return
Pour différencier l'ordre des appels en fonction des actions, utilisez cette syntaxe :

CNSCSOSPE
X1CNSCSOSPE
$ACTION
Case ACTION
$ACTION
When “OUVRE”
Case ACTION
Gosub ACTION From X1CNSCSOSPE
When “OUVRE” Gosub OUVRE
Gosub ACTION From YCNSCSOSPE
…
When Default
When Default
Gosub ACTION From YCNSCSOSPE
Endcase
Gosub ACTION From X1CNSCSOSPE
Return
Endcase
Return
Cela permet de gérer l'appel de chaque script vertical (et spécifique).
Gérer la livraison de traitements d'aiguillage
• Créez un patch séparé pour tous vos traitements d'aiguillage.

• Dans le patch principal, ajoutez :
o Le code source des traitements d'aiguillage au sein d'un répertoire dédié
appelé "ADDSRC" ;
o Dans le fichier 'Lisez-moi', une liste de tous les noms de traitements
d'aiguillage et leur nom de traitement core correspondants.
o Dans le fichier 'Lisez-moi', l'explication concernant la nécessité de
modifier manuellement chaque traitement d'aiguillage en utilisant le
traitement code source correspondant livré dans le répertoire "ADDSRC",
si d'autres add-ons ou assets existent dans la couche verticale.
Patch principal Patch séparé
X1CNSCSOSPE (Remise1) CNSCSOSPE

Traitement applicatif de l'add-on X1 Traitement d'aiguillage
Ce patch est toujours intégré Ce patch sera intégré par le client si aucun
autre add-on ou asset n'existe sur les
mêmes fonctions core.
Sinon, ce patch ne pourra pas être intégré
pour éviter l'écrasement des traitements
existants. Les traitements d'aiguillage
doivent être mis à jour manuellement.
États de développement
Les états standards sont développés avec l'outil Crystal Report.
Voici quelques conseils pour le développement des états.

• Utilisez la charte de développement des états Crystal Report définis dans le centre
d'aide en ligne.
Développez un état à partir de l'un des états modèles suivants :

ATEMPLATE_RPT1 ou ATEMPLATE_RPT2.
• Le nom de l'état commencera par votre identifiant, et lorsque c'est possible, il aura
le même nom que le code de l'état de l'état du dictionnaire.
• Tous les états doivent se baser sur une source ODBC.
• Les états doivent être fournis par les langues que vous gérez, en tant que
partenaire, en sachant que l'anglais est obligatoire.
• Les états respecteront les règles de développement concernant la gestion des
autorisations.
Reportez-vous au support de formation.
Points d'attention
La plateforme présente des limites connues.
Nous essayons de dépasser ces limites, en particulier avec la nouvelle modélisation.

Cependant, aujourd'hui, vous devez faire attention aux points suivants avec les fonctions
classiques :
Nombre de colonnes dans une table Limité à 512.

Lorsque vous travaillez avec une table
standard proche de la limite, il est conseillé de
créer et gérer votre propre table
complémentaire pour éviter tout problème.
Longueur d’une ligne dans une table Limité à 8 Kb.
Même remarque. Si la table standard est
proche de la limite, il peut être intéressant pour
vous d'ajouter et de gérer votre propre table.
Nombre de sections dans un masque Limité à 15.
Vous devez ajouter un nouveau masque si
vous ajoutez plusieurs sections et et vous
rapprochez ainsi que la limite.
Dans tous les cas, l'authoring vous permettra
d'élaborer une mise en page qui répondre à
vos besoins.
Nombre de champs dans un masque Limité à 500 dans la définition (c'est déjà un
chiffre important).
Limité à 240 en validation (la limite sera
passée à 300 en U10 ou dans un patch de
U9).
Même remarque.

Interactions avec le standard
Éviter d'effectuer des modifications à la fonctionnalité de l'élément core, en particulier pour les
localisations, prévues pour coexister au sein du même dossier client. Il est important de garder à
l'esprit qu'un add-on est une solution pour améliorer et étendre la fonctionnalité core, et non pour la
contourner.
Points particuliers à se rappeler

• N'utilisez pas votre code d'activité pour modifier ou supprimer un élément core ;
• Ne désactivez pas de bouton, menu, champ, etc. ;
• Ne modifiez pas le comportement d'un bouton ou d'une menu ;
• Utilisez uniquement GPE=1 pour appeler directement le core mais pas pour l'éviter ;
• Utilisez un menu plutôt qu'un bouton dans une fenêtre core ;
• Utilisez votre propre écran dans une fenêtre core ou créer votre propre pop-up
complémentaire :
• Pour éviter le partage du même espace disponible sur des écrans core entre différents
add-ons installés au sein d'un même dossier client ;
• Ce type de conflit doit être géré par l'équipe de mise en œuvre du projet.
Faites attentions, lorsque vous complétez une fonction core. Si la couche verticale (ou la
couche spécifique dans certains dictionnaires) est déjà utilisée par add-on ou un asset
vertical, ne forcez pas le traitement d'aiguillage existant qui appartient à cet add-on
ou cet asset vertical.
Dans cette situation et pour vos développements futurs, vous devez utiliser la stratégie du
traitement d'aiguillage qui appelle votre propre traitement applicatif.
• Pour utiliser un point d'entrée, utilisez la stratégie du traitement d'aiguillage pour
aider la mise à jour des traitements d'aiguillage ;
• Créez un patch séparé pour ces traitements et placez un exemple de ce que devrait
être le traitement source dans un répertoire dédié appelé "ADDSRC" que vous livrez
avec le patch ;
• Complétez le fichier "lisez-moi" avec la référence des traitements d'aiguillage et le
traitement core correspondant.
Important ! Ne modifiez jamais l'usage d'un élément core.
Test
Pour tester une fonction core :
• Vérifiez la fonctionnalité globale de la fonction core, une fois que les add-ons et les
assets ont été ajoutés ;
• Vérifiez le traitement d'aiguillage dans la couche verticale, et même dans la couche
spécifique pour certains dictionnaires dans les points d'entrée ;
• Vérifiez que les actions de champ coexistantes fonctionnent ensemble dans un écran core
;

• Vérifiez que les menus et boutons fonctionnent pour plusieurs add-ons dans une fenêtre
core.
• Exemple : éviter le même code menu pour deux add-ons de la même fenêtre core ;
• Vérifiez que les capacités de la plateforme n'ont pas été dépassées (nombre de champs
dans une table, nombre d'onglets dans une fenêtre, etc.).

Outil de licence partenaire
À partir de l'Update 8, vous pouvez, en tant que partenaire, gérer les licences pour votre
add-on et contrôler l'accès avec la même structure qu'en standard.
La règle principale est de définir la structure de l'application qui est décrite dans un fichier
appelé Fichier de règles, et de donner accès aux fonctions ou services avec les
limitations décrites dans un fichier de licence.
Le programme de contrôle utilisera le concept de badges et de fonctions clés, et
autorisera un accès complet aux fonctions clés si le nombre d'utilisateurs concurrents du
badge défini dans la licence n'est pas dépassé.
Les licences d'add-ons sont importées vers le serveur comme une licence standard.
L'utilisation de cet outil est optionnelle. Vous pouvez protéger vos add-ons avec vos
propres mécanismes.
L'outil de licence est une application autonome et inclut un mécanisme permettant de

créer des clés d'encodage privées et publiques.
Si vous souhaitez utiliser cet outil, qui vous est fourni gratuitement par Sage, vous devez
en faire la demande auprès de votre équipe support.
Cet outil est léger, peut être installé sur tous les bureaux avec un paramétrage, est
disponible en anglais et possède sa documentation.
Après l'installation, vous devrez créer une paire de clés d'encodage et suivre le
processus.
Veuillez vous reporter à la documentation sur l'Outil de licence partenaire disponible sur le
Centre d'aide en ligne.
Fichier partenaire
Extrayez votre clé publique et envoyez-la à l'ADV en demandant que votre fichier
partenaire soit signé par Sage.
Vous recevrez un fichier partenaire signé de la clé privé de Sage.
Ce fichier partenaire inclut :
• Votre identifiant en tant que partenaire ;
• Votre adresse ;
• Votre clé publique ;
• Une plage de codification autorisée pour vos solutions verticales ;
• Une signature électronique par Sage qui scelle votre fichier partenaire.

Chargez votre fichier partenaire, vous êtes prêt !
Créer vos fichiers de règles

Un fichier de règles définit un produit et sa politique de protection :
• Ce qui est inclus ;
• Ce que la licence doit contrôler ;
• Les fonctions clés ;
• Tout paramètre qui devrait être vérifié ;
Un fichier de règles fait référence à un produit Sage standard et peut avoir plusieurs
versions.

Créer un fichier de licence
Un fichier de licence est accordé à client final par un partenaire.
Il inclut les options, les langues, le nombre d'utilisateurs concurrents par badge, les
valeurs paramètres.
Il est lié à un fichier de règles.
Il peut s'agir d'une licence de démonstration avec une date de validité limitée.

Programme de contrôle des développements
Introduction
Une observation commune concernant la technologie est qu'elle permet d'effectuer

librement de nombreuses modifications et de les protéger raisonnablement par des codes
d'activité spécifiques ou verticaux.
D'un autre côté, le processus de patching de cette technologie est lourd et difficile à
automatiser, en particulier parce que les conflits et erreurs relatifs à la liberté donnée
nécessitent des rectifications manuelles lorsqu'ils se produisent.
Cela est particulièrement critique pour la mise en œuvre Cloud parce que les clients
souhaitent dans le même temps :
• Pouvoir avoir des développements sur mesure ou verticaux sur ces environnements ;
• S'assurer que l'application des patchs standard peut se faire automatiquement sans
conflits.
C'est pourquoi il est nécessaire de restreindre la manière par laquelle les partenaires
peuvent créer des développements sur mesure et/ou verticaux. Cela est possible en
définissant des règles donnant des normes, mais aussi en restreignant les modifications
de dictionnaire. Ces règles sont non seulement obligatoires en mise en œuvre Cloud,
mais elles sont également critiques pour garantir à tous les clients des procédures de
mise à niveau sans problème.
Un outil de vérification qui s'exécute sur les environnements existants a été créé. Cet outil
est amélioré dans la mise à jour 10 et ce document décrit toutes les règles qui seront
vérifiées par cette dernière version.
Cet outil vérifie uniquement la cohérence des dictionnaires (métadonnées). À l'avenir,
nous comptons améliorer l'outil pour vérifier les sources également.
Dans la conception actuelle du dictionnaire, il peut être difficile de suivre ces règles dans
certains cas, en particulier avec le Code classique. Le code Syracuse a été conçu pour
permettre le respect des règles dans ces cas.
Lancer l'outil
L'outil est fourni comme une fonction classique appelée ACTLSPE. Il inclut une fenêtre
permettant de saisir des paramètres supplémentaires. Il doit être exécuté sur le dossier
dans lequel le développement vertical et/ou sur mesure a été effectué.
Les paramètres à renseigner sont :
- Les dossier à tester ;
- Le dossier de référence (en général le dossier d'application).

- Des plages optionnelles pour les éléments spécifiques ou verticaux (noms et
numéros de menus locaux et tables diverses).**
Le script s'exécute et renvoie un fichier trace avec quatre niveaux d'informations :

• Information** : décrit les modifications sûres qui pourraient avoir un impact si
effectuées différemment par un autre fournisseur (par exemple, augmenter la
longueur d'un type de données standard). Il s'agit juste d'un rappel concernant des
points à vérifier lorsque plusieurs développements verticaux ou sur mesure sont
installés ensemble dans un environnement donné ;
• Avertissement : décrit les modifications qui ne sont pas considérées comme des
erreurs, mais qui pourraient le devenir (par exemple, si les dictionnaires sont
améliorés afin de faciliter la mise à niveau en fournissant un autre moyen de
développer certaines fonctionnalités) ;
• Erreur : décrit une erreur dans la conception qui empêchera le bon déroulement de
la mise à niveau automatique. Cela évite une installation sur les environnements
cloud, et il est possible de gérer les environnements sur site (cela rend le processus
de mise à niveau plus difficile car vous aurez à vérifier ces éléments) ;
• Erreur fatale : décrit une erreur qui empêche le bon déroulement d'une mise à
niveau (c'est le cas pour la modification d'élements du dictionnaire, par exemple).
Remarque : ** Ces éléments sont disponibles à partir de l'Update 10
Détail des règles
Convention de nommage
Le premier point important est que les conventions de nommage sont données afin de
gérer les conflits potentiels entre les partenaires qui fournissent des développements ou
add-ons verticaux. Chaque partenaire souhaitant développer de telles fonctionnalités
reçoit des plages de codification. La règle est la suivante :
• Les noms de plages d'add-ons commencent par X ;
• Les noms de plages verticales commencent par Y ;
• Les noms de plages sur mesure commencent par Z.
Cette règle s'applique uniquement pour le niveau le plus élevé d'imbrication associé à
l'élément. Par exemple :
• Un écran vertical doit suivre la règle de nommage, mais les sous-éléments (champs)
peuvent être nommés librement ;
• Sur un écran standard, les champs verticaux ajoutés doivent suivre la règle de
nommage ;
• La même règle s'applique aux colonnes et indices de tables, noms de collection ou
méthodes sur les classes et représentations, etc.
Les éléments contrôlés par la règle de nommage sont: les tables, les écrans, les fenêtres,
les objets, les consultations, les actions, les types de données, les classes, les
représentations, les codes d'activité, les définitions de paramètres, les scripts et les états.
Les sous-éléments d'éléments standard sont vérifiés selon ce qui a été défini auparavant.
Les tables diverses et menus locaux ont des plages numériques.
Certains éléments de dictionnaires sont considérés comme étant non standard bien qu'ils
ne commencent ni par X, Y ou Z :

• Les fonctions commençant par CONSX, CONSY, CONSZ (consultations) ;
• Les fenêtres commençant par DCNSX, DCNSY, DCNSZ, FCNSX, FCNSY, FCNSZ
(associées à des consultations non standard) ;
• Les scripts commençant par SPE (les scripts commençant par SPV doivent être
renommés à partir de la mise à jour 8, voir ci-après).
Les éléments de dictionnaire et les scripts commençant par W sont des éléments
générés. Il est de ce fait interdit de créer directement ces éléments (ils sont normalement
générés à partir d'un modèle dont le nom ne commence pas par W).
Tout élément suivant ces règles de nommage est un élément non standard qui doit être
protégé par un code d'activité commençant par X, Y ou Z. Tout élément qui ne respecte
pas la convention de nommage et qui n'est pas présent dans le dossier d'application est
un élément non standard ajouté qui ne suit pas la convention de nommage (c'est une
erreur).
Remarque : Les éléments de dictionnaire commençant par A sont des éléments

superviseur. Ces éléments suivent des règles particulières (les modifier entraîne
généralement une erreur fatale).
Restrictions sur les dictionnaires classiques

Les restrictions suivantes s'appliquent aux dictionnaires classiques :
Élément de dictionnaire Opération Motif et commentaires
Définition de table, masque, Paramétrer un code d'activité Affecter un code d'activité

fenêtre, objet, action spécifique spécifique désactivera toute
standard (entête) Remplacer un code d'activité mise à jour standard de ces
standard par un autre s'il entités.
existe
Colonnes, champs, Modifier leurs caractéristiques Cela empêche les évolutions
propriétés standards dans même s'ils sont protégés par standard à venir. Cette règle
les tables, masques, un code d'activité est plus restrictive que les
classes, représentations recommandations
standard précédentes. Les
modifications peuvent être
effectuées sur les types de
données standard, et les
modifications sur les
localisations et titres sont
effectuées différemment (par
authoring). Des contrôles plus
restrictifs peuvent être
effectués sur les scripts.
Colonne standard dans une Modifier son type de données, L'impact ne peut être mesuré
table la longueur correspondante sur le code standard. Les
pour les types de données variables internes peuvent
génériques (L, DCB, A, etc.), être définies en fonction du
ou le menu local associé type de données de la

colonne standard. Si la taille
d'une colonne doit être
élargie, le type de données
générique doit être remplacé
par un type de données non
générique.
Ce type de demande doit
être effectué comme une
création de point d'entrée
(avec la même priorité).
Définition de table diverse Réduction de la longueur du L'impact ne peut être mesuré
standard code, ou modification de la sur le code standard.
longueur si non autorisée Une case à cocher définit si la
longueur peut être modifiée.
Restrictions sur les dictionnaires Syracuse

Les restrictions suivantes s'appliquent aux dictionnaires Syracuse :
Classes, Paramétrer un code d'activité Paramétrer ce code d'activité

représentations spécifique à "faux" désactiverait l'entité
standard Remplacer le code d'activité standard correspondante.
par un autre s'il existe Affecter un code d'activité
spécifique désactivera toute
Modifier les caractéristiques d'une mise à jour standard de ces
méthode standard entités.
La méthode peut être utilisée
par des entités standard.
Ajouter un paramètre ou
modifier le type de retour
casserait le code standard.
Collections Modifier leurs caractéristiques L'impact ne peut être mesuré
standard dans les sur le code standard.
classes et
représentations
Propriétés standard Modifier son type de données, la L'impact ne peut être mesuré
dans les classes et longueur correspondante pour les sur le code standard.
représentations types de données génériques (L, DCB, Si la taille d'une colonne doit
A, etc.), ou le menu local associé être élargie, le type de
données générique doit être
remplacé par un type de
données non générique.
Ce type de demande doit
être effectué comme une

création de point d'entrée
(avec la même priorité).
Scripts standard Installer un script standard modifié Si le script standard évolue,
dans un dossier l'évolution ne sera pas prise
en compte.
Modifications autorisées sur les dictionnaires classiques

Les restrictions suivantes s'appliquent aux dictionnaires classiques :
Champ standard dans Paramétrer un code d'activité Les champs désactivés sont
écran standard spécifique sur un champ standard invisibles mais existent
pour le rendre spécifique Un toujours. Cela doit être éviter
risque existe si le code d'activité pour empêcher tout impact
est paramétré à Inactif. Un bon sur le standard.
moyen de modérer ce risque est
de rendre le code d'activité
dépendant de TRU.
Écran standard Ajouter des champs ou sections
spécifiques
Fenêtre standard Ajouter des onglets et boutons
spécifiques, affecter des codes
d'activité standard aux boutons
standard pour les désactiver
Toute entité (fenêtre, Créer un nouvel élément
écran, table, objet, spécifique
action, menu local, table
Désactiver une action
diverse, etc.)
Affecter des noms de scripts standard en affectant GPE est
spécifiques ou verticaux dans le risqué et devrait être interdit ;
dictionnaire mais cela n'est pas contrôlé
pour le moment.
Modifications autorisées sur les dictionnaires Syracuse

Les restrictions suivantes s'appliquent aux dictionnaires Syracuse :
Classes et Ajouter des propriétés, opérations,

représentations méthodes spécifiques
standard
Ajouter des collections spécifiques

Affecter une collection à une classe
spécifique (informations de mapping
incluses)
Ajouter des scripts spécifiques et

verticaux
Classes, Créer classes et représentations
représentations
spécifiques
Classes et Ajouter des propriétés, opérations,

représentations méthodes spécifiques
standard
Ajouter des collections spécifiques
Affecter une collection à une classe

spécifique (informations de mapping
incluses)
Ajouter des scripts spécifiques et
verticaux
Règles supplémentaires ou commentaires
Les vérifications supplémentaires suivantes sont effectuées :

• Comme expliqué précédemment, TOUTE MODIFICATION EFFECTUÉE SUR DES
TABLES SUPERVISEUR est considérée comme une erreur fatale.
• L'outil de cohérence vérifie uniquement les menus locaux (i.e. : pas le chapitre dédié
aux messages). Les trous sont signalés en erreur (i.e. : le fait que le choix N et le
choix N+2 soient définis sans un choix N). La vérification est effectuée uniquement
pour les langues gérées dans le dossier.
• Les éléments non standard et qui ne sont pas protégés par un code d'activité non
standard sont affichés en erreur.
• Les éléments non standard et qui ne sont pas nommés dans la plage de codification
non standard sont affichés en erreur.
Les éléments de dictionnaire commençant par W sont exclus du fichier trace (le système
considère que la cohérence a déjà été vérifiée sur la source des éléments de la
génération).
Ajouter des boutons aux fenêtres standard est parfois nécessaires, mais cela crée des
problèmes que nous ne pouvons résoudre correctement :
• Seules quatre valeurs sont disponibles pour les extensions non-standard ;
• Les conflits entre les extensions verticales ne peuvent être résolus et
nécessitent un contrôle particulier lorsque plusieurs extensions verticales sont
installées ensemble.
Pour les normalisations effectuées pour la Version 7, il est possible de créer autant de
liens que nécessaires, et leur nom est codifié.

Une recommandation particulière devrait être faite pour la création de pièces
automatiques spécifiques. Les bonnes pratiques seraient de les dupliquer et les
renommer afin de gérer plus facilement leur mise à niveau en utilisant des outils de
comparaison. Les paramètres sont disponibles pour réaffecter le code de pièce
automatique utilisé lorsqu'une opération de comptabilisation est effectuée.

Emballage
Cartographie de votre add-on

La plateforme technologique de développement est compatible avec :
• Les systèmes de bases de données Oracle et MSSQL-Server ;
• Les systèmes d'exploitation Windows, AIX, Linux.
Même si la plateforme vous permet de prendre en charge tous ces systèmes, elle
nécessite une validation, et votre choix commercial peut être de la restreindre à une cible
dédiée.
Tous les messages et textes sont stockés dans des fichiers dédiés.
Un processus et des outils existent pour traduire l'application.
Un add-on doit être traduit et livré au moins en anglais et dans la langue locale gérée par
le partenaire.
La cartographie de votre add-on devrait donnée :

• Une courte description ;
• Sa disponibilité concernant :
o Les plateformes prises en charge ;
o Les bases de données prises en charge ;
o Les langues prises en charge ;
• Sa compatibilité certifiée avec la liste Version/Mise à jour/Patch du produit.
Règles de qualité pour la documentation

En tant que partenaire estimé de Sage, il est de votre responsabilité de fournir la documentation
liée à votre add-on.
Les documentations suivantes constituent le minimum requis :
• Guide opérateur comprenant la documentation fonctionnelle ;
• Guide d'installation et de paramétrage.
Vous pouvez également utiliser l'outil de documentation inclus dans l'application pour livrer une
aide en ligne pour les champs et fonctions.
Avec chaque patch, il est recommandé de livrer un fichier changelog.
Veuillez vous reporter à la documention Comment écrire la documentation disponible sur le Centre
d'aide en ligne pour en savoir plus sur l'outil de documentation livré avec la plateforme.

Patching
Si vous créez un patch, il existe un type de patch dédié pour les add-ons.
Vous devez sélectionner cette option pour préserver toute action SPV potentiellement
développée sur un asset dans la couche verticale. Ainsi, si un vertical est présent dans le
dossier client où l'add-on a été installé, les actions SPV seront préservées. Comme un
add-on utilise une action de dictionnaire, ce n'est pas un problème.
Le nom des fichiers patch devrait suivre des règles de nommage pour bénéficier de
contrôles de séquence automatiques fournis par la plateforme.
La règle de nommage des fichiers de patch est la suivante :
<AddOnId>_<AddOnPatchNumber>_<X3RequiredPatchLevel>_<X3Version>.dat
• AddOnId : identifiant de l'add-on (ne doit pas être P, réservé pour les patchs
Sage standard)
• AddOnPatchNumber : numéro d'ordre de séquence utilisé pour identifier
divers fichiers de patch d'add-onsx
• X3RequiredPatchLevel : numéro d'ordre de séquence utilisé pour identifier
divers fichiers de patch d'add-ons
• X3Version : version du produit avec laquelle la liste de patchs d'add-ons est
compatible
De nombreuses informations sont disponibles dans le Centre d'aide en ligne ici.
Chaque version de package devrait contenir les éléments suivants :

• Un ensemble de fichiers de patch dans un répertoire 'FILPATCH' ;
• La documentation en ligne qui devrait être livrée dans un répertoire de fichiers patchs
séparé ;
• Un répertoire contenant des exemples de codes sources de traitements d'aiguillage
(le répertoire recommandé est 'ADDSRC') ;
• La documentation générale pour l'add-on ;
• En option : Dossier de démonstration
• Note : tout utilitaire patché sous la forme d'un EXE doit être réexécutable.
Important ! Le traitement d'aiguillage doit être livré dans un patch séparé.

Si vous sélectionnez Vertical, toutes les actions SPV sont supprimées et seules les
actions qui se trouvent dans votre patch sont acceptées. Vous pouvez uniquement
sélectionner ce type de patch pour un développement spécifique à un client qui sera
installé avec toutes les interactions à gérer.
Maintenance et support
Le développeur de l'add-on doit gérer le processus de maintenance de l'add-on. Dès
qu'une liste de patchs standard est livrée, le développeur doit vérifier que le dernier
package d'add-on est compatible avec la nouvelle liste de patchs. Si ce n'est pas le cas,
une nouvelle version de l'add-on doit être fournie sous un mois. Les informations de
compatibilité entre les packages d'add-ons et les listes de patchs standard doivent être
communiquées par le partenaire.
Le développeur de l'add-on doit également fournir le support pour ses propres add-ons.
Le développeur fournira dans la version suivante du pack des corrections aux problèmes
de l'add-on signalés par les clients. Des correctifs peuvent également être fournis en
fonction de la gravité du problème :
• Pour un problème mineur : pas d'action ;
• Pour un problème majeur : livrer un correctif au client concerné (si nécessaire) ;
• Pour un problème important/bloquant ayant un impact sur plusieurs clients : livrer un
correctif aux clients concernés et publier une nouvelle version du pack de l'add-on.

www.sage.com
© 2018 The Sage Group plc, ou ses partenaires, Tous droits réservés. Sage, les logos Sage et les noms des produits et
services Sage mentionnés dans les présentes sont des marques commerciales de The Sage Group plc ou de ses
partenaires. Toutes les autres marques commerciales sont la propriété de leurs sociétés respectives.

DevelopRules Forextensions

Transféré par

Informations du document

Titre original

Copyright

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 :

DevelopRules Forextensions

Titre original :

Transféré par

Droits d'auteur :

Développer des extensions

L'objectif de ce guide est d'expliquer les règles de développement à appliquer pour

Il s'applique aux solutions basées sur la plateforme technologique commune fournie

Développer des extensions Page 2 sur 43

Éléments ajoutés dans une entité standard 10

Nouvelle entité définie dans le dictionnaire 11

Menus locaux et tables diverses 12

Principales règles de développement à appliquer 18

Interactions avec le standard 27

OUTIL DE LICENCE PARTENAIRE 29

Créer vos fichiers de règles 30

Créer un fichier de licence 31

PROGRAMME DE CONTROLE DES DEVELOPPEMENTS 33

Développer des extensions Page 3 sur 43

Détail des règles 34

Cartographie de votre add-on 40

Règles de qualité pour la documentation 40

Développer des extensions Page 4 sur 43

La plateforme vous permet de développer des extensions pour Enterprise Management. Il

Les développements sont stockés et isolés dans trois couches différentes.

• Standard : développés et maintenus exclusivement par Sage

Développer des extensions Page 5 sur 43

Éléments V6 (Remise1) A partir de V7

Code objet 3 caractères 8 caractères

Abréviation table 3 caractères 7 caractères

Abréviation masque 4 caractères 8 caractères

Type de données 3 caractères 8 caractères

Développer des extensions Page 6 sur 43

Menus locaux 10 000 menus 32 000 menus

Tables diverses 10 000 tables 32 000 tables

Les codifications réservées, les règles de développement renforcées, le programme de

Développer des extensions Page 7 sur 43

Add-on 1 Add-on 2 Asset 1 Asset 2

Pour répondre à ce nouveau besoin d'installer différentes

Développer des extensions Page 8 sur 43

Les nouvelles plages de nommage sont donc :

À partir de l'Update 8, nous encourageons fortement les partenaires à utiliser le Factory

Remarque : Il n'existe pas de limite de taille de codification pour les identifiants

Développer des extensions Page 9 sur 43

Éléments ajoutés dans une entité standard

Convention que vous pouvez utiliser :

Développer des extensions Page 10 sur 43

Nouvelle entité définie dans le dictionnaire

Pour les sous-éléments, comme les colonnes,

Développer des extensions Page 11 sur 43

Exception : Lorsqu'un programme d'aiguillage est nécessaire (voir définition ci-dessous),

Développer des extensions Page 12 sur 43

Cela vous apporte deux avantages :

Paramétrer le Factory ID partenaire

Développer des extensions Page 13 sur 43

Ci-dessous se trouve un exemple vous expliquant comment visualiser les éléments

Bonnes pratiques de nommage pour les données d'administration

Entrées de menu, modules et sous-modules de menu

Développer des extensions Page 14 sur 43

La différence entre le nommage vertical et spécifique pendant l'import est liée au

Développer des extensions Page 15 sur 43

Lorsque vous effectuez un authoring de pages, vous devez fournir :

Développer des extensions Page 16 sur 43

Nous suggérons que :

Développer des extensions Page 17 sur 43

Pour empêcher les conflits techniques dus à la cohabitation d'extensions, un ensemble de

Tous les thèmes décrits sont disponibles à partir de la Version 7.

Principales règles de développement à appliquer

Actions sur champ

Développer des extensions Page 18 sur 43