🧩 WSO2 Micro Integrator : injecter des variables d’environnement à partir d’un fichier file.properties .

🔍 Pourquoi cette méthode ?

Je me souviens très bien de mes premiers pas en intégration avec WSO2 Micro Integrator. Comme beaucoup, je voulais externaliser mes configurations (URLs de bases de données, utilisateurs, mots de passe) dans un simple fichier .properties, sans toucher au deployment.toml. L’idée ? Un fichier .properties unique, facile à maintenir, et reconnu directement par WSO2 Micro Integrator via les variables d’environnement.

🎯 C’est exactement ce qu’on va faire dans cet article : charger un fichier .properties en variables d’environnement utilisables dans un projet WSO2 avant même de charger Micro Integrator. Nous allons plonger dans le script de démarrage, adapter quelques lignes pour lire ce fichier, puis valider la manière dont MI peut s’en servir via le placeholder Synapse "$env:...".

Et comme d’habitude, j’ai avec moi Marius, mon assistant IA au sens de l’analogie bien affûté ! 

🤖 Marius pose le décor :

« Imagine un restaurant où tous tes ingrédients sont déjà prêts, étiquetés, accessibles. Tu gagnes un temps fou en cuisine. C’est pareil ici ! »

1- 📚 Comprendre les bases

🔧 Pourquoi injecter un fichier .properties en variables d’environnement ?

Parce que dans beaucoup de projets, on dispose d’un fichier .properties (par exemple file.properties) sous la main contenant des paires cle=valeur, on aimerait pouvoir réutiliser ce fichier tel quel pour configurer WSO2 Micro Integrator sans avoir à réécrire toutes ces clés dans un autre format.

Alors, plutôt que de tout recopier ailleurs, autant convertir .properties en variables d’environnement pour un déploiement beaucoup plus moderne et comptaible avec Docker et Kubernetes, où la configuration se fait souvent via l’environnement.

🔎 Comment WSO2 Micro Integrato accède-t-il à ces variables ?

Dans un flux Synapse ou un mediator, on fait appel à "$env:..." pour récupérer la valeur d’une variable. Ainsi, si j’ai par exemple "$env:DB_URL", WSO2 ira vérifier si DB_URL est définie dans l’environnement du processus Java.

2.💡 Mise en pratique

📃 Modifier le script de démarrage

Pour injecter toutes les clés/valeurs d’un fichier .properties en tant que variables d’environnement, vous pouvez modifier le script micro-integrator.sh (ou l’équivalent) juste avant l’appel à la JVM. Supposons que votre fichier soit dans ./conf/file.properties, et que vous souhaitiez le charger comme suit :

<# -------------------------------------------------------------------
# 1) Charger le fichier ./conf/file.properties dans l'environnement
# -------------------------------------------------------------------
CONFIG_FILE="$WSO2_SERVER_HOME/conf/file.properties"

if [ -f "$CONFIG_FILE" ]; then
  echo "Loading environment variables from $CONFIG_FILE"
  while IFS='=' read -r key value
  do
      # Ignorer les lignes vides ou qui commencent par #
      if [ -z "$key" ] || [ "$(echo "$key" | cut -c1)" = "#" ]; then
          continue
      fi
      # Optionnellement, enlever les espaces autour
      key=$(echo "$key" | xargs)
      value=$(echo "$value" | xargs)

      # Exporter la variable
      export "$key"="$value"
  done < "$CONFIG_FILE"
else
  echo "No file.properties found at $CONFIG_FILE"
fi
printenv

# -------------------------------------------------------------------
# 2) Continuer le script normal : appeler la JVM pour lancer MI
# -------------------------------------------------------------------

# ... votre code existant, par exemple :
while [ "$status" = "$START_EXIT_STATUS" ]
do
    $JAVACMD \
    ...
    org.wso2.micro.integrator.bootstrap.Bootstrap $*
    status=$?

🧩 Que se passe-t-il ?

