Module

Organisation des modules

Les différents modules sont décrits en détail dans la documentation fonctionnelle. Ici, nous nous concentrons exclusivement sur les aspects techniques. Ces modules se répartissent en trois grandes catégories, comme indiqué dans la présentation générale de l'architecture :

1. Le noyau :

   • Constitue la base essentielle du système.
   • Il fournit les services fondamentaux et transversaux nécessaires au bon fonctionnement de l'ensemble de l'application.

2. Les applications structurantes :

   • Incluent les fonctionnalités principales qui soutiennent le cœur des besoins de l'utilisateur.
   • Exemples :
     • Messagerie pour les communications internes.
     • Notifications pour les alertes et rappels.
     • Recherche pour l'exploration et la récupération de données.
     • Administration de l'utilisateur pour la gestion des comptes et des droits.

3. Les applications tierces :

   • Modules complémentaires intégrés pour répondre à des besoins spécifiques.
   • Souvent développées par des fournisseurs externes ou via des collaborations.

Certains modules, tels que le module d'actualités et le portail, sont regroupés dans un seul conteneur afin d'optimiser l'utilisation des ressources. Cette organisation reste toutefois facilement modifiable, permettant une flexibilité accrue en fonction des besoins ou des évolutions du système.

Objectif de la structure de module cohérente

Tous les modules dans Open ENT sont construits selon la même structure. Cela garantit la cohérence et facilite l'usage.

La structure cohérente des modules dans Open ENT sert plusieurs objectifs :

• Assure l'uniformité : En suivant une structure standardisée, tous les modules ont une présentation uniforme, ce qui facilite la navigation et la compréhension du code pour les développeurs.
• Favorise la ré-utilisabilité : La structure modulaire permet une réutilisation facile du code et des composants entre différents modules, réduisant la duplication et améliorant l'efficacité du développement.
• Simplifie la maintenance : Avec une structure cohérente, il est plus simple de maintenir et de mettre à jour les modules, car les changements peuvent être appliqués de manière uniforme à l'ensemble du code.

Caractéristiques du module

Les modules peuvent contenir des applications backend avec des services API REST ou des applications frontend et backend. Les technologies frontend peuvent être différentes :

• REACT
• Angular
• Qute

Les interfaces clientes Web développées en Angular ou React sont stockées dans src/main/resources/META-INF/resources.

Structure

Chaque module a la structure suivante :

module/
  README.md
  src/main/java
    ModuleMain.java
    ModuleVerticle.java
  src/main/resources
    application.properties
  src/main/resources/META-INF/resources
    (code bundle HTML / Javascript de l'interface Web)    

Comment ça fonctionne ?

Chaque module lance une application Quarkus qui inclut un serveur web intégré.

Ce serveur web est utilisé pour exposer des API REST ou d'autres points d'accès nécessaires pour interagir avec les fonctionnalités du module.

Le port par défaut sur lequel chaque module écoute varie selon sa configuration spécifique, afin d'éviter tout conflit dans un environnement multi-modules.

De plus, chaque module démarre un verticle Vert.x pour souscrire aux événements sur le bus d'événements. Cela permet une communication asynchrone et décentralisée entre les modules, essentielle pour la gestion des interactions dans un environnement de microservices.

Démarrer le module

Le module peut être démarré comme un module classique Quarkus.

mvn quarkus:dev -DPROFILE=native

Conteneur

Le module peut être packagé sous forme de conteneur Docker avec Quarkus :

mvn package -DPROFILE=native

(voir plus de détail dans la partie développement)

Variables d'environnement

Tous les modules contiennent des fichiers de configuration permettant de paramétrer le module. Les fichiers de configuration peuvent être surchargés par des variables d'environnement.

Voici l'ordre des priorités

Gestion des priorités

1. System Properties :

   • Les propriétés du système (ex. -Dproperty=value lors du démarrage) ont la plus haute priorité.

2. Environment Variables :

   • Les variables d'environnement ont également une priorité élevée, juste après les propriétés du système.

3. MicroProfile Config Sources :

   • Application Properties :
     • Les fichiers application.properties ou application-dev.properties sont des sources de configuration standard et ont une priorité moyenne.
   • Custom Config Sources :
     • Les sources de configuration personnalisées définies par l'utilisateur sont également de priorité moyenne, mais leur position dans la chaîne dépend de l'implémentation.
   • Config Profiles :
     • Les profils spécifiques dans les fichiers de configuration (comme application-dev.properties) ont la priorité la plus basse, mais peuvent remplacer les configurations standard selon le profil actif.

Plus d'information sont disponible dans la specification MicroProfile Config