Environnement de test local

Ce guide interne a pour but d’expliquer comment monter un serveur local basé sur un embedded server et des données de test. La première partie explique comment lancer directement les tests d’intégration existants, la deuxième montre comment importer et/ou créer un serveur local avec des données de test.

Avant de pouvoir lancer les tests, le serveur doit avoir été compilé.

Les tests se lancent en un ligne de commande par le script run-test.sh:

./run-test.sh <test_id>

L’option --list pour voir tous les IDs de test possibles. Typiquement, voici un exemple qui va lancer les tests d’intégrations reg:

./run-test.sh reg

Afin de gagner du temps lors du développement de test, il est possible d’exécuter uniquement un seul test en lui appliquant l’annotation @Tag("QuickRun") :

@Test
@Tag("QuickRun")
public void testEmail() throws Exception {
    ...
}

Et ensuite de lancer le test avec le profil adéquat (-P quick-run ou le raccourci -Q):

./run-test.sh <test_id> -Q

Dans le cas d’une classe déjà annotée, il est possible de cumuler les tags:

@Tag("REGDataTest")
@Tag("QuickRun")
public class FacturesChecks {
    ...
}

Lorsqu’un test est en erreur, il est généralement utile d’accéder aux logs du serveur afin de savoir quelles ont été les requêtes reçues et les réponses renvoyées. Les logs sont donc accessibles dans le fichier suivant:

<runtime>/edms/log/sailog-snv4srv-i0_0-default-NA.log

Le dossier <runtime> dépend de l’option -R. Si cette dernière n’a pas été définie, alors le dossier est créé dans le répertoire temp sour la forme <temp>/srv-<test_id>. Typiquement, voici un exemple pour les tests d’intégration reg sous Linux et Windows:

Linux	Windows
/tmp/srv-reg/edms/log/sailog-snv4srv-i0_0-default-NA.log	C:\Temp\srv-reg\edms\log\sailog-snv4srv-i0_0-default-NA.log

La vidéo suivante explique comment monter un serveur local avec des données de test :

Pour créer un serveur vierge, utiliser la commande suivante:

./run-server.sh \
    --runtime <runtime> \
    --install

Dès que le serveur est démarré, l’installer peut être téléchargé avec les identifiants de connexion initiaux saierp/bootStrap373746. Plus d’informations également dans cette documentation.

Les projets res_data contiennent des exports de données qui sont packagées pour les tests d’intégration. Elles permettent d’initialiser un serveur de test un ensemble de données cohérentes entre plusieurs modules.

Pour initialiser le serveur, cloner un des projets puis importer les données avec la commande suivante :

./run-server.sh \
    --runtime <runtime> \
    --import <res_data> \
    --start

Les données de test vont être importées et le serveur démarré. Une fois en ligne, il sera possible de s’y connecter avec les identifiants enregistrés.

La vidéo suivant montre comment récupérer les identifiants et se connecter au serveur de test local :

Les utilisateurs/mot de passe sont disponibles à travers le package java du projet lié dans les dépendances. La façon la plus simple de récupérer ces informations est de laisser l’IDE ouvrir le fichier après avoir fait <ctrl>+clique sur une des constantes utilisées pour les connexions dans les fichiers de test.

Lorsque le script run-test.sh est lancé sans l’option -R, un nouveau serveur va être démarré en utilisant un dossier temporaire (/tmp/srv-<id>). L’importation des données et le démarrage du serveur peuvent prendre quelques minutes et sont difficilement optimisables.

Afin de ne plus avoir à attendre le chargement et démarrage d’un nouveau serveur, il est possible d’indiquer au script d’utiliser un dossier <runtime> utilisé par un serveur déjà en cours d’exécution. Ainsi, les tests seront directement lancés sur les données présentes en l’état.

Pour illustrer le fonctionnement, commencer par démarrer un nouveau serveur de test:

./run-server.sh \
    --runtime ~/sw4_runtime \
    --import sw4 \
    --start

Une fois que le serveur est démarré, ajouter l’annotation @Tag("QuickRun") sur la méthode/classe désirée et lancer le script avec les paramètres suivants:

./run-test.sh sw4 -P quick-run -R ~/sw4_runtime

Le serveur en cours d’exécution sera automatiquement détecté et le test sera directement exécuté. Cela permet de pouvoir faire rapidement des modifications et nouveaux tests.

Pour commencer, démarrer un container docker pour MariaDB:

docker run --rm \
    -p "3306:3306" \
    --env MARIADB_DATABASE=sainet_prod \
    --env MARIADB_USER=sainet \
    --env MARIADB_PASSWORD=saijet \
    --env MARIADB_ROOT_PASSWORD=sairoot \
    --env MARIADB_AUTO_UPGRADE=true mariadb:latest \
    --default-time-zone=Europe/Zurich \
    --max-allowed-packet=1024m