1. On définit la variable CONFIG_FILE="$WSO2_SERVER_HOME/conf/file.properties".
2. On vérifie si le fichier existe.
3. On lit le fichier ligne par ligne, en ignorant les lignes commentées ou vides.
4. Pour chaque ligne cle=valeur, on fait un export cle=valeur.
5. On poursuit ensuite le script normal (lancement de la JVM), qui bénéficiera ainsi de toutes les clés sous forme de variables d’environnement.

🤖 Marius explique :

«  C’est un peu comme donner un grand livre de recettes au chef : toutes les instructions sont disponibles dès qu’il en a besoin, sans devoir recopier quoi que ce soit à la dernière minute.  »

🧰 Exemple concret côté WSO2

Une fois que le script a exporté les variables d’environnement, vous pouvez les consommer dans vos configurations Synapse. Par exemple, si votre file.properties contient :

DB_URL=jdbc:postgresql://195.15.206.237:5432/odh_qa
DB_USER=admin
DB_PASS=HtCem5oHixpqFW

Vous pourrez écrire dans un mediator ou un class mediator :

<class name="com.amarena.Message2Database">
<property name="dbUrl" expression="$env:DB_URL"/>
<property name="dbUser" expression="$env:DB_USER"/>
<property name="dbPass" expression="$env:DB_PASS"/>
</class>

MI remplacera "$env:DB_URL" par la valeur de la variable d’environnement DB_URL. Vous n’avez ainsi plus besoin de coder en dur les paramètres dans votre configuration Synapse.

3- Bonnes pratiques à adopter

🧽 Garder un parsing simple

Le script proposé fonctionne bien pour des fichiers simples sous la forme CLE=VALEUR et ne contiennent pas de caractères spéciaux (ou d’espaces non gérés). Si vous utilisez des lignes plus complexes (multi-lignes, caractères spéciaux, etc.), il faudra adapter votre parsing.

💬 Marius : « Ta recette contient du safran et du yuzu ? Prends un bouquin de cuisine adapté, sinon tu vas galérer. »

🔐 Sécuriser les credentials

Attention : ces valeurs peuvent être sensibles (mots de passe…). Stocker des informations critiques dans un .properties en clair peut représenter un risque. Au minimum, veillez à :

• Restreindre les droits d’accès au fichier.
• Utiliser un mécanisme de chiffrement type “Secure Vault” dans WSO2.

🧭 Explorer les alternatives

WSO2 propose aussi :

• $FILE: pour injecter des propriétés dans certains endpoints.
• Fichier system.properties mentionné dans la documentation.
• Paramétrage via deployment.toml.

Mais si vous tenez absolument à avoir un file .properties et à réutiliser les mêmes informations sous forme de variables d’environnement, la méthode du jour reste la plus directe.

🔧 Compatibilité et portabilité

• Veillez à ce que la syntaxe du script (utilisation de bash, IFS=, etc.) soit compatible avec votre environnement (Linux, Docker, etc.).
• Le cut -c1 pour ignorer les commentaires suppose que votre caractère de commentaire est # au tout début de la ligne.

🚀 Conclusion : un script, une config centralisée, et moins d’erreurs

En résumé, injecter un fichier .properties en variables d’environnement avant même de lancer WSO2 Micro Integrator vous permet de :

• Centraliser vos paramètres dans un seul fichier.
• Éviter de multiplier les points de configuration.
• Bénéficier des placeholders "$env:..." directement dans vos médiators Synapse.

Cette approche est particulièrement pratique si vous avez déjà un pipeline d’intégration continue ou un déploiement Docker ou Kubernetes.

Mon conseil ? Tester sur un petit projet en démo, observez comment vos variables sont chargées, puis vérifiez en console (echo $DB_URL) que votre environnement est bien configuré.

💬 Marius : « Comme pour tout bon plat, n’oublie pas de tester ta recette avant le service. Un echo $DB_URL t’évitera bien des surprises. »

Vous utilisez une autre méthode ? Vous avez un retour d’expérience ou un piège à éviter ?

Partagez-le en commentaire ou contactez-moi via lmvi-conseil.fr. On aime bien les scripts qui marchent… et les projets bien câblés.

Bonne intégration à tous !