Architecture du portail Liferay

Comment ça fonctionne vraiment (pour développeurs BPM & Enterprise Java)

Introduction

Si vous évaluez Liferay DXP ou si vous l’utilisez déjà pour des portails, une question revient toujours :

❓ Qu’y a-t-il réellement à l’intérieur de Liferay ?

La plupart des tutoriels expliquent comment créer un portlet,
mais très peu expliquent comment Liferay fonctionne vraiment en interne.

Comprendre l’architecture est critique quand vous :

  • Intégrez Liferay avec Camunda / jBPM

  • Appelez des APIs Spring Boot

  • Construisez des portails orientés workflow

  • Déboguez des incidents en production

  • Faites évoluer Liferay à l’échelle entreprise

Ce blog explique :

  • Les briques fondamentales de Liferay

  • Le flux des requêtes dans le portail

  • Le rôle d’OSGi

  • Comment les portlets, services et APIs s’imbriquent

  • Comment Liferay s’intègre dans une architecture BPM & microservices

Architecture globale du portail Liferay

À haut niveau, Liferay ressemble à ceci :

Navigateur utilisateur
         ↓
Serveur web / Load Balancer
         ↓
Portail Liferay (Tomcat / JBoss)
         ↓
Runtime OSGi
         ↓
Portlets / Modules
         ↓
Couche services
         ↓
Base de données

Explication des couches principales

1️⃣ Couche présentation (UI)

C’est ce que les utilisateurs voient et utilisent.

Composants :

  • Pages & layouts

  • Thèmes

  • Widgets

  • Portlets

  • Formulaires

  • Tableaux de bord

Cette couche est responsable de :

  • Rendu HTML

  • Gestion des actions utilisateur

  • Affichage des tâches de workflow

  • Présentation du contenu

2️⃣ Couche Portlet (modules applicatifs)

Un Portlet est la brique UI centrale de Liferay.

Chaque portlet :

  • Est une application Java

  • S’exécute dans le conteneur Liferay

  • Est déployée comme un module OSGi

  • Peut être développée et déployée indépendamment

Exemples :

  • Boîte de réception des tâches

  • Tableau de bord d’approbation

  • Formulaire de saisie

  • Module de reporting

3️⃣ Couche Runtime OSGi (le cœur de Liferay)

C’est ce qui fait de Liferay une plateforme, pas un monolithe.

Liferay utilise un conteneur OSGi pour gérer ses modules.

Ce qu’OSGi apporte :

  • Hot-deploy

  • Isolation des modules

  • Versioning des services

  • Résolution dynamique des dépendances

Cela signifie :

Vous pouvez déployer, mettre à jour ou supprimer des fonctionnalités sans redémarrer Liferay.

4️⃣ Couche Services (services métier & plateforme)

Liferay fournit des centaines de services intégrés :

  • Gestion des utilisateurs

  • Rôles & permissions

  • Organisations

  • Sites

  • Gestion de contenu

  • APIs de workflow

  • Recherche

  • Notifications

  • Bibliothèque de documents

Vous pouvez aussi créer vos propres services via :

  • Service Builder

  • APIs personnalisées

  • Endpoints REST

5️⃣ Couche d’intégration (REST, Headless, APIs)

Le Liferay moderne expose :

  • APIs REST

  • Services headless

  • GraphQL

  • OAuth2

Cela permet à Liferay de s’intégrer facilement avec :

  • Spring Boot

  • Les moteurs BPM (Camunda / jBPM)

  • Kafka

  • Des UIs externes

  • Des applications mobiles

6️⃣ Couche persistance (Base de données)

Liferay stocke :

  • Utilisateurs

  • Contenu

  • Permissions

  • État de workflow

  • Configuration

  • Entités personnalisées

Bases supportées :

  • MySQL

  • PostgreSQL

  • Oracle

  • SQL Server

Comment une requête traverse Liferay

Prenons un cas simple : un utilisateur ouvre une page du portail.

Navigateur
    ↓
Load Balancer
    ↓
Portail Liferay
    ↓
Moteur de thème
    ↓
Dispatcher de portlets
    ↓
Module OSGi
    ↓
Couche services
    ↓
Base de données
    ↓
Réponse HTML

Chaque portlet :

  • Traite sa partie de la page

  • Récupère des données

  • Appelle des APIs

  • Rend du HTML

Où s’inscrit OSGi

OSGi n’est pas optionnel dans Liferay.

C’est l’épine dorsale de :

  • Déploiement des portlets

  • Wiring des services

  • Isolation des plugins

  • Cycle de vie des modules

Tout dans Liferay est un bundle OSGi :

  • Portlets

  • Services

  • APIs REST

  • Connecteurs de workflow

Comment Liferay s’intègre dans une architecture BPM

Voici une architecture entreprise réelle :

Portail utilisateur (Liferay)
           ↓
   Services Spring Boot
           ↓
Moteur BPM (Camunda / jBPM)
           ↓
Kafka / Base de données / Systèmes externes

Cas d’usage BPM typiques

  • Workflows d’approbation

  • Tableaux de bord de tâches

  • Portails de gestion de cas

  • Onboarding RH

  • Parcours client

  • Approbation de documents