Ensuite, simplement lancer la commande de démarrage du serveur de test en spécifiant les paramètres de connexion MariaDB via des variables d’environnement ainsi que l’option --tomariadb:

SAINET_DATABASE_HOST=localhost
SAINET_DATABASE_USER=sainet
SAINET_DATABASE_PASSWORD=saijet
SAINET_DATABASE_SCHEMA=sainet_prod
./run-server.sh --runtime ~/sainet_runtime --update --start --webapp --tomariadb

La première étape est de récupérer le dump des données. Généralement, certaines tables lourdes peuvent être ignorées.

mariadb-dump -u sainet -p --single-transaction sainet_prod \
  --ignore-table=sainet_prod.syscls \
  --ignore-table=sainet_prod.syspck \
  --ignore-table=sainet_prod.systop \
  --ignore-table=sainet_prod.unimut \
  --ignore-table=sainet_prod.salsal \
  --ignore-table=sainet_prod.salsav \
  --ignore-table=sainet_prod.gtpcal > /path/to/dump-partial.sql

Une fois le dump téléchargé sur sa machine, lancer la commande suivante pour démarrer une base de données MariaDB (adapter le chemin complet pour /path/to/dump-partial.sql):

docker run --rm \
    -v "/path/to/dump-partial.sql:/mnt/dump.sql" --name sainet_mariadb \
    -p "3306:3306" \
    --env MARIADB_DATABASE=sainet_prod \
    --env MARIADB_USER=sainet \
    --env MARIADB_PASSWORD=saijet \
    --env MARIADB_ROOT_PASSWORD=sairoot \
    --env MARIADB_AUTO_UPGRADE=true mariadb:latest \
    --default-time-zone=Europe/Zurich \
    --max-allowed-packet=1024m

La console va rester ouverte et bloquera tant que le container ne sera pas manuellement arrêté (il suffit de rajouter l’option --detach après --rm pour que le terminal rende la main directement).

Ensuite, l’identifiant du container peut être récupéré avec docker ps, puis obtenir une console dans celui-ci:

docker exec -ti <container_id> /bin/bash

Une fois dans le container, pour importer le dump:

cat /mnt/dump.sql | mariadb -u sainet -p sainet_prod

Lorsque le dump importé, la base de données est prête. Il faut maintenant installer SAINet et démarrer dessus.

Pour commencer, effectuer une installation vierge:

./run-server --runtime ~/sainet_runtime --install --defaults --noconsole

Ensuite, éditer le fichier ~/sainet_runtime/server.properties et changer les paramètres de connexion à la base de données (propriétés database.*). Penser également à adapter la propriété server.customerFile:

database.mariadb.host=localhost
database.mariadb.port=3306
database.mariadb.schema=sainet_prod
database.mariadb.user=sainet
database.mariadb.password=saijet
database.type=mariadb

server.customerFile=global

Finalement, démarrer le serveur SAINet sur la base de données locale:

./run-server.sh --runtime ~/sainet_runtime --update --start --webapp

Lorsque le serveur est démarré, l’URL et le driver JDBC doivent indiquer les données relatives à MariaDB:

Database: jdbc:mariadb://localhost:3306/sainet_prod?permitMysqlScheme (11.4.2-MariaDB-ubu2404)
JDBC driver: MariaDB Connector/J (3.4.1)

Lorsqu’un serveur a été démarré avec run-server.sh, il est automatiquement en mode debug avec le port 9009.

Un IDE peut donc y attacher un debugger avec la configuration ci-dessous:

Paramètre	Valeur
Debugger	JPDA
Connector	SocketAttach
Transport	dt_socket
Host	localhost
Port	9009
Timeout	10000

Une fois le debugger attaché, il suffit de mettre les points d’arrêt voulus et de lancer les différentes actions depuis le client riche.

Lorsque le serveur est lancé manuellement, les arguments suivantes doivent être utilisés pour pouvoir accéder au debugger:

java -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=9009 \
    -jar external/SNV4SRV-server/target/SNV4SRV-server-full-embedded.jar \
    --runtime <runtime> \
    --start

L’utilisation du paramètre -agentlib implique que le code à chaud (dbcode) sera compilé automatiquement avec l’option -g afin d’avoir les valeurs des variables locales durant la session de debug.

Il peut être parfois nécessaire d’utiliser le debugger dans les tests unitaires des librairies. Par défaut, la configuration utilisée par maven fait que l’IDE n’arrive pas à les exécuter.

Afin de pouvoir utiliser directement le debugger de l’IDE, effectuer les 2 étapes suivantes:

• dans les options maven, ajouter -P master afin de “forcer” l’exécution des tests.
• dans le pom.xml principal, supprimer les noeuds suivants du maven-surefire-plugin
  • <reuseForks>...</reuseForks>
  • <forkCount>...</forkCount>
  • <argLine>...</argLine>

Pour exporter les données du serveur en cours d’exécution, utiliser la commande export dans le prompt du serveur de la manière suivante. Le <path> doit pointer à la racine d’un des dossiers du groupe res_data.

export light <path>

Généralement, les seules modifications utiles sont:

• La base de données (root/h2dump.sql)
• Les fichiers GED (root/edms/ged)
• Le schema de la base de données (root/schema.sql)

Pour que des nouvelles données de test soient disponibles lors des tests d’intégration, il est nécessaire qu’elles soient publiées sur le Nexus de SAI ERP, via la procédure de mise à jour res_data.

De manière générale, cela n’est pas nécessaire car le serveur local sert lui-même les différents fichiers nécessaires (voir l’option --webapp dans run-test.sh).

Afin de développer le client web, suivre la procédure suivante:

• Démarrer un serveur de test local SAINet.
• Copier le fichier web/app/scripts/Config_template.ts vers web/app/scripts/Config.ts
• Éditer le fichier Config.ts pour le faire pointer sur le serveur local (http://localhost:9090/SNV4SRV-mobile-war).
• Lancer la commande suivante: npm run dev-server2.

Une fois le serveur nodejs démarré, le client web et accessible sur http://localhost:8080.

Un serveur local doit être préalablement démarré avec le paramétrage du portail de pré-inscription.

Le projet portail se nomme se nomme dev / creche-portal. Une fois le projet cloné, il est nécessaire d’initialiser le projet. À partir du fichier cre-portal / src / public / scripts / Config_templates.ts , créer un fichier Config.ts. À partir du fichier cre-portal / .env.sample, créer un fichier .env qui contiendra la configuration serveur du portail et ses accès. Dans ce dernier, les variables mentionnées ci-dessous doivent être initialisés :

• SAINET_URL url du serveur SAINet (par exemple https://localhost:9191/SNV4SRV-mobile-war/)
• SAINET_USER utilisateur du serveur local ayant accès au portail (par exemple admin, sadmin)
• SAINET_PASS mot de passe du serveur local ayant accès au portail
• SAINET_DOMAIN domaine du portail (POR)

Le projet doit initialiser les dépendances, compiler toutes les entrées du projet, puis lancer le projet portail avec ces trois commandes :

npm install
npm run build
node dist/server.js

Les différents concepts liés au portail et l’utilisation du debbuger sont disponibles dans la documentation du projet.

Lorsque le serveur de test local a fini de démarrer, un prompt est affiché permettant de directement agir avec ce dernier au niveau de l’Application Server (GlassFish). Différentes commandes sont à disposition pour faciliter le déveoppement SAINet, notamment pour recharger du code (reload-dbcode) ou du paramétrage (reload-config).

================================================================================
SAINet server is now running !
SAINet console is accessible through port 9019
--------------------------------------------------------------------------------
SAINet admin console is ready.
You can type 'help' to list available commands.

>>

Il est également possible d’automatiser les commandes via un script (typiquement utile lorsqu’une librairie doit être recompilée au préalable et ensuite rechargée). Cela peut se faire de la manière suivante:

mvn -q exec:java -pl external/SNV4SRV-server \
    -Dexec.args="--runtime <runtime_dir> --noconsole --command 'reload-dbcode SalaryEngine'"

La fonction ci-dessus peut-être mise dans le fichier ~/.bashrc afin d’être automatiquement disponible dans n’importe quelle console:

function sainet-exec
{
  if [ ! -d "external/SNV4SRV-server" ]; then
    echo "You're not in a SAINet GIT repository." >&2
    return 1
  fi
  
  if [ $# -lt 2 ]; then
    echo "Usage: sainet-exec <runtime_dir> <cmd> [args...]" >&2
    return 1
  fi
  
  runtime_dir="$1"
  shift
  
  socket_file="${runtime_dir}/.socket"
  if [ ! -f "$socket_file" ]; then
    echo "The file ${socket_file} does not exist." >&2
    echo "Either this is not a SAINet dir or the server is not running." >&2
    return 1
  fi
  
  command="$1"
  shift
  
  while [ $# -gt 0 ]; do
    command="$command $1"
    shift
  done
  
  mvn -q exec:java -pl external/SNV4SRV-server -Dexec.args="--runtime ${runtime_dir} --noconsole --command '$command'"
}

Elle s’utilise ensuite comme ceci (exemple avec un serveur local en cours d’exécution dans ~/sw4_runtime):

sainet-exec ~/sw4_runtime reload-dbcode SalaryEngine