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 il est branché. 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

---

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 de Git qui servira au merge.

Il est important de maintenir la hiérarchie telle qu’elle est définie dans Git car le ConfigurationWatch va automatiquement trouver les bons chemins.

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

---

Aperçu global de l'outil

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

Voici la liste rapide des éléments que de 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.

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)

---

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 :

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

---

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…

2. 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é.

---

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.

---

Développement du client riche

Le developpement du client riche est également possible facilement avec cet outil. Il suffit de changer le répertoire d’exécution 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 bons modules mergés automatiquement.

Voici comment changer le dossier courant de l’exécutable:

---

Vérification manuelle

Le ConfigurationWatch étant un outil qui n’est pas systématiquement (re)compilé lorsque les vérifications du paramétrage évoluent, il peut arriver que la pipeline master soit en erreur, mais pas les Merge Requests (ou l’inverse). Dans ce cas, il peut être utile de vérifier le paramétrage avec les dernières sources.

La commande suivante effectue la vérification complète des différentes configurations du paramétrage:

mvn clean package -pl testing/sources -P master,no-qa-check -Dtest=ConfigurationTest

La propriété système sainet.customers permet de définir une liste de customers (se trouvant dans le dossier modules/customers) qui doivent être vérifiés:

mvn clean package -pl testing/sources -P master,no-qa-check -Dtest=ConfigurationTest -Dsainet.customers=regie,cre

Il est également possible de vérifier une configuration unique d’un customer:

mvn clean package -pl testing/sources -P master,no-qa-check -Dtest=ConfigurationTest -Dsainet.customers=cre/creche_generic_portal

Si aucune configuration ne correspond aux valeurs fournies dans sainet.customers, alors la liste des identifiants disponibles sera affichée.

Il est parfois difficile de se rendre compte de l’erreur indiquée sans explorer le paramétrage généré durant le merge de la configuration. Pour ce faire, il est possible d’utiliser la propriété système sainet.output_dir en indiquant un répertoire:

mvn clean package -pl testing/sources -P master,no-qa-check -Dtest=ConfigurationTest -Dsainet.customers=cre/creche_generic_portal -Dsainet.output_dir=tmp_cre

Cela va créer le répertoire testing/sources/tmp_cre et y générer le paramétrage qui sera vérifié, permettant son exploration après-coup. De manière générale, il est recommandé d’utiliser cette propriété en même temps que sainet.customers car chaque configuration est générée dans le même dossier.