...
les informations concernant le développement en SaaS Le développement Diva Développer avec Divalto ERP en mode Saas
les informations concernant le développement avec divalto one Comment développer un zoom compatible divalto one
...
en expérience classique/OnPremise/Saas, il est composé d’un objet xxx.DHOF unique qui intègre les écrans (WYSIWYG) et les traitements
en expérience one, il est composé
de l’objet xxx.DHOF, le même qu’en expérience classique (pour la bascule au besoin en expérience classique)des fichiers .JSON qui comportent une description du contenu des écrans dans un mode web pour un rendu full web en expérience one
d’un objet xxx_t.DHOP qui comporte uniquement les TRAITEMENTS diva de l’objet, pour exécution en expérience one du code de la zone de traitements.
d’un fichier .JSON qui comporte une description du contenu des écrans dans un mode web pour un rendu full web responsive
...
| Info |
|---|
Si le projet ne comporte aucune surcharge de masque écran zoom, aucune action n’est requise spécifiquement à la plateforme one |
On voit ici simplement la différence : pour fonctionner en expérience one, la plateforme a besoin d’un objet complémentaire et d’un fichier de fichiers JSON de description de l'écran. Les objets nommés xxx_t.dhop sont indispensable, pensez à bien les prendre !
| Remarque |
|---|
Lors de la publication d’un zoom vers divalto one, il faudra toujours veiller à ce que les 3 éléments sont déployés en même temps (les 2 éléments expérience one et l’objet expérience classique) |
Si les 3 éléments (DHOF de l'écran, _t.DHOP de l'écran et fichiers JSON) ne sont pas déployés en même temps, il y a un risque n’anomalies, par exemple
...
En complément des résultats habituels de compilation, il est donc nécessaire de déployer sur la plateforme divalto one le binôme : fichier fichiers JSON et objet objets xxx_t.DHOP.
En pratique, la compilation des objets DHOF est combinée avec la construction de par XWIN va produire tous les éléments, donc les objets DHOF ainsi que les fichiers JSON descriptifs des écrans de type ZOOM et des objets xxx_t.dhop de TRAITEMENTS.
| Info |
|---|
RAPPEL : La présence des fichiers, issus de la même compilation que le DHOF, est indispensable pour que les traitements et le rendu écran soient en phase. C’est pourquoi il faut aussi compiler les écrans et déployer les JSON en même temps |
...
La méthode la plus simple est d’utiliser XWIN en post-compilationXWin.
En effet, le PROFIL du projet XWin comporte des propriétés du profil de compilation (clic droit + Paramètres sur le nom du profil) et il apparaît un bouton DivaltoOne.
...
La compilation des objets n’est pas impactée par ces paramètres complémentaires. Les paramètres servent uniquement à l’envoi automatique vers un serveur cloud
...
Nom du champ ou case à cocher | Explication |
|---|---|
Générer les masques pour divaltoOne dans le répertoire Chemin de configurations | Coché : génère les fichiers JSON en local, dans le répertoire indiqué juste dessous (Non coché : les fichiers JSON ne sont pas matérialisés en local dans des fichiers, et seront uniquement envoyés par API web) |
Envoyer le résultat de la compilation vers un serveur DivaltoOne | Coché : envoi par API, en |
fin de compilation, |
des fichiers JSON |
compagnons des masques écran vers le serveur One (Non coché : les fichiers restent en local ou n’existent pas selon la coche précédente) | |
URL DivaltoOne | URL de la plateforme DivaltoOne |
Projet | Code du projet One dans lequel envoyer les fichier JSON |
Authentification
| Code et mot de passe de l'utilisateur ayant accès au serveur et au projet indiqués. Le bouton TESTER L’AUTHENTIFICATION permet de contrôler ces données |
Afficher les warning spécifiques à la compilation DivaltoOne |
Affiche dans le résultat de compilation des warnings spécifiques à la plateforme one. Exemple : objet de type bouton dans un masque écran zoom non pris en charge |
Pour un déploiement via XWIN, on COCHE donc la case “Envoyer le résultat de la compilation vers un serveur DivaltoOne”, en indiquant également l’URL, le code projet et les informations utilisateur . Cela a pour effet de tout compiler et d’envoyer les fichiers JSON à l’issue de la compilation
| Info |
|---|
Les fichiers JSON sont envoyés automatiquement vers le serveur divalto one après une compilation sans erreur. Il faut donc copier les objets par FTP dans les instants qui suivent pour éviter une désynchronisation (telle qu’indiquée au premier chapitre) |
Pour bonne pratiquesécuriser le déploiement, il est recommandé:
...
peut être opportun de
faire une recompilation de tout le projet en ayant DECOCHE la case “Envoyer le résultat résultat” dans le profil de compilation afin de s’assurer de la compilation vers un serveur DivaltoOne”
de COCHER la case “Afficher les warnings spécifiques à la compilation DivaltoOne”
de faire une compilation complète jusqu'à ce qu’il n’y ait ni erreur ni warning
de vérifier l’emplacement des objets re-compilés en local, et de préparer la liaison FTP (voir les bonnes pratiques Le développement Diva bonne compilation de l’ensemble et d’un test de premier niveau en local. (La coche “Générer les masques pour divaltoOne dans le répertoire” peut être cochée ou non, cela n’a pas d’impact hors performance)
supprimer les objets masques écrans de zoom de type “*ez*.dhof” (dans les objets qui viennent d'être compilés)
préparer la copie des objets en s’assurant de l’accès aux dossiers de déploiement (via FTP, voir les bonnes pratiques Développer avec Divalto ERP en mode Saas )
de COCHER à nouveau la case “Envoyer le résultat” dans le résultat profil de la compilation vers un serveur DivaltoOne” et finir par une dernière re-compilation qui va envoyer les fichiers JSON vers la plateformede copier les objets par FTP dans les instants qui suiventcompilation
faire une simple construction, qui aura pour effet
de recompiler uniquement les masques écran zooms manquants
d’envoyer les fichiers JSON par API vers le serveur one
copier les objet par FTP
De cette manière, la première compilation permet de s’assurer un bon déploiement avant de le faire effectivement avec une copie des objets juste après l’envoi
Déploiement via le Studio
Cette seconde méthode est à préférer possible si l’on souhaite déployer plusieurs sites en même tempsidentiques, ou de manière décorrélée de l’action de compilation.
Dans cette seconde méthode, on retrouve tous les éléments indiqués dans le chapitre précédent, à la différence que l’on ne COCHE PAS la case “Envoyer le résultat de la compilation vers un serveur DivaltoOne” et qu’il faut nécessairement COCHER la case “Générer les masques pour divaltoOne dans le répertoire” afin d’avoir les fichiers JSON en local. Après une compilation sans erreur ni warning, tous les fichiers sont disponibles sur le poste local (les objets spécifiques, les xxx_t.dhop et les fichiers JSON).
...
La seule différence avec le déploiement par XWIN est donc le fait que les fichiers JSON sont envoyés manuellement au lieu d’un envoi automatique. L’utilisation du FTP pour les l’envoi des objets reste identique
Plus d’informations sur l’utilisation du studio : https://divalto.atlassian.net/wiki/spaces/DO1/pages/10848862343/Utilisation+de+Divalto+StudioAvertissement
Les fichiers JSON utilisés par la plateforme one sont localisés dans :
Nom du site / DeviceTypes / Default
Dans ce dossier, on trouvera un dossier par masque écran de zoom, nommé comme le masque écran zoom, par exemple gtez000_sql. A l’intérieur de ce dossier se trouvent plusieurs fichiers JSON propres au bon fonctionnement de la nouvelle expérience utilisateur.
...
Les fichiers présents dans chaque dossier ne doivent pas être modifiés directement