koosseryADempiere ERP : une migration de ADempiere vers une architecture Struts2-Spring-iBatis

| Cedric ESSALE et Elvadas NONO (koosseryADempiere ERP core team) | Baké Jc. BAKENEGHE  (Software Coordinator) |

koosseryADempiere ERP est un ERP open source disponible sur SourceForge.
Cet ERP est construit à partir d'une migration de ADempiere vers une architecture Struts2-Spring-iBatis.

Vos réactions par l'intermédiaire de ce fil : Commentez

Les ERP deviennent de plus en plus incontournables dans les systèmes d'information des entreprises. Lorsqu'il faut implémenter un projet d'ERP, on est la plupart du temps souvent confronté à une offre riche et variée, tant propriétaire qu'open source.

Cet article s'adresse à tous ceux qui sont confrontés à des projets d'implémentation d'ERP, en particulier les développeurs Java de projet ERP et aussi dans une certaine mesure les décideurs.

- Titre : koosseryADempiere ERP : une migration de ADempiere vers une architecture Struts2-Spring-iBatis

- Auteurs : Cedric ESSALE et Elvadas NONO (koosseryADempiere ERP core team), Baké Jc. BAKENEGHE  (Software Coordinator)

- Parution : 22 juin 2009

- Mise à jour : 13 février 2020

- Licence :

Sommaire

- I. Introduction

- I-A. Brève présentation de ADempiere ERP

- I-B. Les raisons d'être de koosseryADempiere ERP

- II. koosseryADempiere ERP: une architecture 3-tiers classique (Struts2-Spring-iBatis)

- II-A. Front-end de koosseryADempiere ERP : webapp basée sur Struts2 et Spring

- II-A-1. Méthodologie de migration de ADempiere vers une webapp Struts2

- II-A-2. Utilisation d'un moteur MDA pour le code de la webapp

- II-B. Back-end de koosseryADempiere ERP : serveur orienté services, Spring, iBatis

- II-B-1. Description rapide d'un petit framework simple structurel SCA : FwkKoosseryJavaBE

- II-B-1-a. Couche DAO

- II-B-1-b. Couche services simples : SISV

- II-B-1-c. Couche services de haut niveau : SVCO

- II-B-2. koosseryADempiere ERP : de ADempiere vers une architecture serveur orientée services

- II-B-2-a. Méthodologie de migration vers une architecture serveur orientée services

- II-B-2-b. Génération du code de la couche serveur avec un outil MDA

- II-B-3. API pour lancer un process engine

- II-B-4. koosseryADempiere Data Report Engine: utilisation de jasper report

- II-B-5. DAO (Data Access Layer) : utilisation du mapper O/R iBatis

- III. koosseryADempiere ERP: un projet Maven2

- III-A. Sous-projet (module maven2) koosseryADempiere_FE : webapp Struts2

- III-B. Sous-projet (module maven2) koosseryADempiere_CORE_CONTRACT

- III-C. La partie Server de koosseryADempiere ERP

- III-C-1. Sous-projet (module maven2) : koosseryADempiere_CORE_BACKEND

- III-C-2. Sous-projet (module maven 2) : koosseryADempiere_DAO

- III-C-3. Sous-projet (module maven2) : koosseryADempiere_SISV

- III-C-4. Sous-projet (module maven2) : koosseryADempiere_SVCO

- III-D. Annexes

- III-D-1. Sous-projet (maven 2): FwkKoosseryJavaBE

- III-D-2. Bibliothèques externes

- IV. How to Setup le projet koosseryADempiere ERP

- V. État d'avancement du projet koosseryADempiere ERP

- VI. Vos Remarques

I - Introduction

Nous allons commencer par présenter brièvement ADempiere ERP. Puis nous présenterons ce qu'apporte koosseryADempiere ERP par rapport à ADempiere ERP.

I-A - Brève présentation de ADempiere ERP

ADempiere ERP est un ERP (ERP, progiciel de gestion intégré) open source populaire.

Il est issu d'un 'fork' de Compiere ERP : en effet le but principal du projet ADempiere ERP était d'aller en l'encontre du confinement de Compiere ERP dans des technologies obsolètes et une architecture fermée.

