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-1. Brève présentation de ADempiere ERP

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/

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

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

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

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

architecture koosseryADempiere
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-1. Front-end de koosseryADempiere ERP: webapp basée sur Struts2 et Spring

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-1-1. Méthodologie de migration de ADempiere vers une webapp Struts2

L'architecture de la partie webapp est simple et basée sur Struts2.
A 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).

architecture du front-end de koosseryADempiereERP
Figure 2 : architecture du front-end de koosseryADempiereERP

II-1-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-2. 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 dit 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ée. 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

II-2-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 developper un service de haut niveau (service SVCO), un service simple (service SISV), et une classe DAO.

Structure du  framework FwkKoosseryJavaBE
Figure 3 : Structure du framework FwkKoosseryJavaBE

II-2-1-1. 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-2-1-2. 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-2-1-3. Couche services de haut niveau: SVCO

Il s'agit de la couche des services de haut niveau, c'est-à-dire ceux qui exposent leurs interfaces à 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-2-2. koosseryADempiere ERP: de ADempiere vers une architecture serveur orientée services

II-2-2-1. 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étiers 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 tiers.

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:

 exemple de migration vers le Server
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-2-2-2. 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 suffit 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-2-3. API pour lancer un process engine

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

 
Sélectionnez

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

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

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

A la fin de l'éxécution du process relatif au report qu'on veut voir, koosseryADempiere ERPkoosseryADempiere 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-2-5. DAO (Data Access Layer): utilisation du mapper O/R iBatis

La couche d'accès aux données de koosseryADempiere ERPkoosseryADempiere 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 ERPkoosseryADempiere ERP est un pojet Maven2 composé de sous-projet (modules maven2) représentés dans la figure ci-dessous:

 modules maven2 de koosseryADempiere
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-1. 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-2. 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-3. La partie Server de koosseryADempiere ERP

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

III-3-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-3-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-3-3. Sous-projet (module maven2): koosseryADempiere_SISV

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

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

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

III-4. Annexes

III-4-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-4-2. Librairies externes

Etant donné que le projet koosseryADempiere ERPkoosseryADempiere ERP s'appuie sur le noyau ADempiere, on distingue les librairies 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 ERPkoosseryADempiere ERP est un projet open-source sur SourceForge sur le lien suivant:
http://sourceforge.net/projects/ktadempiere/http://sourceforge.net/projects/ktadempiere/

Le wiki du projet se trouve sur le lien ci-dessous:
http://www.koosseryadempiere.org/wiki/). 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. Etat 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: 18 commentaires Donner une note à l'article (0)