...
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’anomaliesd’anomalies, par exemple
l'écran de l’expérience classique ne fait pas la même chose que l'écran de l’expérience one
l'écran expérience one fait appel a à un traitement qui n’existe pas dans l’objet _t.DHOP
...
En complément des résultats habituels de compilation, il est donc nécessaire de déployer
sur la plateforme divalto
...
web SaaS classique (accès par FTP) : les objets xxx_t.DHOP
sur la plateforme one (accès par le Studio) : les fichiers JSON
En pratique, la compilation par XWIN va produire tous les éléments à partir des sources, donc les objets DHOF ainsi que les fichiers JSON descriptifs des écrans de type ZOOM et des objets xxx_t.dhop de TRAITEMENTS (selon les cases à cocher du profil XWin - voir plus bas). Les JSON et les xxx_t.dhop sont fabriqués à la fin de la compilation classique).
| 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 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. Le champ de cette zone est alors obligatoire pour la création des fichiers. Les objets xxx_t.dhop seront générés dans le dossier de compilation ‘Objets de surcharge’ (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. Les 4 champs de cette zone sont alors obligatoires pour permettre l’envoi (Non coché : les fichiers restent en local ou n’existent pas selon la coche précédente) | |
URL DivaltoOne | URL de la plateforme DivaltoOne. Diffère principalement pour des environnements Beta Par exemple : https://one.divalto.com |
Projet | Code du projet One dans lequel envoyer les fichier JSON |
Authentification
| Code (sans le domaine @C123456.divalto.com) 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) |
Un environnement en Test est conseillé pour utiliser facilement un profil avec déploiement vers one (et copie des objet manuelle par FTP).
Pour sécuriser le déploiement d’un environnement en Prod, il peut être opportun de
faire une recompilation de tout le projet en ayant DECOCHE la case “Envoyer le résultat” dans le profil de compilation afin de s’assurer de la 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). Une alternative peut être de créer un sous-projet qui contient tous les masque d'écran zoom, et de faire une re-construction de ce sous-projet uniquement
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éployer des développement en mode Saas )
COCHER la case “Envoyer le résultat” dans le profil de compilation
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 objets par FTP
...
Déploiement via le Studio
...
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).
...
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.
Attention, seul les dossiers qui suivent le nommage d’un zoom (exemple gtez000_sql) comportent les fichiers JSON issus de la compilation.
...
Les autres dossiers, par exemple “comboboxdatasources” n’est pas concerné et ne doit pas être modifié ni supprimé
...
Les fichiers présents dans chaque dossier ne doivent pas être modifiés directement