ADempiere ERP est un projet java dont quelques fonctionnalités sont :
-  gestion des achats ;
-  gestion des ventes et des points de vente ;
-  gestion de la comptabilité et production de tableaux de bord ;
-  gestion des stocks ;
-  etc.

Une description complète des fonctionnalités se trouve sur le lien suivant :http://adempiere.org/home/

I-B - Les raisons d'être de koosseryADempiere ERP

ADempiere ERP, bien qu'étant plus accessible que Compiere ERP ne reste tout de même encore pas évident pour une prise en main aisée par un développeur Java.

Par exemple nous avons du mal à distinguer clairement la couche présentation de la couche métier : elle reste top fortement liée au reste de l'application.
Pour ce qui concerne la couche métier, nous sommes tout de suite confrontés à une difficulté d'extraction de la logique métier de la base de données vers une couche externe.
Pour ce qui concerne l'accès en base de données, nous sommes confrontés à une difficile portabilité du fait de l'absence d'une couche de mapping (Data Mapper ou Mapping O/R).
Les développements de modules verticaux sont moins mis à disposition de la communauté Java pour servir les futurs projets.

Ce sont là quelques difficultés parmi tant d'autres sur lesquelles nous n'allons pas nous étendre ici.

Afin de rendre le projet Java plus classique, koosseryADempiere ERP va alors plus loin en réarchitecturant ADempiere sur la base de concepts SOA et en effectuant une migration totale de ADempiere afin d'obtenir un code basé sur les standards suivants :

- Maven2 : c'est un projet Maven2 ;

- Struts2 : c'est un projet web basé sur Struts2 ;

- Spring : c'est un projet 'service oriented' basé sur Spring (IoC, gestion des transactions applicatives, sécurité ACEGI, etc.) ;

- iBatis : c'est un projet dont la couche d'accès aux données repose sur le Data Mapper iBatis.

II - koosseryADempiere ERP: une architecture 3-tiers classique (Struts2-Spring-iBatis)

koosseryADempiere ERP a une architecture 3-tiers classique illustrée dans la figure ci-dessous :

Figure 1 : architecture koosseryADempiere

Dans la figure ci-dessus on a un front-end et un back-end.
Le front-end web MVC est construit à base du framework Struts2.
Le back-end est constitué d'un ensemble de services (SCA , service component architecture). Les services de haut niveau exposent leurs interfaces au front-end web.

II-A - Front-end de koosseryADempiere ERP : webapp basée sur Struts2 et Spring

Le front-end de koosseryADempiere ERP est une webapp construite avec Struts2 et Spring.

Tous les concepts novateurs de Struts2 sont exploités, notamment l'utilisation massive de fonctionnalités Ajax.

II-A-1 - Méthodologie de migration de ADempiere vers une webapp Struts2

L'architecture de la partie webapp est simple et basée sur Struts2.
À la base nous avons une classe abstraite (KTAdempiereBaseAction) qui regroupe toutes les méthodes et propriétés communes à toutes nos actions et qui étend la classe de base ActionSupport de Struts2.
La classe KTAdempiereBaseAction implémente aussi les interfaces ApplicationContextAware et SessionAware du framework Struts2.

Pour chaque vue, les données correspondantes du formulaire sont mises dans des POJO (ces POJO sont suffixés par 'Form').
Les classes *Form sont référencées dans nos Actions.

Dans koosseryADempiere ERP le framework DOZER est utilisé afin de convertir les DTO du back-end (partie Server) en les données des formulaires (*Form).

Figure 2 : architecture du front-end de koosseryADempiereERP

II-A-2 - Utilisation d'un moteur MDA pour le code de la webapp

Une fois l'architecture MVC de la webapp mise en place à base de Struts2, une bonne partie du code des différentes classes de la webapp a été générée à l'aide d'un moteur MDA : le moteur koosseryOPTIMADEV.

koosseryOPTIMADEV est un moteur MDA utilisé dans le Centre de Services 'Développement de Projet Au Forfait' de Koossery Technology. Il s'agit d'un moteur qui respecte les recommandations de l'OMG (Object Management Group).

