Paramétrage - ConfigurationTester

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 repository sainet directement pour travailler sur un serveur.

Le framework propose un outil intitulé ConfigurationTester permettant de vérifier la cohérence du paramétrage de tous les customers du repository sainet, sans devoir compiler SAINet. Il est notamment utilisé par les jobs CI config-light des Merge Requests.

Cet outil est situé dans le fichier tools/ConfigurationTester.jar du repository sainet. Il se lance depuis la racine du repository:

java -jar tools/ConfigurationTester.jar

En cas d’erreur, l’erreur est affichée et le code de sortie est non nul.

Options principales (voir java -jar tools/ConfigurationTester.jar --help):

--customers <liste>: vérifie uniquement les customers indiqués (séparés par une virgule).
--from-customer <nom>: vérifie ce customer et les suivants.
--output <dir>: génère le paramétrage vérifié dans ce répertoire.
--root <path>: racine du repository sainet, pour lancer l’outil depuis un autre répertoire.
--help: affiche l’aide.

Prérequis

Customers

Vérification manuelle

Prérequis

Afin de pouvoir utiliser l’outil, le repository sainet complet doit être disponible, et en particulier les répertoires suivants :

modules contenant tous les dossiers de modules divers de l’application.
server contenant les propriétés du serveur.
tools contenant l’outil.

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

L’outil doit être lancé depuis le repository sainet:

java -jar tools/ConfigurationTester.jar

Depuis un autre répertoire, la racine du repository peut être indiquée avec --root:

java -jar tools/ConfigurationTester.jar --root /chemin/vers/sainet

Customers

Les différents clients possible, leurs environnement et leurs variantes proviennent des fichiers xml du dossier customers dans le dossier modules du repository sainet. 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)

Vérification manuelle

Le ConfigurationTester é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.

Note:

Cela nécessite d’avoir au préalablement compilé SAINet.

Vérification complète

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

Vérification d’un customer particulier

La propriété système sainet.customers (option --customers du jar) 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

Avec le jar, depuis la racine du repository:

java -jar tools/ConfigurationTester.jar --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 (ou --customers), alors la liste des identifiants disponibles sera affichée.

Générer le paramétrage

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 (option --output du jar) 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

Avec le jar, un chemin relatif donné à --output se résout depuis le répertoire courant (et non depuis --root):

java -jar tools/ConfigurationTester.jar --customers cre/creche_generic_portal --output 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é (ou --output) en même temps que sainet.customers (ou --customers) car chaque configuration est générée dans le même dossier.

Info:

S’il n’y a aucune erreur, le répertoire sera automatiquement supprimé, sauf si une seule configuration a été demandée via la propriété sainet.customers ou l’option --customers.

Options du jar

Option	Propriété système équivalente	Description
`--root <path>`		Racine du repository sainet (par défaut, recherchée depuis le répertoire courant)
`--customers <liste>`	`sainet.customers`	Customers (ou configurations) à vérifier, séparés par une virgule
`--from-customer <nom>`	`sainet.customers_from`	Vérifie ce customer et les suivants (vérification incrémentale)
`--output <dir>`	`sainet.output_dir`	Répertoire dans lequel le paramétrage vérifié est généré
`--help`		Affiche l’aide et quitte

Une option prime sur la propriété système équivalente. Si une option est répétée, la dernière valeur l’emporte. Un argument inconnu ou une valeur manquante provoque l’affichage de l’aide et le code de sortie 2.

Mise à jour de l’outil

Le jar tools/ConfigurationTester.jar est construit depuis testing/sources. Il embarque la version de external/SNV4SRV-rules-config présente dans le repo Maven local (et non ses sources): avant de le reconstruire, ce module doit être réinstallé (par exemple via un mvn install complet ou mvn install -pl external/SNV4SRV-rules-config). Après avoir compilé et installé SAINet (mvn install), la commande suivante le reconstruit et le met à jour:

mvn clean package -pl testing/sources -P configuration-tester,no-check && cp testing/sources/target/ConfigurationTester-jar-with-dependencies.jar tools/ConfigurationTester.jar