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

ADempiere ERPADempiere 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 ERPCompiere 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/description complète de ADempiere ERP

ADempiere ERPADempiere ERP, bien qu'étant plus accessible que Compiere ERPCompiere 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 ERPkoosseryADempiere 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 :

- Maven2Maven2 : c'est un projet Maven2 ;

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

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

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

Le front-end de koosseryADempiere ERPkoosseryADempiere 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 ERPkoosseryADempiere ERP le framework DOZER est utilisé afin de convertir les DTO du back-end (partie Server) en les données des formulaires (*Form).

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

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 ERPkoosseryADempiere 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 ERPkoosseryADempiere 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.

II-B-1-a. Couche DAO▲

Il s'agit de la couche DAO. Toutes les interfaces des classes DAO de koosseryADempiere ERPkoosseryADempiere 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 ERPkoosseryADempiere 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 ERPkoosseryADempiere 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 ERPkoosseryADempiere 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 ERPkoosseryADempiere 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 ERPkoosseryADempiere 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 :

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▲

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▲

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

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

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).

Le Serveur de koosseryADempiere ERPkoosseryADempiere 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▲

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-1. Sous-projet (maven 2): FwkKoosseryJavaBE▲

III-D-2. Bibliothèques externes▲