Avec l'utilisation du moteur MDA koosseryOPTIMADEV, il suffit d'écrire les transformations XSLT qui prennent en entrée un fichier XMI produit par le projet UML fait avec l'outil Enterprise Architect et qui produisent en sortie une bonne partie du code des classes Actions, Forms, ainsi qu'une bonne partie des fichiers de configuration Spring. Le moteur koosseryOPTIMADEV génère aussi le squelette de nos pages jsp.

II-B - Back-end de koosseryADempiere ERP : serveur orienté services, Spring, iBatis

Le back-end est un serveur bâti selon les concepts SCA (Service Component Architecture). Nous avons un ensemble de services dits de haut niveau qui exposent leurs interfaces à la webapp.

On distingue les couches suivantes :

- une couche composée de services de haut niveau. Les services de haut niveau exposent leurs interfaces à la webapp. Les services de haut niveau sont suffixés par 'SVCO' (SVCO pour Service Composed), exemple : HR_PayrollSVCO ;

- une couche de services de bas niveau encore appelés services simples. C'est dans ces services que se concentre le métier. La couche des services simples est suffixée par 'SISV' (SISV pour Simple Services), exemple= HR_PayrollSISV. Pour fonctionner, la couche SVCO s'appuie sur la couche SISV ;

- une couche DAO pour l'accès à la base de données. L'implémentation de la couche DAO repose sur le mapper O/R iBatis. La couche SISV s'appuie sur la couche DAO.

Le back-end de koosseryADempiere ERP s'appuie sur des classes techniques d'un framework structurel simple et orienté SCA.
Il s'agit d'un framework SCA simple qui offre un ensemble de fonctionnalités techniques de base. La description rapide de ce framework simple est faite dans le paragraphe suivant.

II-B-1 - Description rapide d'un petit framework simple structurel SCA : FwkKoosseryJavaBE

Le back-end de koosseryADempiere ERP est construit en s'appuyant sur les fonctionnalités techniques offertes par un framework SCA simple.

Le framework FwkKoosseryJavaBE offre des classes de base pour développer un service de haut niveau (service SVCO), un service simple (service SISV), et une classe DAO.

Figure 3 : Structure du framework FwkKoosseryJavaBE

II-B-1-a - Couche DAO

Il s'agit de la couche DAO. Toutes les interfaces des classes DAO de koosseryADempiere ERP étendent l'interface IKTADempiereDataAccessObject.
L'interface IKTADempiereDataAccessObject quant à elle étend l'interface IDataAccessObject du framework FwkKoosseryJavaBE.

Pour ce qui concerne l'implémentation de la DAO, le framework offre la classe de base AbstractCommonDAO qu'étendent toutes les classes d'implémentations de la DAO.

II-B-1-b - Couche services simples : SISV

Il s'agit de la couche des services simples.
Pour fonctionner, la couche des services simples s'appuie sur la couche DAO.

Les interfaces des services simples de koosseryADempiere ERP étendent l'interface IKTADempiereSimpleService.
L'interface IKTADempiereSimpleService quant à elle étant l'interface ISimpleService du framework FwkKoosseryJavaBE.

Les implémentations des services simples étendent la classe AbstractCommonSISV.

II-B-1-c - Couche services de haut niveau : SVCO

Il s'agit de la couche des services de haut niveau, c'est-à-dire ceux qui exposent leur interface à la webapp. Pour fonctionner, la couche des services de haut niveau s'appuie sur la couche des services simples.

Les interfaces des services de haut niveau de koosseryADempiere ERP étendent l'interface IKTADempiereServiceComposed qui elle-même étend l'interface IServiceComposed du framework FwkKoosseryJavaBE.

Les implémentations des services de haut niveau étendent la classe AbstractCommonSVCO.

II-B-2 - koosseryADempiere ERP : de ADempiere vers une architecture serveur orientée services

II-B-2-a - Méthodologie de migration vers une architecture serveur orientée services

Pour illustrer de façon claire la méthodologie utilisée pour construire le serveur koosseryADempiere ERP sous forme de services à partir du noyau ADempiere, nous allons nous appuyer sur un exemple concret.

L'exemple consiste à migrer l'entité fonctionnelle C_BPartner vers un service SCA managé par Spring dans koosseryADempiere ERP.

