SAINET apis and documentation (stable/4.8.x)

Paramétrage - ConfigurationWatch

Dans le système modulaire du framework, le client utilise des versions mergées des modules pour connaitre le paramétrage à utiliser. Il n’est donc pas possible d’utiliser de base le trunk directement pour travailler sur un serveur.

Le framework propose un outil intitulé ConfigurationWatch permettant de travailler non seulement sur les serveurs actuels qui gèrent la gestion des modules, mais également sur des serveurs legacy sans modularisation.

Il permet de merger en local de façon automatique le paramétrage en fonction du serveur avec lequel on veut travailler. Il analyse également automatiquement les modifications apportées en local sur les fichiers du trunk et reconstruit à la volée les versions finales du paramétrage afin de pouvoir travailler en continu avec le trunk

Cet outil est situé dans le dossier tools/ConfigurationWatch du trunk

Chemin de l'outil


Prérequis
Aperçu global de l'outil
Customers
Override par société
Merge et surveillance
Utilisation de l'application
Developpement de l'executable

Prérequis

Afin de pouvoir utiliser l’outil, les deux répertoires suivants doivent être disponibles :

  • modules contenant tous les dossiers de modules divers de l’application
  • tools contenant l’outil
  • Un dossier d’output en dehors du trunk qui servira au merge

Il est important de maintenir la hierarchie telle qu’elle est définie sur le trunk car le ConfigurationWatch va automatiquement trouver les bons paths

Hierarchie des dossiers du trunk Dossier des modules

Dans cet exemple, nous utiliserons le dossier C:\SNV4-dev-env\ pour contenir la version mergée

Aperçu global de l'outil

Voici un aperçu de la fenêtre du ConfigurationWatch.

Overview

Voici la liste rapide des éléments que l’on voit sur cet écran. Le détail de chaque concept sera ensuite détaillé en profondeur.

  1. Dossier modules Ce chemin est récupéré automatiquement par l’outil. C’est le dossier obligatoire contenant la liste des modules
  2. Dossier d’output Ce chemin obligatoire est le dossier dans lequel l’outil va merger le paramétrage. Attention, ce dossier est vidé entre chaque merge, il doit donc être vide au démarrage
  3. Customer Selection du client (impacte la selection du serveur et de l’environnement)
  4. Environnement Lorsqu’un client peut avoir plusieurs serveurs, le choix est ici
  5. Variante Lorsqu’un serveur a plusieurs configuration dans le .ini (proxy, etc…), les différentes variantes apparaissent ici
  6. URL L’url du serveur est automatiquement récupérée de l’environnement du customer
  7. Modules par defaut Donne la liste des modules activés pour toutes les sociétés en plus du global
  8. Modules par société Il est possible en local de changer la liste des modules actifs pour une société
  9. La console de log indique les opérations en cours. Son bouton Watch permet de lancer le merge et la surveillance

Customers

Les différents clients possible, leurs environnement et leurs variantes proviennent des fichiers xml du dossier customers dans le dossier modules du trunk. Ce dossier contient la liste officielle des serveurs. Elle est également utilisée par l’AdminClient.

Dossier des clients

Voici un exemple de définition de client :

<?xml version="1.0" encoding="UTF-8"?>
<customer  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
           xsi:noNamespaceSchemaLocation="../../server/lib/CustomerAPI/src/main/resources/saierp/customer/customer.xsd"
           id="ABC">
  <defaults>
    <availableModules>
      <module id="abc" />
      <module id="def" />
    </availableModules>
    <defaultModules>
      <module id="abc" />
    </defaultModules>
    <ini>
      <prop id="SSO">true</prop>
    </ini>
  </defaults>
  <environments>
    <environment id="prod" url="https://my-abc-url/SNV4SRV-ws-war/EPS">
      <ini id="internal">
        <prop id="ProxyType">PROXY_HTTP</prop>
        <prop id="Proxy">SOME-INTERNAL-ADDRESS:8443</prop>
      </ini>
    </environment>
    <environment id="qa" url="https://my-abc-qa-url/SNV4SRV-ws-war/EPS" />
    </environments>
</customer>

customer permet de définir un client au sens large (exemple client ABC).

defaults indique au système quels sont les modules disponibles (availableModules), quels sont les modules activés pour toutes les sociétés par défaut (defaultModules), et quelles sont les propriétés dans le .ini qui doivent apparaitre dans tous les .ini pour toutes les serveurs

environments définit la liste des serveurs et des propriétés associées pour ce client. Chaque environment possède un id unique qui apparaitra dans la combo Environnement de l’outil. Il possède également une url qui est l’url de connexion qui sera présente dans le .ini pour cet environnement. Enfin, il est possible de définir des ini identifiés par un id (vide pour le default) qui permettent de déclarer des variantes pour un même environnement (exemple : une version interne avec proxy et une version externe par défaut)

Variante d'un environnement

Override par société

Il est possible afin de tester facilement l’activation de modules de spécifier une liste de modules actifs pour une société en particulier. Cette opération s’effectue dans le tableau suivant :

Override par société

Dans cet exemple, les société OR2 et OR4 ont toutes les deux le module someother actif, et on chacune un module supplémentaire avant ou après celui-ci.

Attention : la liste des modules doit être déclarée en minuscule séparée par des virgules

Attention : seuls les modules déclarés dans les <availableModules/> peuvent être utilisés

Merge et surveillance

Le bouton Watch permet de lancer le merge du paramétrage dans le dossier d’output. La console d’output fournit des indications sur l’opération en cours. Il existe deux étapes principales :

  1. Le merge initial. Le prépare la première fois le dossier d’output. Il copie les fichiers du client, crée le .ini, etc…

Packaging initial

  1. La surveillance. Dans cette étape, tout modification d’un fichier de module entraine une regénération du package correspondant. Si le fichier ajouté/supprimé/modifié ne fait pas partie d’un des packages utilisés par l’environnement, un message d’information avertit le developpeur, et aucun package n’est regénéré.

Surveillance des modifications

Utilisation de l'application

Il suffit de lancer l’application dans le dossier mergé pour pouvoir travailler automatiquement avec la bonne version du paramétrage.

Le fichier domains_override.xml empêche le logiciel de télécharger des packages du serveur et de faire des mises à jour, tout en lui indiquant où sont situés les packages de configuration mergés.

Il est donc possible de developper sur le trunk et de voir les modifications telles qu’elles apparaitront sur le serveur.

Afin de simplifier encore plus le developper, l’outil de merge communique avec le client par le biais du fichier latest_merge.txt afin de transmettre le dernier timestamp de regénération. Si ce timestamp change, le client vide ses caches pour recharger à la volée le nouveau paramétrage ce qui permet de pouvoir faire des modifications de modules et voir instantanément le resultat.

Developpement de l'executable

Le developpement de l’application est également possible facilement avec ce système. Il suffit de change le repertoire d’execution de SAINET en le pointant vers le dossier final d’output. Il trouvera alors le bon SAINETV4.ini et le fichier domains_override.xml qui lui feront utiliser les bon modules mergés automatiquement. Voici comment changer le dossier courant de l’executable :

Menu Run

Working Directory