| Info |
|---|
Cette page donne des indications pour la programmation en langage Diva avec l’ERP Divalto |
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
Objets standards : les objets sont livrés, mutualisés et inaltérables
Spécifiques : les mécanismes (surcharge dictionnaire, masque, source, objets, synchro de dictionnaire) sont identiques ; seules certaines pratiques diffèrent
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 specif 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, mais il est possible de faire l’action de compilation sur la plateforme
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 et envoi
Se connecter à la plateforme avec un outil FTP.
Une fois connecté, on trouve dans le dossier specif la même arborescence que celle préparée.
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
Compil en saas non recommandé, car compil en saas très lente.
Mais c’est un Choix!
Il est donc possible de pousser les JSON depuis le local! C'est plus rapide
En ONE, en plus des JSON il faut les traitements diva qui s'appellent tutu_t.dhop, à copier (ce sont les ‘te’ diva, inclus dans un DHOF mais qu’il faut séparer pour ONE)
Conseil : faire une compil SANS la coche one pour avoir les objets ET les tutu_t.dhop, en local, et pousser le tout
On peut utiliser le Studio pour envoyer les JSON au bon endroit
Recommandé : compil en local (d’un projet coché ONE), qui génère les .objets + DHOF + _t.DHOP + JSON. Les JSON sont déjà envoyés par xwin, puis on copie par FTP tous les objets dans les instants qui suivent
Alternative si on veut séparer : on compile tout, mais SANS envoi des JSON. On récupére les fichiers et leS JSON qui sont en local. Puis a un autre moment on utiliser le STUDIO pour envoyer les JSON et FTP pour tous les objets.
Risque de la désynchro : qu’un JSON fasse appel a un traitement qui n’est pas dans le xxx_t.dhop, ou que le rendu one ne soit pas le rendu classique