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é de version/pac en version/pac par des outils dédiés, identiques à ceux utilisés OnPremise, avec synchronisation de dictionnaires et scripts SQL ; aucune migration manuelle

• 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 dossiers 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)

Open	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,…)

Déployer les spécifiques en Saas

Préparer les spécifiques

La préparation se fait idéalement dans les 4 dossiers principaux

• 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 et les sous-projets

• (Navigation, contentant les fichier browse est possible)

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

 

Open

 

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

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

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

Bonnes pratiques de déploiement SaaS

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

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