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

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

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

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.

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 :

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

;dans borsetta on se considère comme dernier niveau, donc addon=0 false, et les autres comme ajouts donc addon=1 true
;addon italie, en ABSOLUTE PATH 
<Type>OBJECT<addon>1<name>italie<absolutepath>/surcharge/italie_erp220/objets
<Type>SOURCE<addon>1<name>italie<absolutepath>/surcharge/italie_erp220/sources
;addon maroquinerie, en ABSOLUTE PATH 
<Type>OBJECT<addon>1<name>maroquinerie<absolutepath>/surcharge/maroquinerie_erp220/objets
<Type>SOURCE<addon>1<name>maroquinerie<absolutepath>/surcharge/maroquinerie_erp220/sources
;niveau client borsetta : en PATH
<Type>OBJECT<addon>0<name>borsetta<path>objets
<Type>SOURCE<addon>0<name>borsetta<path>sources

On peut voir dans cet exemple les règles de construction:

• un ; indique une ligne de commentaire

• on 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 diva

• chaque 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 courante

  • la 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

;dans la maroquinerie on se considère comme dernier niveau puisqu'on ne connait ni italie ni borsetta, donc addon=0
<Type>OBJECT<addon>0<name>maroquinerie<absolutepath>/surcharge/maroquinerie_erp220/objets
<Type>SOURCE<addon>0<name>maroquinerie<absolutepath>/surcharge/maroquinerie_erp220/sources

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

<Type>OBJECT<addon>1<name>italie<absolutepath>/surcharge/italie_erp220/HotfixA/objets
<Type>SOURCE<addon>1<name>italie<absolutepath>/surcharge/italie_erp220/HotfixA/sources
<Type>OBJECT<addon>1<name>italie<absolutepath>/surcharge/italie_erp220/objets
<Type>SOURCE<addon>1<name>italie<absolutepath>/surcharge/italie_erp220/sources
<Type>OBJECT<addon>1<name>maroquinerie<absolutepath>/surcharge/maroquinerie_erp220/HotFix1/objets
<Type>SOURCE<addon>1<name>maroquinerie<absolutepath>/surcharge/maroquinerie_erp220/HotFix1/sources
<Type>OBJECT<addon>1<name>maroquinerie<absolutepath>/surcharge/maroquinerie_erp220/objets
<Type>SOURCE<addon>1<name>maroquinerie<absolutepath>/surcharge/maroquinerie_erp220/sources
<Type>OBJECT<addon>0<name>borsetta<path>/objets
<Type>SOURCE<addon>0<name>borsetta<path>/sources

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.

;en premier on met la couche client finale, avec les chemins, le fichier Overwrite doit être présent
/surcharge/borsetta_erp220
/surcharge/borsetta_erp220/objets
/surcharge/borsetta_erp220/sources
/surcharge/borsetta_erp220/fichiers
;ensuite on met les add-on
/surcharge/italie_erp220/sources
/surcharge/italie_erp220/objets
/surcharge/italie_erp220/fichiers

/surcharge/maroquinerie_erp220/objets
/surcharge/maroquinerie_erp220/sources
/surcharge/maroquinerie_erp220/fichiers


/divalto/erp220/sources
/divalto/erp220/objets

Les éléments de surcharge

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

Module italie.GTTMFICSQL.dhop   as italie_addon
Module maroquinerie.GTTMFICSQL.dhop   as maroquinerie_addon

Public Procedure Dossier_Select_Ap (&Dossier)
RecordSql 'gtrsdos.dhoq' Dossier Dossier
beginp
  italie_addon.Dossier_Select_Ap (Dossier)
  maroquinerie_addon.Dossier_Select_Ap (Dossier) 
endp

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

;=== CAS FORCE : la couche client impose un comportement
Procedure Article_update_av
beginP
    ;je fais ce qui est attendu, sans appeler les autres couches
    ;la simple existance de la procédure, sans appeler les autres couches, va ignorer les autres couches
endP

;===CAS STANDARD : la couche laisse l'empilement 'naturel'
Procedure Article_update_av
beginP
    ;appel au standard. pour empiler les couches
    standard.Article_update_av
    
    ;suivi du code spécifique
    ;(s'il n'y a pas de code spécifique, autant ne pas déclarer la procédure)
    monModule.monArticle_update_av
endP

;===CAS EXPLICITE : la couche décide de l'empilement
Module italie.GTTMFICSQL.dhop         as italie_addon
Module maroquinerie.GTTMFICSQL.dhop   as maroquinerie_addon
Procedure Article_update_av
beginP
    ;appel explicite (ceci est un exemple où une condition dirait si on a un comportement propre ou non
    if maCondition
      maroquinerie_addon.Article_update_av
      italie_addon.Article_update_av
    else
      monModule.monArticle_update_av
    endif
endP

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

1. l’ajouter dans un “fichier de table” standard d’un dictionnaire standard surchargé

2. l’ajouter dans un “nouveau fichier de table” dans un dictionnaire standard surchargé

3. 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 Tuscany 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

DD-SM-01 Surchargemultiple 01 - Intro.mp4

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)

DD-SM-01 Surchargemultiple 02 - Couche Italie.mp4

Vidéo 3 : La couche Maroquinerie

Présentation du code Diva qui constitue la couche Maroquinerie (add-on, couche intermédiaire)

DD-SM-01 Surchargemultiple 03 - Couche Maroquinerie.mp4

Vidéo 4 : La couche Borsetta

Présentation du code Diva qui constitue la couche Borsetta (couche finale client)

DD-SM-01 Surchargemultiple 04 - Couche Borsetta.mp4

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

DD-SM-01 Surchargemultiple 05 - Démo avec Code.mp4

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.

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

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)

1. 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.

2. 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

3. 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

4. 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.