L'entité fonctionnelle C_BPartner est composée de différentes classes : I_C_BPartner.java, X_C_BPartner.java et C_Bpartner.java.

Nous commençons par identifier clairement quelles sont les méthodes consommées par le client webapp(Struts2) de koosseryADempiere ERP et sur la base de ces méthodes, nous construisons la couche de service de haut niveau composée par l'interface IC_BPartnerSVCO et son implémentation C_BPartnerSVCOImpl. Ce service de haut niveau est le contrat présenté vers l'extérieur (ici la webapp) ; il définit toutes les méthodes exposées à la webapp.

Par la suite nous définissons la couche de service simple composée par l'interface IC_BPartnerSISV avec son implémentation C_BPartnerSVCOImpl. Les implémentations des services simples concentrent tous les algorithmes métier de base. Ces implémentations apparaissent comme des adaptateurs qui s'appuient sur le noyau 'ADempiere core' pour implémenter le métier. 'ADempiere core' apparaît alors comme un composant offrant des fonctionnalités tierces.

L'implémentation du service simple invoque donc notre composant tiers 'ADempiere core' et ensuite construit les classes DTO (data transfert objets) afin d'encapsuler les données à retourner à l'appelant qui est ici la couche SVCO (Services de haut niveau).

Pour notre exemple les classes DTO sont : l'interface IC_BPartnerDTO et son implémentation BPartnerDTO. On distingue aussi une classe criteria : C_BPartnerCriteria.

Ci-dessous le schéma illustrant notre exemple de migration :

Figure 4 : exemple de migration vers le Server

Le pont entre la webapp et le server est réalisé à travers le projet 'core.contract'. Ce projet contient tous les contrats qu'expose le serveur à l'extérieur. Cela inclut : les classes DTO (classes POJO de transfert des données), les classes d'exceptions que le serveur est susceptible de renvoyer vers l'extérieur, les interfaces de tous les services de haut niveau.

II-B-2-b - Génération du code de la couche serveur avec un outil MDA

Tout comme pour la partie webapp, une bonne partie du code des différentes couches du serveur a été générée à l'aide d'un moteur MDA (voir paragraphe).

Selon un principe similaire au paragraphe, il a suffi d'écrire les transformations XSLT qui prennent en entrée un fichier XMI résultat du projet UML du Serveur et qui produisent en sortie une bonne partie du code des classes des couches services, des couches DAO avec les fichiers de configuration du mapper O/R iBatis correspondant à la DAO générée.

II-B-3 - API pour lancer un process engine

koosseryADempiere ERP fournit une API pour lancer un process engine connaissant son ID dans la table AD_Process :

public int startProcess (Properties ctx,
int processID,
int recordID,
String [] paramNames,
Object[] paramValues) throws  KAdempiereException

II-B-4 - koosseryADempiere Data Report Engine: utilisation de jasper report

koosseryADempiere ERP Data Report Engine est l'engin de production des rapports.
Son fonctionnement est simple.

À la fin de l'exécution du process relatif au rapport qu'on veut voir, koosseryADempiere ERP Data Report Engine récupère le AD_INSTANCE_ID retourné par le process et invoque les méthodes appropriées dans les packages org.compiere.print.ReportEngine et org.compiere.print.DataEngine pour récupérer les données à imprimer.
Les données à imprimer sont dans les listes d'objet org.compiere.print.PrintData.

Les données de chaque objet PrintData sont extraites et mises dans des DTO et ces DTO sont retournées à la webapp. La webapp invoque alors le dispositif jasper report afin de générer les rapports sur la base de templates jasper report

II-B-5 - DAO (Data Access Layer) : utilisation du mapper O/R iBatis

La couche d'accès aux données de koosseryADempiere ERP s'appuie sur le mapping O/R iBatis.

Pour ce qui concerne les opérations de lecture, les requêtes de lecture sont écrites et externalisées dans des fichiers de configuration iBatis.

Pour ce qui concerne les opérations d'écriture et mise à jour de la base, la couche DAO utilise toujours le mapping O/R iBatis, mais celui-ci invoque des procédures stockées.

III - koosseryADempiere ERP: un projet Maven2

