Les surcharges multiples
- 1 C’est quoi la surcharge multiple
- 2 Pourquoi mettre en œuvre la surcharge multiple
- 3 Exemple fictif de surcharge multiple
- 4 Les recommandation de développement pour faciliter la surcharge multiple
- 5 Les éléments techniques en surcharge multiple
- 5.1 Le fichier OVERWRITE.TXT
- 5.2 Les implicites
- 5.3 Les éléments de surcharge
- 5.3.1 Compléments concernant les sources/objet/surcharge pour le cas des masques écran/imprimante
- 5.3.2 Compléments concernant les xxTMFICSQL
- 5.3.3 Compléments concernant l’empilement des couches
- 5.3.4 Compléments concernant les dictionnaires
- 5.3.5 Compléments concernant le FHSQL
- 5.3.6 Compléments concernant XWin et l'éditeur de dictionnaires
- 5.4 Le fichier DHOS
- 6 Synchronisation des dictionnaires
- 7 Illustration de la surcharge multiple (vidéos et code source)
- 8 Mise en oeuvre dans le SaaS
- 8.1 1. Déclaration de l’add-on (par le partenaire éditeur de l’add-on)
- 8.2 2. Publication d'un add-on sur un site client (par le partenaire du client)
- 8.3 3. Ajout de l’add-on dans le site client (par le partenaire du client)
- 8.4 4. Fichier FHSQL en cas de dictionnaire complémentaire ou de fichier de tables complémentaires (par le partenaire éditeur de l’add-on)
- 8.5 5. Fichier Overwrite.txt (par le partenaire du client)
- 8.6 6. Spécifiques de la couche client (par le partenaire du client)
- 8.7 7. Synchronisation des dictionnaires (par le partenaire du client)
- 9 Complément de mise en oeuvre pour la plateforme divalto one
- 10 Migration de version en surcharge multiple
C’est quoi la surcharge multiple
L'ERP Divalto permet nativement la surcharge.
C'est le terme employé pour désigner la faculté de Divalto à modifier le comportement du logiciel ou de lui ajouter des comportements via un développement sur la base de l'ERP standard.
Autrement dit, c'est la possibilité d'ajouter/modifier/supprimer des données, des traitements ou des interactions avec l'utilisateur à l’ERP sans en altérer les fonctions de base.
La surcharge multiple va permettre d'activer un mode d'exécution de l'ERP particulier, dans lequel plusieurs surcharges faites de manière indépendante vont venir s’empiler en couches, apportant ainsi les ajouts de chacune des couches de surcharge avec un minimum de travail et de développement, puisque chaque couche reste indépendante des autres couches ; et ce à la fois sur la base de données et sur les traitements.
La surcharge multiple permet aussi d’augmenter la capacités des zones de surcharges prévu a cette effet (Zone U). Cette capacité de surcharge multiple est dite ‘multiple’ même dans une situation de non multiplicités des couches, par exemple en apportant une couche unique de verticalisation ou localisation.
Pourquoi mettre en œuvre la surcharge multiple
La surcharge multiple apporte un gain de temps et d'efficacité lorsque des surcharges déjà existantes sont requises pour répondre aux besoins d'utilisation ERP d'un client.
Il devient possible de réutiliser des couches de surcharge, et d’en empiler plusieurs, Sans forcément avoir la maîtrise totale d'une couche intermédiaire. On peut donc imaginer utiliser une couche de surcharge développée par quelqu'un d'autre dans un autre contexte client.
De plus, la surcharge multiple est associée à la zone de surcharges (Zone U) extensible, qui permet de dépasser la taille fixée à l’origine.
Exemple fictif de surcharge multiple
L'ensemble des exemples qui vont suivre sont basés sur le cas suivant (cas fictifs, aucune ressemblance avec des entreprises existantes)
Surcharge A : Maroquinerie
Prenons une entreprise d’un métier particulier comme la Maroquinerie.
Ce métier nécessite de marquer les articles qui sont en cuir, afin d’imprimer un texte spécifique aux articles en cuir sur les pièces commerciales.
Un développement spécifique peut donc être fait dans un esprit de “verticalisation de l’ERP à un métier”, avec ajout de champs dans les écrans et modification de traitement d’impression.
Une entreprise du métier de la maroquinerie peut utiliser cette surcharge pour répondre à ses besoins
Surcharge B : Italie
Prenons une entreprise qui a une agence en Italie.
Cette localité nécessite d’appliquer des règles locales, notamment une localisation AOP qui interdit de vendre des produits hors Italie, et cette restriction doit apparaitre sur les pièces commerciales.
Un développement spécifique peut donc être fait dans un esprit de “localisation ERP à un pays”, avec ajout de champs dans les écrans et modification de traitement d’impression
Une entreprise du métier de la maroquinerie peut utiliser cette surcharge pour répondre à ses besoins
Surcharge finale : le cas Borsetta
L’entreprise Borsetta est une entreprise de maroquinerie italienne
Pour répondre a ses besoins, il y a 2 possibilités principales:
inventer une nouvelle couche de surcharge Borsetta en copiant les spécificités de la maroquinerie et de l’Italie, et si besoin y adjoindre de spécificités client ; toutes les surcharges se trouvent donc mélangées
utiliser la surcharge multiple pour empiler les couches Maroquinerie et Italie, et si besoin y adjoindre une couche spécifique client ; chaque couche reste autonome, et peut évoluer de manière séparée
C’est donc ici que la surcharge multiple apporte des réponses techniques qui permettent de faciliter, accélérer et sécuriser les développements de spécifiques, en séparant des couches qui restent autonome
Le gros avantage est la maintenance des couches, car une couche comme la Maroquinerie pourra évoluer pour apporter plus de fonctionnalités, ou corriger des anomalies, et venir s’insérer sans que les autres couches ne nécessitent de modification
(Attention, il y a des restrictions possibles, comme par exemple le nommage des champs qui doivent rester avec des nom différents dans toutes les couches)
Surcharge finale en mode surcharge multiple Borsetta
On choisit de répondre aux besoins Borsetta par la surcharge multiple. Cela implique
que les couches qui entrent dans un empilement de surcharges vont devenir des ADD-ON
que l’on crée une couche pour porter les spécificités du client et les adaptations de l’empilement des couches
La surcharge multiple fonctionne en cloud, permettant même l’utilisation de couches provenant d’un autre auteur de surcharge. Les add-on sont alors en lecture seule via des chemins cloud
Illustration avec 2 add-ons (italie et maroquinerie), prêt à recevoir une couche client supplémentaire.
Les recommandation de développement pour faciliter la surcharge multiple
Pour que les couches de surcharge multiple s’imbriquent au mieux, il y a quelques consignes lors du développement des couches
Les surcharge de TT ou TM
lors de l'écriture de surcharge d’un fonction/procédure standard xxx , il faut mettre l’appel à standard.xxx à l’intérieur. C’est ainsi que les couches vont pouvoir s’empiler naturellement
tout code spécifique doit être externalisé dans un module de type TM ou TT à part, avec uniquement un appel a une fonction depuis la fonction/procédure standard xxx. Ceci afin de pouvoir agir lors de l’empilement des couches sans casser la surcharge xxx
Exemple
SURCHARGE GTUMPCE : CODE DE DEPART
Procedure Piece_Imp_Ligne_Read_ap
;
beginp
If SOC.MaroImprCuirFl = OUI and ART.MaroCuirFl = OUI
G4.Lib(2) = SOC.MaroImprCuirTxt
XMiPrint (MZ.MICLE, 19)
Else
G4.Lib(2) = "Il est en cuir"
XMiPrint (MZ.MICLE, 19)
EndIf
endp
CE QUI NE VA PAS
Il n’y a pas d’appel a standard.Piece_Imp_Ligne_Read_ap ! Cela va donc bloquer l’empilement des couches
Le code est directement dans la fonction/procedure de surcharge
CE QU’IL FAUT CHANGER
créer un module de type TM ou TT séparé, qui contient le code spécifique à la surcharge
appeler le standard.
appeler la fonction spé
MODULE DEDIE : MAROTMPCE
Procedure AjoutTexteMaroquinerie
beginp
If SOC.MaroImprCuirFl = OUI and ART.MaroCuirFl = OUI
G4.Lib(2) = SOC.MaroImprCuirTxt
XMiPrint (MZ.MICLE, 19)
Else
G4.Lib(2) = "Il est en cuir"
XMiPrint (MZ.MICLE, 19)
EndIf
endp
SURCHARGE GTUMPCE : CODE D'ARRIVEE
Procedure Piece_Imp_Ligne_Read_ap
;
beginp
;en surcharge on appelle par défaut la couche supérieure
standard.Piece_Imp_Ligne_Read_ap
;mon code spé est dans un module séparé
maropmpce.AjoutTexteMaroquinerie
endp
Les dictionnaires
Les dictionnaires des couches add-ons seront rangés dans des sous-dossier du fhsql.
Ceci afin d'éviter les conflits de nommage : le dictionnaire GTFDD va exister dans chaque couche, et il ne peut être renommé ; il faut donc les ranger dans des sous-dossiers.
Il et recommandé de donner aux sous-dossiers le même nom que l’add-on.
Pour rappel, pour qu'une Zone-U soit extensible, il faut que le paramètre <Zone U> soit à <Oui> dans les propriétés de la donnée.
Les éléments techniques en surcharge multiple
Le fichier OVERWRITE.TXT
Le fichier nommé OVERWRITE.TXT a les caractéristiques suivantes
est un fichier texte simple (encodage à éviter : UTF-8-BOM), éditable avec un bloc-notes ou XWIN
sa présence dans les implicites active le mode surcharge multiple lors de l’exécution des programmes Diva ERP
sert de référence pour la synchronisation des dictionnaires (mise à jour du schéma de base de données)
doit indiquer les différentes couches (3 dans notre exemple) et l’ordre d’empilement (selon ordre d’apparition dans le fichier), en indiquant la couche finale et les couches add-on
permet de donner les chemins vers les autres couches (en absolu ou relatif)
N’a pas besoin d’exister dans TOUTES les couches qui sont empilées, chaque couche détermine s’il est nécessaire d’en avoir ou pas ( débordement de la zone U par exemple ), les contenus seront bien sur différents couche par couche
doit être placé dans les IMPLICITES dans le dossier FICHIERS pour le cloud mais peut être à la racine des spécifiques en Onprem en ajoutant le chemin dans les implicites
une synchronisation de dictionnaire vie XPSql doit trouver ce fichier pour gérer la fusion des dictionnaires de chaque couche. Le fichier overwrite sera recopié dans le répertoire de la base de données
il ne doit en exister qu’un seul exemplaire dans l’arborescence des implicites final/client. Il permet à XlanSql d'avoir les bons dictionnaires en ligne
tous les sources d'un add-on ne sont pas forcément livrés par l'éditeur de l'add-on. Il est néanmoins impératif que les sources des dictionnaires de données (.dhsd) soient livrés.
En plus d’activer le mode surcharge multiple, ce fichier déclenche la capacité des dictionnaires DHSD à étendre la zone U au-delà de la limite de taille définie dans ce dictionnaire.
C’est une caractéristique importante et essentielle pour permettre aux couches de se compléter les unes aux autres sans risque de débordement ou chevauchement
Description du fichier
Pour chaque add-on, il faut une ligne de type SOURCE et une ligne de type OBJET
Les différents paramètres sont :
Type | Source : répertoire où se trouvent les sources de l'add-on |
Name | Nom de l'add-on |
Path | Chemin relatif par rapport au fichier overwrite.txt du répertoire (source ou objet selon le type). Paramètre inutilisé dans la pratique. |
AbsolutePath | Chemin absolu du répertoire (source ou objet selon le type) |
Remarque : Il est obligatoire que les chemins spécifiés ici soient écrits de la même manière que dans le fichier des implicites.
(Il ne faut pas avoir : c:/divalto/specifs/WS_AO_Italy/objets dans les implicites et /specifs/WS_AO_Italy/sources dans le fichier overwrite.txt)
Exemples
Exemple de fichier Overwrite.txt pour la couche FINALE
On peut voir dans cet exemple les règles de construction:
un
;
indique une ligne de commentaireon place les ADD-ON en premier, en mettant “true” sous la forme :
<addon>1
on place la couche finale en dernier, en mettant “false” sous la forme :
<addon>0
chaque couche doit être nommée avec la balise
<name>
, avec un nom simple court, sans caractères spéciaux ni espace, mais qui synthétise la fonction de la couche, ici par exemple<name>italie
ou<name>maroquinerie
chaque ligne est typée avec les balises
<Type>OBJECT
pour un chemin de type objets diva, ou<Type>SOURCE
pour un chemin de type sources divachaque ligne a pour but d’indiquer un chemin
la balise
<absolutepath>
indique un chemin absolu. C'est le cas à utiliser pour les lignes ADD-ON pour ‘sortir' des implicites de la couche courantela balise
<path>
indique un chemin relatif. C'est le cas à utiliser pour ‘rester’ dans la couche courante
lorsqu’on utilise un chemin relatif avec
<path>
il ne faut PAS démarrer par un/
car le dossier indiqué est forcément au noeud de départ
Exemple de fichier Overwrite.txt pour la couche MAROQUINERIE
Si la couche add-on veut gérer un mécanisme de HOTFIX, il convient d’ajouter les chemins de HOTFIX dans le groupe de chaque add-on, et plaçant le hotfix avant son propre standard
Exemple : Italie et Maroquinerie ont des Hotfix
Les implicites
Le fichier des implicites de la couche finale doit décrire tous les chemins nécessaires de chaque couche. Comme indiqué précédemment, l’ordre dans ce fichier doit être l’inverse de celui du fichier Overwrite.
Exemple :
Couche Italie : un GTUMPCE correctif et un GTUMPCE d’origine
Couche Maroquinerie : un GTUMPCE d’origine
Couche Borsetta : un GTUMPCE correctif et un GTUMPCE d’origine
Lors de l’appel à GTTMPCE se déclenche l’imbrication des GTUMPCE. Le premier chemin dans l’implicite devra être le premier de chaque couche, donc dans l'exemple Hotfix Borsetta, puis Borsetta, puis Maroquinerie, puis Hotfix italie, puis Italie
Dans notre cas on aura donc d’abord la couche finale, puis la couche italie et maroquinerie.
Les éléments de surcharge
Nom de l'élément | Partie de l'élément | Comportement en surcharge multiple (si le même élément existe dans plusieurs couches) | Actions à faire |
---|---|---|---|
Dictionnaire .DHSD | Champ U dans un dictionnaire standard Table U dans un dictionnaire standard | Les champs de chaque couche vont s’ajouter. Attention il ne doit pas y avoir de conflit de nom de champ entre couches | (aucune, la fusion pour le schéma et la compilation vont se faire naturellement) |
Dictionnaire .DHSD | Table ou champ dans un dictionnaire add-on |
|
|
Source .DHSP | Source de type TT/TZ | Le TT de chaque couche va être appelé successivement, à condition que le STANDARD.xxx n’est pas été oublié ou remplacé. S’il n’y a pas d’appel à standard. la chaîne s’arrête | S’assurer de la présence du standard.xxx si on veut enchaîner les couches, ou ne pas en avoir si on ne veut pas empiler |
Source .DHSP | Source de type TM |
|
|
Source .DHSP | Source de type xxTMFICSQL | Les xxTMFICSQL ne sont pas des surcharges, il n’y a donc pas d’empilement de couches | Fusionner à la main les couches |
Masque écran .DHSF | Ecrans EE/EZ | Il n’y a pas de fusion des écrans ! | Recréer un masque d’écran, et reporter manuellement les éléments |
Masque écran .DHSF | Traitements EE/EZ | il n’y a pas de fusion des traitements écrans ! |
|
Masque imprimante .DHSI | Bloc impressions II | Il n’y a pas de fusion des blocs ! | Recréer un masque d’écran, et reporter manuellement les éléments |
Masque imprimante .DHSI | Traitements II | il n’y a pas de fusions des traitements d’impressions ! |
|
Menus .DHFI | Surcharge de menu IA | Il n’y a pas de fusion des fichiers .DHFI! donc pas de fusion des menus | Reporter dans la couche finale les ajouts de chaque couche |
Styles .DHFI | Surcharge de feuille de style | Il n’y a pas de fusion des fichiers .DHFI! donc pas de fusion des feuilles de style | Reporter dans la couche finale les ajouts de chaque couche |
RecordSql .DHSQ |
| La fusion des recordSql compilés .DHOQ se fait naturellement. Les champs et tables de couches inférieurs sont automatiquement remontées dans la couche finale |
|
Jointures .DHSJ |
| Les jointures de chaque couche vont s’ajouter. Attention il ne doit pas y avoir de conflit de nom de champ entre couches |
|
Fichier FHSQL |
| Il n’y a pas de fusion des FHSQL ! | Chaque couche a son fichier FHSQL pour décrire des “fichiers de tables” le cas échéant. La couche finale/client doit reprendre manuellement les fichiers issus des couches add-on |
Pour plus de détails et d’illustration, suivez le guide pas à pas plus bas.
Compléments concernant les sources/objet/surcharge pour le cas des masques écran/imprimante
Lorsqu’une couche modifie par exemple un masque écran ou impression (donc un élément qui ne se fusionne pas dans le tableau ci-dessus), et que les autres couches n'ont pas de modification de ce même écran, il n’y a aucune intervention à faire. La modification d’une couche inférieur sera vue et traitée naturellement, sans avoir besoin de créer un source ou compiler un objet dans la couche finale. Exemple : si la couche Maroquinerie modifie le zoom Client, mais que la couche Italie et Borsetta n’ont pas de modification de ce même zoom, alors on obtient bien un zoom, exécuté dans la couche finale, qui comporte les modifications Maroquinerie. Ce n’est que lorsque le même élément existe dans plusieurs couches que la fusion doit être faite manuellement pour les masque écran ou impression
Compléments concernant les xxTMFICSQL
Les modules xxTMFICSQL n'étant pas des surcharges, ils ne sont pas naturellement empilés s’il en existe dans plusieurs couches qui utilisent un xxPMFICSQL.
Il est donc indispensable de fusionner le code manuellement.
Pour cela il faut déclarer les modules issus des autres couches sous la forme
Module NomDeLAddOn.xxTMFICSQL.dhop as NomDeLAddOn_AddOn
Exemple
De cette manière, la couche finale détermine si les procédures des autres couches sont appelées ou non, et dans quel ordre
Compléments concernant l’empilement des couches
La couche de référence est la couche client final. Tout code de surcharge existant dans cette couche sera exécuté. La surcharge multiple, en cas d’absence de surcharge sur une ouverture, ira remonter selon les implicites pour chercher la surcharge sur cette même ouverture dans les autres couches, ce qui donne l’effet principal de la surcharge multiple, à savoir qu’une couche ‘add-on’ modifie le comportement de la couche client sans que cette dernière n’ait à implémenter de modification
Exemple : une ouverture Article_update_av existe, et appelée par le standard. Si une couche ‘add-on’ implémente cette fonction (et pas la couche client) dans un objet trouvé dans les implicites, elle sera exécutée.
Mais si la couche client, ou une couche add-on, implémente une fonction il faut tenir compte des autres couches potentielles.
C’est pourquoi il est recommandé, dans toute surcharge d’une ouverture, de toujours faire appel au standard. de cette même ouverture pour continuer la propagation aux autres couches
Exemple : une surcharge de Article_update_av est fait dans un couche Italie. Elle doit faire appel à standard.Article_update_av pour permettre à la couche Maroquinerie d'être appelée
La couche client peut donc, via la méthode d'écriture, décider de la manière d’empiler les couches
soit en mettant son propre comportement, sans appeler les autres couches
soit en appelant le standard.xxx pour un empilement naturel des couches
soit en appelant explicitement une couche. Pour cela une déclaration
Exemples
Compléments concernant les dictionnaires
La “fusion” des dictionnaires, pour le développeur dans XWIN, se fait automatiquement.
En effet, XWIN lit le fichier Overwrite.txt en plus de l’implicite, et connait donc les couches et les dictionnaires qui y sont. Il est donc capable de trouver par exemple les zones U de chaque couche et de les afficher dans une seule vision de dictionnaire fusionné, même si ce qui est affiché à l'écran n’a pas d’existance physique en tant que fichier.
Exemple:
la couche Italie utilise la zone U de ART pour ajouter un champ I
la couche Maroquinerie utilise la zone U de ART pour ajouter un champ M
la couche finale Borsetta utilise la zone U de ART pour ajouter un champ B
=>Avec la présence du fichier overwrite.txt, XWIN va afficher un dictionnaire surchargé qui présente dans la zone U de ART les 3 champs (I, M et B). Ce dictionnaire est fictif, car aucun des fichiers GTFDDU.dhsd des couches Italie, Maroquinerie ou Borsetta ne comporte les 3 champs, et la version “fusionnée” affichée dans XWIN n’est pas sauvegardée. Ce même principe permettra à la synchronisation de dictionnaires de fusionner les dictionnaires.
Compléments concernant le FHSQL
Un couche peut nécessiter de nouvelles tables SQL. Il existe trois manières d’ajouter une table SQL
l’ajouter dans un “fichier de table” standard d’un dictionnaire standard surchargé
l’ajouter dans un “nouveau fichier de table” dans un dictionnaire standard surchargé
l’ajouter dans un dictionnaire spécifique, dans des “fichiers de table spécifiques”
Le cas 1 est transparent pour le FHSQL, aucun action à faire.
Les cas 2 et 3 obligent l'éditeur de l’add-on a fournir un fichier FHSQL qui comporte uniquement les “nouveau fichier de table” ou les “fichiers de table spécifiques”
Il est recommandé de fourni un fichier nommé “FHSQL_addon_nomdeladdon.dhfi” afin d’indiquer le nom de l’add-on. Exemple : “fhsql_addon_italie.dhfi”
Compléments concernant XWin et l'éditeur de dictionnaires
Pour qu'une donnée soit extensible (c'est à dire que ses sous-données puissent dépasser la taille initialement prévue), il faut cocher la case <Zone U>
Lorsque Xwin est lancé en mode Surcharges Multiples, (c'est à dire qu'il détecte la présence d'un fichier overwrite.txt), quelques nouvelles fonctionnalités apparaissent dans l'éditeur de dictionnaires :
par défaut, Xwin affiche le dictionnaire de base ET toutes les surcharges qui sont en lignes
Ici on voit que les champs provenant de l'add-on Italy, de l'add-on Maroquinerie et de la surcharge Borsetta sont visibles en même temps
Le choix <Outils><Ne voir que le dictionnaire principal> permet de ne voir que le dictionnaire de base sans aucune surcharge
Le choix <Outils><Ne voir que le dictionnaire principal et son premier niveau de surcharge> permet de voir le dictionnaire de base et la première surcharge trouvée d'après les implicites et non d'après overwrite.txt. Il s'agit du mode de fonctionnement habituel, comme si le fichier overwrite.txt n'existait pas.
Le fichier DHOS
Le fichier .DHOS a les caractéristiques suivantes:
c’est un fichier issu d’une compilation par XWIN, il n’est en aucun cas modifiable par un autre outil
il porte la combinaison des dictionnaires de données (obtenus par fusion des différentes couches ; il contient donc les positions réelles des champs des tables mémoire et SQL et gère les conflits de positions des zones U)
il doit être généré dans la couche FINALE, même si la couche finale n’a aucun spécifique propre et ne fait qu’utiliser d’autres couches
est utilisé uniquement lors de l’exécution des programmes Diva en surcharge multiple afin de fournir un dictionnaire combiné (par la couche runtime ; pas d’impact sur la synchronisation des dictionnaires)
il faut le régénérer à CHAQUE modification de l’un des dictionnaires de l’une des couches de surcharge (quel que soit le module GT,CC,…, la nature de modification de dictionnaire, quelle que soit la couche)
il faut le régénérer à CHAQUE modification du fichier Overwrite.txt de la couche finale/client
il ne doit en exister qu’un seul exemplaire dans l’arborescence des implicites final/client, juste à côté du Overwrite.txt
Ce fichier est obtenu par XWIN, sur le projet de la couche finale qui regroupe les surcharges, dans le menu clic-droit sur le projet puis “Compiler les dictionnaires de données (surcharges multiples)
A noter que le menu “Contrôler les fonctions” est une aide avant compilation pour détecter d’éventuels conflits de noms de fonctions/procédures entre les couches
Synchronisation des dictionnaires
Lors de la phase de synchronisation, XP-SQL doit trouver tous les dictionnaires, plus précisément celui de la couche client, et toutes les couches existantes. Comme le nom du dictionnaire est identique (par exemple GTFDDU.dhsd) quelle que soit la couche, il est nécessaire d’utiliser des sous-dossiers distincts. De plus ces sous-dossiers peuvent provenir d’add-on auxquels l’accès est difficile en SaaS.
La synchronisation directe/manuelle depuis XP-SQL n’est donc pas recommandée
La synchronisation se fait de manière sécurisée à partir d’XWin, ce qui va créer la structure adaptée dans la base de données aux surcharges multiples, par fusion des différents niveaux de surcharge.
Pour lancer une synchronisation pilotée d’XP-SQL (programme XpSQLautosynchro), on utilisera le menu” Synchroniser la base de données” du clic-droit sur le projet
Dans un cadre de développement local, si besoin de faire une synchronisation manuelle, suivez les étapes suivantes :
Créer un dossier “SYNCHRO-MULTIPLE”
Placer le fichier OVERWRITE.TXT de la couche client à la racine de ce dossier (voir plus haut l’exemple #OverwriteClient)
Placer les dictionnaires de surcharge de la couche client à la racine de ce dossier
Créer un sous-dossier pour chaque couche
Exemple : un dossier ITALIE et un dossier MAROQUINERIE
Placer les dictionnaires de surcharge de la couche dans son dossier
Lancer XP SQL, et choisir le dossier de synchro multiple
Illustration de la surcharge multiple (vidéos et code source)
Voici quelques vidéos basées sur l’exemple fictif, à savoir un client BORSETTA maroquinier italien qui utiliser deux couches, l’une pour les spécificité Italie, l’autre pour les spécificités Maroquinerie.
Le but de ces vidéos est de présenter l’exemple dans un mode opérationnel, mais à but pédagogique.
Vidéo 1 : Introduction
Présentation de l’exemple fictif
Code source exemple fictif
Voici un zip contenant l’exemple illustré dans les vidéos
Vidéo 2 : La couche Italie
Présentation du code Diva qui constitue la couche Italie (add-on, couche intermédiaire)
Vidéo 3 : La couche Maroquinerie
Présentation du code Diva qui constitue la couche Maroquinerie (add-on, couche intermédiaire)
Vidéo 4 : La couche Borsetta
Présentation du code Diva qui constitue la couche Borsetta (couche finale client)
Vidéo 5 : Exécution dans la couche Borsetta
Exécution de l’ERP dans la couche Borsetta, avec explications rapides sur les traversées des couches
Mise en oeuvre dans le SaaS
Dans la plateforme SaaS Divalto, les add-ons ont une gestion spécifique pour permettre la mutualisation.
En effet, le principe est de déclarer un add-on (dans notre exemple Italie et Maroquinerie) à partir d’un site partenaire, et de faire un lien entre le site client (dans notre exemple Borsetta) et les add-ons dans le paramétrage du site. Cela permet de bénéficier des mise à jours/hotfix de chaque couche sous la responsabilité du partenaire éditeur de ladite couche.
1. Déclaration de l’add-on (par le partenaire éditeur de l’add-on)
La déclaration de l’add-on, donc la couche intermédiaire, est nécessaire pour que la couche soit utilisable dans un autre site (notamment du fait des implicites qui ne sont pas modifiables directement en saas)
Voici les étapes à suivre pour déclarer un add-on
Demande d’un site partenaire dans notre SAAS si le partenaire n’en possède pas encore
Mise en place de l’add-on X dans les spécifiques du nouvel environnement SAAS partenaire. Pour cela la demande est à faire via un ticket MyService en indiquant le site partenaire (sur lequel l’add-on sera hébergé), ainsi que le nom du nouvel add-on
Le partenaire éditeur devient responsable de son add-on, envers les utilisateurs de cet add-on, qu’il maintiendra via FTP sur son site partenaire
Le partenaire obtient un accès FTP réservé à la gestion du site add-on
2. Publication d'un add-on sur un site client (par le partenaire du client)
Une fois l’add-on disponible sur la plateforme Saas, il devient utilisable sur un site (pas encore actif)
Voici les étapes à suivre pour publier un add-on:
Demande de publication de l’Add-on X vers le site client final (nouveau ticket à créer sur MyService). Si cette information est déjà connue au moment de la création de l’add-on sur le site partenaire , la demande peut être faite directement dans le ticket précédent.
L’add-on apparait alors sur le site dans la gestion des implicites
3. Ajout de l’add-on dans le site client (par le partenaire du client)
Si l’add-on a bien été publié pour le site, il apparaît dans la gestion des implicites, zone “Add-ons”
On peut alors ajouter l’add-on X dans les implicites du site final avec les cases à cocher, ce qui a pour effet d’insérer les implicites de l’add-on au bon endroit. Il est possible de mettre plusieurs add-on qui viendront se placer dans les implicites.
Implicites Utilisateur, avec activation d’un add-on et hotfix
Le même mais en version Administrateur (pour développeur), qui ajoute automatiquement les chemins liés aux sources, navigation, projets
A noter que, via FTP, le client ne voit que son propre site. Les add-on sont visibles via les implicites, mais d’une manière fictive. Seul le partenaire éditeur de l’add-on accède aux dossiers de l’add-on
Exemple de la vision par FTP, par le partenaire, de son site qui héberge un add-on
Site distant : le site est dédié à l’add-on, ici MAROQUINERIE
Version : c’est la version 1 de l’add-on, donc 01
Dossiers : le dossier MAROQUINERIE/01 contient les dossiers habituels (sans le SPECIFS)
Il est recommandé au partenaire éditeur d’utiliser, dans son site partenaire, le dossier SPECIFS pour faire les modifications, puis de copier vers les dossiers réservés à l’add-on quand tout est prêt
A cette étape, il faut également publier sur le site client le fichier OVERWRITE.TXT et OVERWRITE.DHOS issus de la préparation de l’environnement surcharge multiple
4. Fichier FHSQL en cas de dictionnaire complémentaire ou de fichier de tables complémentaires (par le partenaire éditeur de l’add-on)
Si l’add-on comporte des surcharges de dictionnaire de type ‘nouveau dictionnaire’ ou 'fichier de tables en compléments dans un dictionnaire standard) alors il faut également fournir le fichier FHSQL issu de l’environnement de préparation de surcharge multiple.
Ce FHSQL ne doit comporter que les fichiers de tables correspondants aux compléments (donc fichier de table d’un dictionnaire standard ou fichier de table d’un nouveau dictionnaire). Par exemple un ajout dans GTFAT du GTFDD ne nécessite aucune action, car c’est un fichier de tables existant. Par contre un fichier GTFUITAL ajouté dans GTFDD ou un dictionnaire ITALFDD.DHSD rend cette étape indispensable.
Voici les étapes à suivre :
Générer les fichiers fhsql depuis votre environnement local où est déjà en place la surcharge multiple (à partir de XPSQL).
Supprimer toutes les lignes de fichiers de tables 'standard (donc ne garder que ceux correspondant aux surcharges)
Déposer les fhsql et les dictionnaires sur le site du client final via ftp
Depuis XWin sur le site SAAS du client final, créer un projet de surcharge (Achat-Vente par exemple) si ce n’est pas fait (rappel, c'est indispensable pour compiler le .DHOS)
Dans les options du projet, ajouter le chemin vers ce fichier FHSQL
5. Fichier Overwrite.txt (par le partenaire du client)
La première fois, lors de la première publication sur un site en surcharge multiple, on passera par une création du fichier sur un poste local avant de le publier par FTP vers le site en SaaS.
Par la suite on pourra
continuer à faire les modifications dans le fichier local et le publier par FTP
on pourra aussi utiliser XWIN pour ouvrir le fichier .TXT et le modifier. ATTENTION dans ce cas, après modification, il faut QUITTER XWIN et le relancer pour prendre en compte la modification
6. Spécifiques de la couche client (par le partenaire du client)
A ce stade, les add-ons sont prêts, il reste à s’assurer que les spécifiques de la couche client, préparés au préalable dans un environnement de préparation de surcharge multiple, sont bien livrés (objets et sources).
C’est une étape importante qui doit aussi générer le fichier Overwrite.DHOS issu de la compilation multi-couches à partir de la couche finale, et le placer au même endroit que le fichier Overwrite.TXT.
7. Synchronisation des dictionnaires (par le partenaire du client)
Lancer la synchronisation de la base à partir d’XWin, ce qui va créer la structure adaptée dans la base de données aux surcharges multiples, par fusion des différents niveaux de surcharge
Complément de mise en oeuvre pour la plateforme divalto one
La fusion automatique entre plusieurs couches pour l’expérience divalto one n’existe pas actuellement.
Cela signifie que les fichiers JSON qui pourraient être générés par une couche d’add-on (qui vient modifier un zoom) n’est pas vu automatiquement dans la couche finale/client car il n’y a pas de stockage de ces fichiers add-on.
Il est donc indispensable actuellement de reporter les sources des masques écran de zooms issus des couches d’add-on dans le projet de la couche finale/client pour que la compilation génère les fichiers JSON correspondants lors de la compilation de la couche finale/client.
Migration de version en surcharge multiple
La surcharge multiple implique au minimum une couche d’add-on, soit 3 couches au minimum (couche standard, couche add-on, couche client).
Il faut considérer les surcharges multiples comme des couches successives à migrer indépendamment et dans l’ordre (en partant du standard vers le client), et chaque couche est considérée comme “simple” (=pas en surcharge multiple)
En effet, la couche add-on (par exemple Italie) est vu comme une surcharge ‘simple’, et doit donc être migrée par rapport à la couche standard en totale indépendance des autres. On traitera donc une montée de version du standard et ses effets sur une couche add-on, par exemple ici Italie seul.
En présence d’une seconde couche d’add-on (par exemple Maroquinerie), cette dernière sera elle aussi traitée en montée de version du standard et de ses effets sur une couche add-on, mais sans tenir compte des autres add-on, donc par exemple ici Maroquinerie seul
La couche client est une surcharge monocouche qui utilise les couches d’add-on (Italie et Maroquinerie). On la traite donc ainsi, en partant d’une couche standard avec les add-ons déjà migrés, pour y appliquer uniquement les effets de la montée de version sur les spécifiques client
Au final, on aura donc traité dans l’ordre : migration couche Italie, Migration couche Maroquinerie, Migration couche client Borsetta
En cas de montée de plusieurs versions, il faut que chaque couche fasse également le saut pour rester cohérent sur l’ensemble.