| Info |
|---|
Cette page donne des indications pour l’application de développements en langage Diva avec l’ERP Divalto vers le SaaS Divalto |
| Sommaire | ||
|---|---|---|
|
Rappel des concepts en SaaS
En mode Saas, sur notre infrastructure cloud, il y a des différences notables pour le développeur
Version Runtime à jour : la dernière version du Runtime Harmony est toujours disponible et installée
Migration : l’ERP est migré entre version par des outils dédiés, identiques à ceux utilisés OnPremise, avec synchronisation de dictionnaires et scripts SQL
Objets standards ERP : les objets sont livrés, mutualisés et inaltérables, dans des dossiers non accessibles par le développeur
Spécifiques : les mécanismes (surcharge dictionnaire, masque, source, objets, synchro de dictionnaire) sont identiques ; seules certaines pratiques diffèrent notamment pour la gestion des dossiers/fichiers pour le déploiement mais il n’y a pas de particularité ou de contrainte supplémentaire en SaaS
En Saas, il n’y a a pas de particularité de développement en comparaison au mode local/OnPremise.
Les différences en Saas
Les principales différences qui modifient le travail en Saas :
Implicites : les implicites ne sont pas modifiables directement, des outils permettent de faire les modifications et les implicites fournis sont opérationnels dès la création du site, et incluent l’ajout de spécifiques
Accès aux dossiers et fichiers : les fichiers/dossier sont accessible par FTP uniquement. Tout site dispose d’un dossier specifs avec une arborescence prévue pour recevoir les éléments de surcharge. C’est dans ces sous-dossiers, et uniquement ici que peuvent être hébergés les spécifiques
Il existe également un dossier transfert pour les échanges de fichiers
XWIN est disponible en Saas, mais principalement pour des recompilation légères ou de contrôle. La compilation et déploiement de spécifiques en masse passe en général par une préparation en local/On Premise, puis une poussée des objets/sources vers le dossier cloud, mais il est possible de faire l’action de compilation sur la plateforme.
Le mode SaaS fonctionne en client HTML ou client WPF, comme le mode local/OnPremise. A noter que pour le cas du HTML il y a des particularités sur la manière de lire/écrire/récupérer un fichier depuis le poste client, mais que ces particularités sont liées au client HTML et non au mode SaaS
Les principaux dossiers en SaaS dans “DIVALTOERP/specifs” (a noter que la racine ne doit rien comporter car non présent dans les implicites)
 | TMP | (temporaire) |
SOURCES | Pour les sources diva (dhsp, dhsf, dhsi, dhsd, dhst), notamment gtfddu.dhsd | |
PROJETS | Pour le ou les projets de surcharge (dhpt, dhps) | |
OBJETS | Pour les objets issus d’une compilation | |
NAVIGATION | Pour les fichiers ‘browse’ issus de la compilation (optionnel) | |
FICHIERS | Pour les fichiers DHFI, notamment les menus (a5mfu.dhfi, g3fu.dhfi,…) |
Traiter les spécifiques en Saas
Préparer les spécifiques
La préparation se fait idéalement aux 4 dossiers
Objets, contenant les objets spécifiques recompilés
Fichiers, contenant les fichiers comme les menus de surcharge
Sources, contenant les sources
Projets, contenant le projet de surcharge
Sauvegarder ce qui est en place, implicites et envoi
Se connecter à la plateforme avec un outil FTP.
Une fois connecté, on trouve dans le dossier specifs
...
la même arborescence que celle préparée.
A noter que le développeur doit avoir un profil Administrateur pour accéder aux dossiers complets
Implicites d’un profil utilisateur : ne voit que objets, fichiers et tmp
Implicites d’un profil administrateur/développeur : voir tous les dossiers
Il est recommandé de faire une sauvegarde ce qui est en place, en téléchargeant les dossier tels qu’ils sont présent sur le site vers un dossier local, et de le zipper pour le conserver avec horodatage.
On peut ensuite pousser les dossier préparés localement vers le site
Certains fichiers nommés Xxxx_V1.dhof proviennent de Divalto processus, ce ne sont pas des fichiers à supprimer
Réaliser une synchronisation de dictionnaire
Pour la synchronisation de dictionnaires, il ne peut s'agir que de spécifiques, puisque la migration de version se gère avec les outils de la plateforme.
La synchronisation avec des spécifiques passe de préférence par une construction d’un dossier temporaire de synchronisation, constitué:
d’un dossier temporaire que l’on place dans le dossier TRANSFERT, nommé par exemple “fhsql_synchro”
des dictionnaires standard actuels, que l’on copie du dossier FTP : DIVALTOERP / config / fhsql vers le dossier temporaires
des dictionnaires de surcharge que l’on pousse par l’outil FTP dans ce même dossier temporaire
| Info |
|---|
On peut également avoir ici un fichier fhsql |
La synchronisation de dictionnaire se fait avec l’outil XPSQL, disponible dans les remote apps
1.Sélection de l’environnement
2.Sélection de la base à synchroniser
3.Lancer la synchronisation
En précisant le chemin des nouveaux dictionnaires créé précédemment : //XXXXXX/yyyyy/transfert/FHSQL_SYNCHRO/
4.Vérifier la cohérence de la synchro avec ce qui était attendu avant de valider
5.La mise à jour peut prendre un certain temps en fonction des tables impactées.
6.Mise à jour effectuée!
Exécuter un script
Il est possible d’exécuter un script via le SQL Data studio, mais il est recommandé de passer par l’exécution de script via XPSQL
On aura au préalable, dans le dossier TRANSFERT utilisé pour la synchronisation, créé un dossier SCRIPTS pour y placer par FTP les scripts à exécuter
| Remarque |
|---|
Rappel, les scripts pour XPSQL doivent commencer par la balise <execute>. Voir les scripts standard fournis si besoin |
Bonnes pratiques
Notifier les utilisateurs via l’Interface d’accueil
La fonctionnalité de notification accessible depuis le menu Administration permet, via un zoom, de faire apparaître une notification dans l’interface d’accueil des utilisateurs, afin de les prévenir d’une modification ou d’un arrêt
Sauvegarder la base avant synchronisation
Dans xCloudManage, lancer la sauvegarde de la BDD par le menu Administration/ERP/Sauvegarde
Déconnecter les tâches
Lancer la console d’administration (xConsole) depuis l’IA
Clic droit pour tuer toutes les taches de l'environnement, afin de tuer toutes les tâches de l’environnement si nécessaire et si possible (attention aux programmes de traitement que ne faut impérativement pas couper en cours)
Bien penser à fermer xConsole avec le menu Quitter, sinon la connexion persiste et empêche la sauvegarde.
Relancer les services
Après modification des objets, il est fortement recommandé de relancer les services pour charger ces derniers objets, en utilisant xCloudmanage
| Remarque |
|---|
ATTENTION ici les 4 première lignes concernent tout le site (tous les environnements) Ne surtout pas arrêter le scrutateur ici. |
Faire un test
Après modification d’objet, synchronisation ou re-démarrage des services, il est recommandé de faire un test par exemple en lançant un zoom, affichant un devis ou d’entrer dans les fonctions qui font l’objet de spécifiques