Le projet koosseryADempiere ERP est un pojet Maven2 composé de sous-projets (modules maven2) représentés dans la figure ci-dessous :

Figure 5 : modules maven2 de koosseryADempiere

On distingue :

- le sous-projet (module maven2) koosseryADempiere_CORE_CONTRACT ;
- le sous-projet (module maven2) koosseryADempiere _CORE_BACKEND ;
- le sous-projet (module maven2) koosseryADempiere _DAO ;
- le sous-projet (module maven2) koosseryADempiere _SISV ;
- le sous-projet (module maven2) koosseryADempiere _SVCO ;
- le sous-projet (module maven2) koosseryADempiere_FE ;
- le sous-projet (module maven2) FwkKoosseryJavaBE.

III-A - Sous-projet (module maven2) koosseryADempiere_FE : webapp Struts2

Le sous-projet (module maven2) koosseryADempiere_FE représente le front-end. C'est une webapp basée sur Struts2.

III-B - Sous-projet (module maven2) koosseryADempiere_CORE_CONTRACT

Le sous-projet (module maven2) koosseryADempiere_CORE_CONTRACT représente le contrat qu'expose le serveur à la partie webapp.

Ce sous-projet comprend les classes de transfert de données (DTO), les interfaces des services de haut niveau (les IxxxSVCO), les exceptions renvoyées par le serveur, les classes 'criteria' (XxxCriteria).

III-C - La partie Server de koosseryADempiere ERP

Le Serveur de koosseryADempiere ERP est constitué des sous-projets (module maven2) suivants : koosseryADempiere_CORE_BACKEND, koosseryAdempiere_DAO, koosseryADempiere_SISV, koosseryADempiere_SVCO.

III-C-1 - Sous-projet (module maven2) : koosseryADempiere_CORE_BACKEND

Dans le sous-projet koosseryADempiere_CORE_BACKEND, on retrouve les interfaces de la couche DAO et les interfaces de la couche des services simples.

III-C-2 - Sous-projet (module maven 2) : koosseryADempiere_DAO

Le sous-projet koosseryADempiere_DAO contient les implémentations des DAO. L'implémentation de la couche DAO s'appuie sur le mapper O/R iBatis.

III-C-3 - Sous-projet (module maven2) : koosseryADempiere_SISV

Ce sous-projet est constitué des implémentations des services simples.

III-C-4 - Sous-projet (module maven2) : koosseryADempiere_SVCO

Ce sous-projet est constitué des implémentations des services de haut niveau.

III-D - Annexes

III-D-1 - Sous-projet (maven 2): FwkKoosseryJavaBE

C'est le projet du framework SCA (service component architecture) sur lequel s'appuient les couches du serveur.

III-D-2 - Bibliothèques externes

Étant donné que le projet koosseryADempiere ERP s'appuie sur le noyau ADempiere, on distingue les bibliothèques externes suivantes :
- Adempiere.jar ;
- adempiereApps.jar ;
- CCTools.jar ;
- commons-javaflow-20060411.jar ;
- CSTools.jar ;
- j2ee.jar ;
- jasperreports-3.0.0-applet.jar ;
- jasperreports-3.0.0-javaflow.jar ;
- jboss.jar ;
- oracle.jar ;
- postgresql.jar ;
- sqlj.jar.

IV - How to Setup le projet koosseryADempiere ERP

Le projet koosseryADempiere ERP est un projet open source sur SourceForge sur le lien suivant :
http://sourceforge.net/projects/ktadempiere/.

Le wiki du projet se trouve sur le lien ci-dessous :
http://www.koosseryadempiere.org/wiki/).
Vous y trouverez toutes les informations techniques sur comment monter le projet sur un environnement de développement Eclipse ainsi que comment le déployer sur un serveur d'application.

V - État d'avancement du projet koosseryADempiere ERP

MODULE

STATUS

Accounting

100 %

Human Resources

100 %

Payroll

100 %

Referencial/Admin

finishing

Immo

In progress

Purchasing

In progress

Selling

In progress

POS

In progress

CRM

In progress

Stock Control

In progress

VI - Vos Remarques

Tous les remerciements au comité de relecture developpez.com.

N'hésitez pas à réagir par l'intermédiaire de ce fil : Commentez