Liferay vs applications web traditionnelles

AspectApplication web classiquePortail Liferay
DéploiementMonolithiqueModulaire (OSGi)
UISur mesureBasée portail
UI workflowPersonnaliséeIntégrée
Gestion utilisateursÀ développerIntégrée
CMSOptionnelIntégré
SSOÀ développerIntégré
ScalabilitéNiveau applicationNiveau plateforme

👉 Liferay est une plateforme, pas juste une application web.

Erreurs d’architecture courantes 🚨

❌ Traiter Liferay comme un simple CMS
❌ Mettre de la logique métier lourde dans les portlets
❌ Ignorer les règles de dépendances OSGi
❌ Couplage fort avec les tables DB
❌ Utiliser uniquement des appels REST synchrones
❌ Ne pas externaliser la logique longue

Bonnes pratiques (éprouvées en production)

✔ Garder les portlets légers (UI uniquement)
✔ Mettre la logique métier dans Spring Boot
✔ Utiliser les APIs REST pour l’intégration
✔ Utiliser le BPM pour l’orchestration
✔ Utiliser Kafka pour les événements
✔ Utiliser les APIs headless
✔ Surveiller les bundles OSGi
✔ Optimiser la base et les caches

Question d’entretien (très fréquente)

Q : Quel est le concept architectural central de Liferay ?
R : Une plateforme portail modulaire construite sur OSGi, avec des portlets, des services et des APIs headless.

Conclusion

❗ Liferay n’est pas “juste un CMS”.
❗ C’est une plateforme portail entreprise complète.

Si vous construisez :

  • Des portails de workflow

  • Des applications BPM

  • Des tableaux de bord métier

  • Des plateformes digitales

Alors l’architecture de Liferay en fait la couche UI idéale au-dessus de :

  • Camunda

  • jBPM

  • Spring Boot

  • Kafka


💼 Support professionnel disponible

Si vous rencontrez des problèmes sur des projets réels liés au développement backend d’entreprise ou à l’automatisation des workflows, je propose des services de conseil payants, de débogage en production, de support projet et de formations ciblées.

Les technologies couvertes incluent Java, Spring Boot, PL/SQL, Azure, CMS, ainsi que l’automatisation des workflows (jBPM, Camunda BPM, RHPAM), DMN/Drools.

📧 Contact: ishikhanirankari@gmail.com | info@realtechnologiesindia.com

🌐 Website: IT Trainings | Digital lectern | Digital rostrum | Digital metal podium     


Comments

Post a Comment

Popular posts from this blog

jBPM Installation Guide: Step by Step Setup

  jBPM Installation Guide – Step by Step for Beginners If you are starting with jBPM (Java Business Process Management) , the first step is to set up your environment. In this guide, we’ll walk through how to install jBPM, configure it, and run your first business process. 🔎 What is jBPM? Before we dive into installation, a quick recap: jBPM is an open-source Business Process Management (BPM) suite , written in Java, that allows you to model, execute, and monitor workflows using BPMN 2.0 standards. It can run standalone , embedded in applications , or deployed on a Java EE server . 🖥️ Prerequisites Before installing jBPM, make sure you have: Java JDK 11 or later (Java 17 is commonly used) Maven 3.x (for building and managing dependencies) Git (optional, if you want to clone sample projects) A Database (H2, MySQL, PostgreSQL, or Oracle) – jBPM ships with H2 for testing At least 4GB RAM (8GB recommended for Workbench & KIE Server) 📦 Download ...
Read more

Scopes of Signal in jBPM

Image
💡 Introduction Signals in jBPM 7 are a core part of event-driven workflow design. They allow asynchronous communication between process instances, making it possible to start , interrupt , or coordinate processes without direct linking. However, signals can have different scopes , which define how far the signal travels and who receives it . Let’s explore the four available scopes in detail: 🔹 Process Scope 🔹 Default Scope 🔹 External Scope 🔹 Project Instance Scope 🧩 1️⃣ Process Scope 📘 Definition Process scope signals are local to a single process instance or its child subprocesses . They are not visible outside that instance hierarchy. 📋 Use Case Used for communication inside the same process , like triggering subprocesses or event sub-processes. 🖼️ Process Scope Example Below is an example of a simple process-scoped signal. Only this process (or its subprocess) will catch this signal. ⚙️ 2️⃣ Default Scope 📘 Definition The default scope ...
Read more

OOPs Concepts in Java | English | Object Oriented Programming Explained

Image
🔹OOPS (Object Oriented Programming System) in Java Object-Oriented Programming (OOPS) is a programming paradigm that uses classes and objects to design software. It simplifies development and maintenance by applying key concepts: 📌 Class: Class   is a user-defined data type which defines its properties and its functions. Class is the only logical representation of the data. For example, Human beings in an organisation is a class like Employee. The age, name, department, salary etc. of a human being/employee are its properties, and the jobs performed by the employees in an organisation are known as functions.  The class does not occupy any memory space till the time an object is instantiated. A class is a user-defined data type that defines properties and functions. For example: Class: Employee Properties: name, age, salary Functions: work(), attendMeeting() A class does not occupy memory until an object is created. ...
Read more