Pour rappel, retrouvez ici

• les informations concernant le développement en SaaS https://divalto.atlassian.net/wiki/spaces/PAI/pages/11239424017

• les informations concernant le développement avec divalto one https://divalto.atlassian.net/wiki/spaces/PAI/pages/11263901698

Principe sous Divalto one

La plateforme Divalto one, pour proposer la nouvelle expérience utilisateur, utilise beaucoup d'éléments déjà fournis par un développement et un déploiement SaaS classique. En effet, les mécanismes d'exécution sont identiques pour tous les objets Diva, les fichiers .DHFI (menus par exemple), les impressions et les masques d'écran de l’expérience classique. Seule l’expérience divalto one des zooms nécessite des éléments complémentaires actuellement.

Le principe est le suivant pour un “masque écran zoom”

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

  • 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

On voit ici simplement la différence : pour fonctionner en expérience one, la plateforme a besoin d’un objet complémentaire et de fichiers JSON de description de l'écran. Les objets nommés xxx_t.dhop sont indispensable, pensez à bien les prendre !

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

• 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

Ce qu’il faut déployer sous divalto one

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 pus bas). Les JSON et les xxx_t.dhop sont fabriqués à la fin de la compilation classique).

Il existe deux manières de déployer ces éléments

Déploiement via XWIN

La méthode la plus simple est d’utiliser XWin.

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.

Ce bouton ouvre une fenêtre de paramétrage complémentaire d’XWin spécifique au développement avec la plateforme divalto one.

Open

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

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 https://divalto.atlassian.net/wiki/spaces/PAI/pages/11239424017 )

• 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 par FTP

Déploiement via le Studio

Cette seconde méthode est possible si l’on souhaite déployer plusieurs sites identiques, 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, tous les fichiers sont disponibles sur le poste local (les objets spécifiques, les xxx_t.dhop et les fichiers JSON).

Il est alors possible d’utiliser le STUDIO pour envoyer les fichiers JSON manuellement, et de déposer les objets par FTP.

Plus d’informations sur l’utilisation du studio : https://divalto.atlassian.net/wiki/spaces/DO1/pages/10848862343

Les fichiers JSON utilisés par la plateforme one sont localisés dans :

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é

Open