RapportNereide PGoron

Université François R ABELAIS Tours
École Polytechnique Universitaire - Département Informatique

64, avenue Jean P ORTALIS
37200 Tours
Rapport de stage
Développements sur l’ERP libre Ofbiz
Reponsable de Stage : Étudiant :

Olivier H EINTZ Peter G ORON
Néréide EPU-DI 2e année
3 bis les Isles Année 2004
37270 Veretz
Table des matières
Remerciements 1
Introduction 2
1 Présentation de l’entreprise 3
1.1 Néréide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Le réseau Libre-Entreprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Le réseau Libre Partage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4 Le maître de stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2 Présentation d’Ofbiz 6
2.1 Son architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.1 Architecture générale . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.2 Architecture d’Ofbiz . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.3 Notion de composant . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2 Présentation du framework Ofbiz . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.1 Présentation de l’Entity Engine . . . . . . . . . . . . . . . . . . . . . 12
2.2.2 Présentation du Service Engine . . . . . . . . . . . . . . . . . . . . . 14
2.2.3 Présentation du ControlServlet . . . . . . . . . . . . . . . . . . . . . . 16
2.3 Présentation des applications Ofbiz . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3.1 Party . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3.2 Product . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3.3 Facility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3.4 Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3.5 Shipment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
i
TABLE DES MATIÈRES
2.3.6 Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3.7 Accounting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.3.8 Marketing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.3.9 Work Effort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.3.10 Human Ressources . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3 Présentation de Néogia 21
3.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2 Les générateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2.1 Processus de génération d’un composant Néogia . . . . . . . . . . . . 23
3.3 Les composants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.3.1 Composants fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.3.2 Composants techniques . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.3.3 Processus d’intégration des composants Néogia dans Ofbiz : . . . . . . 24
4 Mes réalisations au sein de Néréide 25

4.1 Amélioration du composant Order . . . . . . . . . . . . . . . . . . . . . . . . 26
4.1.1 Pourquoi ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.1.2 Cahier des charges . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.1.3 Présentation détaillée du composant Order . . . . . . . . . . . . . . . . 27
4.1.3.1 Organisation du composant . . . . . . . . . . . . . . . . . . 28
4.1.3.2 Processus de saisie d’un ordre . . . . . . . . . . . . . . . . . 29
4.1.3.3 Cycle de vie d’un ordre . . . . . . . . . . . . . . . . . . . . 33
4.1.4 Amélioration de l’interface de saisie des articles . . . . . . . . . . . . 34
4.1.4.1 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.1.4.2 Plan de développement . . . . . . . . . . . . . . . . . . . . 35
4.1.4.3 Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.1.5 Ajout d’une étape de saisie des acteurs . . . . . . . . . . . . . . . . . . 37
4.1.5.1 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.1.5.2 Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.1.6 Étude de la modification d’un ordre après sa création . . . . . . . . . . 43
4.1.6.1 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.1.6.2 Étude et mise en oeuvre . . . . . . . . . . . . . . . . . . . . 43
ii
TABLE DES MATIÈRES
4.1.6.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.2 Réorganisation de Néogia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.2.1 Mise en place d’une nouvelle organisation de Néogia . . . . . . . . . . 47
4.2.1.1 Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.2.1.2 Mise en oeuvre et résultats . . . . . . . . . . . . . . . . . . 47
4.2.2 Mise en oeuvre de Maven pour la gestion du projet Neogia . . . . . . . 49
4.2.2.1 Qu’est-ce que Maven ? . . . . . . . . . . . . . . . . . . . . 49
4.2.2.2 Mise en oeuvre . . . . . . . . . . . . . . . . . . . . . . . . 50
4.2.2.3 Problèmes rencontrés . . . . . . . . . . . . . . . . . . . . . 51
4.2.3 Mise en oeuvre d’un système d’automatisation de l’intégration de Néo-
gia dans Ofbiz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.2.3.1 Analyse des besoins . . . . . . . . . . . . . . . . . . . . . . 52
4.2.3.2 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.3 Intégration du composant Facility de Néogia dans Ofbiz . . . . . . . . . . . . 54
4.3.1 Mode opératoire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.3.1.1 Étude des dépendances inter-modules . . . . . . . . . . . . . 54
4.3.1.2 Solutions possibles . . . . . . . . . . . . . . . . . . . . . . 54
5 Bilan du stage 55
5.1 Bilan professionnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.2 Bilan personnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Bibliographie 56
A Plaquette de la société 57
iii
Liste des tableaux
2.1 Organisation d’Ofbiz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2 Composants du framework Ofbiz . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3 Moteurs de rendu du ControlServlet . . . . . . . . . . . . . . . . . . . . . . . 16
3.1 Composants fonctionnels de Néogia . . . . . . . . . . . . . . . . . . . . . . . 23

3.2 Composants techniques de Neogia . . . . . . . . . . . . . . . . . . . . . . . . 24
4.1 Organisation du composant Order . . . . . . . . . . . . . . . . . . . . . . . . 28

4.2 Les différents états d’un ordre . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.3 Nouvelle organisation de Néogia . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.4 Rôles identifiés pour le système de gestion des patchs . . . . . . . . . . . . . . 52
4.5 Scénarios identifiés pour le système de gestion des patchs . . . . . . . . . . . . 53
iv
Table des figures
2.1 Architecture n-tiers d’Ofbiz . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2 Architecture J2EE d’Ofbiz . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3 Architecture en couches d’Ofbiz . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4 Schéma fonctionnel de Entity Engine . . . . . . . . . . . . . . . . . . . . . . . 12
2.5 Exemple de définition d’entité . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.6 Schéma fonctionnel du Service Engine . . . . . . . . . . . . . . . . . . . . . . 14
2.7 Exemple de définition de service . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.8 Boucle d’évènements dans Ofbiz . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.1 Architecture de Neogia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.1 Point d’entrée dans l’application web « Order Management Application » . . . 27

4.2 Saisie d’un ordre – étape 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.8 Modèle de données simplifié du composant Order . . . . . . . . . . . . . . . . 32
4.9 Diagramme de séquence simplifié du processus de saisie d’un ordre . . . . . . 32
4.10 Cycle de vie d’un ordre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.11 Cycle de vie d’un OrderItem . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.12 Modification de l’interface de saisie des articles . . . . . . . . . . . . . . . . . 34
4.13 Modèle de données simplifié d’un OrderItem . . . . . . . . . . . . . . . . . . 35
4.14 Interface de saisie des acteurs réalisée . . . . . . . . . . . . . . . . . . . . . . 38
v
TABLE DES FIGURES
4.15 Modélisation existante des acteurs et des rôles dans order . . . . . . . . . . . . 38

4.16 Boucle d’évènements de la page de saisie des acteurs . . . . . . . . . . . . . . 39
4.17 Implémentation de la modification d’ordre dans l’interface d’administration . . 44
4.18 Modélisation POM du projet Néogia . . . . . . . . . . . . . . . . . . . . . . . 50
4.19 Site web Néogia entièrement généré par Maven . . . . . . . . . . . . . . . . . 51
vi
vii
Remerciements
Mes remerciements s’adressent en premier lieu à mon maître de stage, Oliver Heintz, pour
sa disponiblité et pour m’avoir laissé une grande autonomie dans mon travail. Je tiens aussi
à remercier toute l’équipe Néréide pour avoir fait de Néréide un lieu où il fait bon travailler.
Enfin, mes remerciements vont également à Jacopo Cappellato de Tau pour m’avoir conseillé et
encouragé sur les améliorations à apporter sur Ofbiz. Sans eux, ce stage n’aurait pas été aussi
intéressant et enrichissant.
Acknowledgments
In first place, I want to deliver my thanks to my training master, Olivier Heintz, for his
availability and to have let me a large autonomy in my work. I make a point of thanking Néréide
team to have made of Néréide a place where working is pleasant. Finally, my thanks are also
addressed to Jacopo Cappellato of Tau to have advised and encouraged me on the enhancements
to bring to Ofbiz. Without them this training wouldn’t have been so interesting and enriching.
1
Introduction
On ne présente plus les logiciels libres, aujourd’hui reconnus pour leur qualité et leur
ouverture. Ils ont démontré leur efficacité dans plusieurs domaines, notamment Internet, avec
par exemple, le serveur web Apache et le système d’exploitation Linux. Aussi, de nombreuses
entreprises et gouvernements ont commencé la migration de leurs systèmes d’information vers
des solutions libres.
En conséquence, on commence à trouver ces logiciels dans des secteurs traditionnellement
réservés aux logiciels propriétaires, en particulier, les PGI ou Progiciels de Gestion Intégrés.
Ainsi, les GNU Enterprise, Ofbiz, Compiere et autres viennent empiéter sur les terres de BAAN,
SAP, ORACLE, etc. Cependant, ce type d’application joue un rôle stratégique au sein des
entreprises qui les utilisent. Il requiert un très haut niveau de technicité et de compétences que
ces dernières ne sont pas prêtes à laisser aux mains de développeurs éparpillés aux quatre coins
du monde.
C’est pourquoi, comme pour les logiciels propriétaires, est apparue la nécessité d’avoir des
entreprises prestataires de services spécialisées en logiciels libres. Ce besoin s’est renforcé avec
la rationalisation des coûts liés aux systèmes d’information depuis l’éclatement de la « bulle
Internet ».
Néréide, société dans laquelle j’ai effectué mon stage de 2e année entre le 14 juin et le 25
septembre 2004, est une de ces nouvelles SSLL (Société de Services en Logiciels Libres). Elle
propose à ses clients un PGI basé sur le logiciel libre « OpenForBusiness » (Ofbiz) pour lequel
elle peut développer des besoins spécifiques pour chacun d’entre eux.
Au cours de ce stage, mon travail a consisté à comprendre le fonctionnement d’un PGI, à amé-
liorer le module de gestion des ordres d’achats et de ventes d’Ofbiz, et à intégrer les nouveaux
développements de la société dans Ofbiz. Ce stage m’a aussi permis de mieux comprendre
comment fonctionne une société de services et comment une SSLL peut vivre du logiciel libre.
2
Chapitre 1
Présentation de l’entreprise
1.1 Néréide
« La collaboration et les bonnes pratiques en action. »
Néréide est une jeune société de services en logiciels libres (SSLL) spécialisée dans l’inté-
gration de l’ERP Open Source Ofbiz. Créée en mars 2004 sous la forme d’une SARL à capital
variable, elle est située à 10 km à l’Est de Tours. Outre l’intégration d’Ofbiz, elle propose à
ses clients toute une gamme de services centrés autour de l’ERP : développements spécifiques,
administration système, infogérence, maintenance et support applicatif. Étant membre du réseau
Libre-Entreprise, cette offre peut être étendue selon les services que proposent les membres de
ce réseau (cf. section suivante).
Elle compte trois employés à temps complet en plus du gérant :
– Eric Barbier, Gérant de l’entreprise ;
– Catherine Heintz, Responsable de l’administration et de la communication ;
– Olivier Heintz, Directeur de projet ;
– Yannick Thebault, Architecte.
Durant ma période de stage, 2 stagiaires étaient présents :

– Nicolas Malin, DESS SIRAD ;
– Thierry Grauss, Département informatique de Polytech’ Tours.
3
1.2. LE RÉSEAU LIBRE-ENTREPRISE
1.2 Le réseau Libre-Entreprise
Le réseau Libre-Entreprise regroupe des entreprises ayant des spécialités proches ou com-
plémentaires, en particulier dans le domaine du logiciel libre. Toutes partagent les mêmes
valeurs et modes de fonctionnement, basés sur la clarté et la compétence. Le groupe est présent
en France (Biarritz, Marseille, Montpellier, Mulhouse, Nantes, Paris, Tours, Vandoeuvre-lès-
Nancy), en Belgique (Bruxelles) et au Canada (Montréal).
L’organisation en réseau permet à tous les membres de bénéficier d’une offre commerciale éten-
due homogène et de disposer d’un ensemble de ressources spécialisées dans chaque domaine
d’intervention grâce aux partages des connaissances. En outre, un ensemble d’outils de travail
collaboratif est mis à la disposition des membres du réseau pour simplifier la communication
au sein du réseau et pour les aider dans leurs démarches :
– documentations partagées :
– documents sur la création d’entreprise,
– documents techniques,
– modèles de documents ;
– calendrier partagé ;
– listes de diffusion partagées ;
– serveur de messagerie instantanée (Jabber) ;
– le laboratoire Libre-Entreprise : une plateforme d’hébergement de projets informatiques
tel que le célèbre SourceForge. Elle offre les mêmes services, à savoir, site web, espace
ftp, accès cvs, mailing-lists, etc.
– Planet Libre-Entreprise : c’est un agrégateur de contenu qui permet de suivre l’activité
des membres du réseau.
Pour faire partie du réseau, les sociétés doivent envoyer un compte-rendu mensuel d’activité sur
la liste de diffusion "réseau" afin que tous les membres puissent connaître l’évolution de chaque
entreprise. La forme exacte de ce rapport n’est pas définie mais certaines informations sont
nécessaires, comme une rapide présentation de l’entreprise, l’effectif, les finances, les affaires
en cours et les affaires probables.
4
1.3. LE RÉSEAU LIBRE PARTAGE
1.3 Le réseau Libre Partage

Libre Partage est un réseau de partage d’informations entre ses membres (des entreprises,
des indépendants, des associations) permettant à tous de progresser et d’atteindre les objectifs de
qualité et de méthodes de travail demandés par le réseau Libre-Entreprise. Les seules conditions
d’adhésion sont :
– avoir un fonctionnement démocratique ;
– être contrôlé par les personnes qui y travaillent ;
– souhaiter partager l’information avec les autres membres du réseau ;
– accepter de suivre des règles de bonnes moeurs ;
– et utiliser des logiciels libres.
1.4 Le maître de stage

Mon maître de stage est Olivier Heintz, Directeur de Projet. Avant de fonder Néréide avec
Yannick Thebault, ils ont travaillé de nombreuses années pour 1 des 6 premiers cabinets de
conseil international spécialisé dans la mise en oeuvre d’ERP propriétaires pour de grands
comptes, notamment pour BAAN et SAP. Ces expériences leur confèrent une très grande ex-
pertise, aussi bien fonctionnelle que technique, pour ce type d’application.
Olivier Heintz coordonne les différents développements en cours dans la société. En particulier
pour un nouveau projet appelé « Néogia » qui apporte une couche de persistance objet à Ofbiz
et permet la génération automatique de fichiers sources à partir d’une modélisation UML.
Enfin, il gère les différentes collaborations en cours avec d’autres sociétés, notamment :
– Code-Lutin, une SSLL nantaise, pour le développement des outils de génération de code
utilisés par le projet Neogia.
– Tau, une SSII italienne, pour le développement du composant manufacturing et l’amélio-
ration du composant order d’Ofbiz.
5
Chapitre 2
Présentation d’Ofbiz
Open For Business, ou Ofbiz, est un projet de progiciel de gestion intégré libre initié par
deux développeurs américains, Andy Zeneski et David E. Jones, en mai 2001. L’objectif de ce
projet est de fournir un ensemble de composants homogènes permettant de développer aisément
et rapidement des logiciels libres de gestion. À terme, il est prévu d’obtenir tous les composants
nécesssaires à un PGI intégrant les modules de gestion suivants :
– un ERP (Enterprise Resource Planning)
– un SCM (Supply Chain Management)
– un CRM (Customer Relationship Management)
– un MRP (Manufacturing Resource Planning)
– un CMS (Content Management System)
– un CMMS (Computerized Maintenance Management System)
– une plateforme de E-Business / E-Commerce
Pour atteindre ces objectifs, Ofbiz se base sur de nombreux logiciels libres tels que Subversion,
ant, Tomcat, JPublish, FreeMarker, etc. Ces logiciels sont reconnus pour leur qualité et ils as-
surent l’indépendance du projet. De même, Ofbiz respecte de nombreux standards pour garantir
un maximum de compatibilité avec les systèmes existants et futurs. En particulier, J2EE et XML
qui est largement utilisé dans tout le projet pour décrire les données et les traitements.
Par ailleurs, le code source du projet est publié sous la licence MIT qui est libre et permissive,
c’est-à-dire qu’elle ne fixe aucune obligation et/ou interdiction quant à l’utilisation, la mo-
dification, l’extension et la commercialisation du logiciel. Grâce à l’ouverture du code, une
véritable communauté d’utilisateurs et de développeurs s’est formée. Cette dernière assure ainsi
la réactivité et la qualité du projet.
6
Cependant, de par sa taille et sa complexité, ce type de logiciel nécessite de gros investissements
humains, matériels et financiers pour son développement mais aussi pour être reconnu. Les
auteurs initiaux ont donc créé une société, Undersun Consulting, qui offre des services autour
d’Ofbiz tout en les rémunérant pour leur travail de développement. Plusieurs sociétés du même
type se sont créées un peu partout dans le monde dont Néréide pour la France. Elles participent
ainsi au projet en tant que sponsors. Généralement, ces sociétés proposent quatre types de
services :
– l’installation et l’adaptation si nécessaire d’Ofbiz ;
– le développement d’extensions spécifiques à l’entreprise ;
– la maintenance du système ;
– la formation des utilisateurs.
Comme indiqué précédemment, un PGI est un logiciel complexe mettant en oeuvre de nom-
breux concepts de gestion. C’est pourquoi, la première partie de mon stage a consisté à com-
prendre l’architecture d’Ofbiz, son fonctionnement et à indentifier le rôle de ses différents
composants. La suite de cette présentation est donc la synthèse de cette étude. Elle permettra
ensuite de mieux situer les développements que j’ai effectué sur certains composants d’Ofbiz.
7
2.1. SON ARCHITECTURE
2.1 Son architecture
2.1.1 Architecture générale

Ofbiz est une application java client-serveur compatible avec la spécification J2EE définis-
sant une architecture logicielle standard. On retrouve ainsi les trois éléments caractéristiques
d’une architecture 3-tiers :
– les clients : ici des clients légers, typiquement des machines peu puissantes disposant d’un
navigateur internet ;
– un serveur exécutant les différentes applications Ofbiz ;
– et une ou plusieurs bases de données stockant le système d’information de l’entreprise.
F IG . 2.1 – Architecture n-tiers d’Ofbiz
Néanmoins, Ofbiz peut aussi être considéré comme une architecture n-tiers car elle peut faire
appel à des applications externes via des services. Ces derniers ne sont pas forcément exécutés
sur la même machine, on les appelle alors WebServices. Ce type d’architecture présente de nom-
breux avantages. Elle permet de distribuer plus librement la logique applicative, ce qui facilite
la répartition de la charge entre tous les niveaux. Elle facilite l’intégration de l’application avec
celles déjà existantes. Enfin, elle permet d’accéder à un très grand nombre de fonctionnalités.
Par exemple, dans le cadre d’une entreprise de vente par correspondance, il serait très facile
d’interroger les services de calcul des coûts de livraison des sociétés de transport travaillant
avec l’entreprise pour fournir à ses clients le prix exact des frais de port.
8
F IG . 2.2 – Architecture J2EE d’Ofbiz
2.1.2 Architecture d’Ofbiz

Une des caractéristiques principales d’Ofbiz est la modularité de son architecture. En effet,
tout est composant. Cette approche favorise une meilleure réutilisation des composants logi-
ciels, un développement modulaire donc plus rapide et enfin une meilleure qualité. Ce type
d’architecture permet aussi de remplacer un composant par un autre très facilement dans le cas
où il existe plusieurs implémentations différentes.
Ofbiz se décompose en deux parties : le serveur et les composants. Le serveur, ou base, propose
un environnement d’exécution homogène et performant pour les applications qu’il fait tourner.
Il fournit tout un ensemble de mécanismes de gestion de cache et de pools de connexions
qui permettent une meilleure montée en charge et une meilleure réactivité du système. Les
composants, quant à eux, représentent les plus petites briques logicielles gérées par le serveur.
ofbiz contient :
base le serveur d’application Ofbiz
config les différents fichiers de configuration du serveur : les composants à
charger, les certificats, les propriétés j2ee, etc.
dtd les grammaires des différents fichiers XML utilisés par le serveur.
libs les bibliothèques communes à tout le projet.
src le code source du serveur.
components tous les composants fournis par défaut avec Ofbiz.
data les fichiers de la base de données HypersonicSQL fournie par défaut
avec Ofbiz
hot-deploy des composants externes qui seront chargés automatiquement au démar-
rage du serveur (vide par défaut).
logs les fichiers d’activité du serveur.
TAB . 2.1 – Organisation d’Ofbiz
9
2.1.3 Notion de composant

Un composant représente le plus petit élément de l’architecture Ofbiz. Il peut fournir un
ensemble de ressources permettant de construire tout ou partie d’une application Ofbiz. Ces
ressources peuvent correspondre à : un jeu de données, un modèle de données, des services, une
ou plusieurs applications web, du code java. Généralement, un composant est spécialisé pour
une fonctionnalité donnée.
L’architecture d’Ofbiz se décompose en une multitude de composants qui, regroupés ensemble,
forment un PGI complet. Toutefois, tous n’ont pas le même rôle au sein du PGI, c’est pourquoi
on les classe selon trois niveaux d’abstraction :
– le framework qui permet de développer des applications métier rapidement ;
– les applications de base que l’on retrouve dans tout type d’organisation ;
– les applications de haut-niveau et/ou applications métier.
F IG . 2.3 – Architecture en couches d’Ofbiz
10
2.2. PRÉSENTATION DU FRAMEWORK OFBIZ
2.2 Présentation du framework Ofbiz

« Un Framework informatique est un ensemble de bibliothèques permettant le
développement rapide d’une application. Ils fournissent suffisamment de briques
logicielles pour pouvoir produire une application aboutie. Ces composants sont or-
ganisés pour être utilisés en interaction les uns avec les autres. Ils sont en principe
spécialisés pour un type d’application. On trouve différents types de Frameworks :
1. Framework d’infrastructure système : pour développer des systèmes d’exploi-
tation, des interfaces graphiques, des outils de communication. (exemple :
Eclipse)
2. Framework d’intégration Middleware : pour fédérer des applications hétéro-
gènes. Pour mettre à dispositions différentes technologies sous la forme d’une
interface unique. (exemple : Ampoliros avec ses interfaces RPC, SOAP, XML)
3. Framework d’application d’entreprise : pour développer des applications spé-
cifiques au secteur d’activité de l’entreprise. (exemple : Struts)
Les principaux avantages de ces Frameworks sont la réutilisation de leur code, la
standardisation du cycle de vie du logiciel (Spécification, développement, mainte-
nance, évolution). Ils permettent de formaliser une architecture adaptée aux be-
soinx de l’entreprise. Ils tirent partie de l’expérience des développements anté-
rieurs. Ces Frameworks sont en quelque sorte des progiciels extrêmement souples
et évolutifs. »
Wikipédia - L’encyclopédie libre
Ofbiz est en premier lieu un « framework d’application d’entreprise » dans lequel chaque com-
posant représente une brique logicielle pouvant être réutilisée pour construire des applications
diverses. Ce framework repose sur trois composants essentiels sans lesquels une application
standard ne pourrait pas fonctionner : l’Entity Engine, le Service Engine et le ControlServlet.
Composant État Description

Entity Engine stable Gère la persistance des données d’une application et la
transparence d’accès à ces données.
Service Engine stable Gère tous les traitements d’une application et les rend
accessibles à d’autres applications via des WebServices.
ControlServlet stable Gére les intéractions entre les utilisateurs et une application
web ainsi que la logique applicative.
Rules Engine prévu Implémente un moteur d’inférence pour modéliser des sys-
tèmes experts.
Workflow Engine stable Gère l’enchaînement des traitements d’une application.
Data Analysis prévu Implémente un moteur d’analyse de données. (Fouille de
données, datamining, statistiques, etc.)
SecurityEngine stable Gère l’accès sécurisé à une application
TAB . 2.2 – Composants du framework Ofbiz

11
2.2.1 Présentation de l’Entity Engine

L’Entity Engine est un composant Ofbiz qui se charge de la gestion des données de tous
les autres composants Ofbiz. Les données sont représentées selon un modèle Entité-Relation
largement utilisé dans les applications d’entreprise et compatible avec la plupart des bases de
données relationnelles. Le principal objectif de ce composant est d’éliminer tout code spécifique
à la persistance des données dans un système transactionnel.
Ses principales caractéristiques sont :
– accès aux données via une interface unique, le « GenericDelegator ».
– supporte l’accès transparent à plusieurs base de données.
– les entités sont définies dans de simples fichiers XML.
– tous les types java de base ont un équivalent en base de données.
– supporte les transactions distribuées.
– suppporte un mécanisme de trigger appelé « EECA1 » même si le SGBD sous-jacent
n’implémente pas cette fonctionnalité.
F IG . 2.4 – Schéma fonctionnel de Entity Engine
Le GenericDelegator est le coeur de l’Entity Engine. Il peut être considéré comme une interface
à une base de données relationnelle « virtuelle » issue de l’agrégation d’une ou plusieurs bases
de données relationnelles « réelles ». Les utilisateurs n’ont pas à se soucier des différences
existant entre les SGBD, le délégator assure un comportement homogène. L’accès aux don-
nées s’effectue par son interface unifiée. Cette interface permet d’effectuer des opérations de
1 Entity Event-Condition-Action
12
création, d’enregistrement, de suppression, de recherche, de mise en cache des données.

Les définitions des entités sont lues au démarrage du serveur et ce dernier vérifie leur validité
et leur cohérence par rapport aux bases de données sous-jacentes. Si des différences existent,
l’Entity Engine peut créer automatiquement les tables, les champs et les relations manquantes.
<entity entity-name="Party"
package-name="org.ofbiz.party.party"
title="Party Entity">
<field name="partyId" type="id-ne"></field>
<field name="partyTypeId" type="id-ne"></field>
<field name="externalId" type="id"></field>
<field name="createdDate" type="date-time"></field>
<field name="createdByUserLogin" type="id-vlong"></field>
<field name="lastModifiedDate" type="date-time"></field>
<field name="lastModifiedByUserLogin" type="id-vlong"></field>
<prim-key field="partyId"/>
<relation type="one" fk-name="PARTY_PTY_TYP" rel-entity-name="PartyType">
<key-map field-name="partyTypeId"/>
</relation>
<relation type="one" fk-name="PARTY_CUL" title="CreatedBy"
rel-entity-name="UserLogin">
<key-map field-name="createdByUserLogin" rel-field-name="userLoginId"/>
</relation>
<relation type="one" fk-name="PARTY_LMCUL" title="LastModifiedBy"
rel-entity-name="UserLogin">
<key-map field-name="lastModifiedByUserLogin" rel-field-name="userLoginId"/>
</relation>
<relation type="many" rel-entity-name="PartyTypeAttr">
<key-map field-name="partyTypeId"/>
</relation>
<index name="EXTERNAL_ID_IDX">
<index-field name="externalId"/>
</index>
</entity>
F IG . 2.5 – Exemple de définition d’entité
L’Entity Engine d’Ofbiz est utilisé par plusieurs projets libres, notamment JIRA une application
J2EE assurant le suivi et la gestion des bugs d’un projet informatique (équivalent Java à BugZilla).
Ce composant est reconnu pour son efficacité et ses performances. Il démontre l’intérêt des
briques logicielles réutilisables.
13
2.2.2 Présentation du Service Engine

Le Service Engine est l’équivalent de l’Entity Engine pour tous les traitements des com-
posants Ofbiz. Les traitements sont appelés Services et peuvent être exécutés localement ou à
distance. Le principal intérêt de ce composant est qu’il permet de lancer des services sans avoir
besoin de connaître leur localisation et leur implémentation. C’est le ServiceDispatcher qui se
charge alors de trouver l’implémentation du service et de son exécution. Un autre intérêt est la
possibilité de rendre disponible tout service Ofbiz vers l’extérieur.
F IG . 2.6 – Schéma fonctionnel du Service Engine
Les services sont définis dans des fichiers XML dans lesquels il faut indiquer pour chaque
service :
– son nom ;
– son implémentation (java, beanshell, minilang, etc) ;
– sa localisation ;
– la méthode à invoquer lors de son appel ;
– la nécessité ou non d’être authentifié pour pouvoir l’appeler
– ses paramètres d’entrée ;
– ses paramètres de sortie ;
Un service est un traitement qui prend des paramètres en entrée et des paramètres en sortie. Ces
paramètres sont vérifiés avant et après l’appel d’un service. Le traitement peut être asynchrone
ou synchrone. L’accès aux entités à partir d’un service se fait automatiquement par l’intermé-
14
diaire d’une transaction ainsi en cas d’échec du service, la cohérence des bases de données est
conservée.


<service name="calcTax" engine="java"
location="org.ofbiz.order.order.OrderServices" invoke="simpleTaxCalc">
<description>Simple Calc Tax Service</description>
<attribute name="productStoreId" type="String" mode="IN"/>
<attribute name="itemProductList" type="java.util.List" mode="IN"/>
<attribute name="itemAmountList" type="java.util.List" mode="IN"/>
<attribute name="itemShippingList" type="java.util.List" mode="IN" optional="true"/>
<attribute name="orderShippingAmount" type="Double" mode="IN" optional="true"/>
<attribute name="shippingAddress" type="org.ofbiz.entity.GenericValue" mode="IN"/>
<attribute name="orderAdjustments" type="java.util.List" mode="OUT"/>
<attribute name="itemAdjustments" type="java.util.List" mode="OUT"/>
</service>
F IG . 2.7 – Exemple de définition de service
15
2.2.3 Présentation du ControlServlet

Le ControlServlet est l’élément clé de la communication entre les utilisateurs et les ap-
plications web d’Ofbiz. Implémenté selon le modèle MVC (Modèle-Vue-Controleur), il gère la
boucle d’évènements de l’interface graphique et les différents moteurs de rendu de l’application.
Les réponses aux intéractions de l’utilisateur s’effectuent par l’intermédiaire d’évènements qui
peuvent être implémentés sous la forme de services, de méthodes java, de scripts Beanshell ou
Minilang.
Un moteur de rendu se charge de renvoyer à l’utilisateur une vue d’un document généré à partir
des évènements précédents et/ou de données. Les moteurs de rendu dont dispose Ofbiz :
Moteur Description
JSP Les Java Server Pages permettent de générer des pages HTML
dynamiquement.
JPublish + FreeMarker JPublish permet de construire une page HTML à partir de plu-
sieurs fichiers traités par FreeMarker et d’appeler pour chacun
d’entre-eux des scripts BeanShell à différents moments de la
construction. FreeMarker est un moteur de template qui permet
de générer des documents dynamiquement.
FOP + FreeMarker FOP est un processeur XSL qui transforme un document XML
traité avec FreeMarker en un document HTML ou PDF.
JasperReport JasperReport permet de réaliser très facilement des rapports à
partir de multiples sources de données.
TAB . 2.3 – Moteurs de rendu du ControlServlet
Voici l’ensemble des opérations effectuées suite à une intéraction avec l’utilisateur pour lui
afficher une page à l’aide de JPusblish et FreeMarker (cf. fig. 2.8 ) :
16
F IG . 2.8 – Boucle d’évènements dans Ofbiz
1. L’utilisateur clique sur un lien hypertexte ou valide un formulaire. Le navigateur envoie

alors une requête HTTP au serveur Ofbiz qui est interceptée par Tomcat et transmise au
ControlServlet de l’application web correspondante.
ex : https://127.0.0.1:8443/ordermgr/control/orderview?order_id=WS10000
2. Le ControlServlet vérifie si l’URI demandée est définie par l’application. Le cas échéant,
il appelle le ou les événements associés à cette URI. Dans le cas contraire, il renvoie une
erreur au navigateur web de l’utilisateur (Erreur HTTP 404 : page non trouvée).
3. Si l’évènement généré doit appeler un service, il vérifie que les paramètres de la requête
correspondent aux attributs du service.
4. Si l’évènement généré doit appeler un service, il convertit les paramètres de la requête
sous forme textuelle en objets Java correspondant.
5. L’évènement appelle un service ou un gestionnaire d’évènements (méthode java statique).
6. Le service ou le gestionnaire d’évènements peuvent effectuer des actions sur le modèle
de données.
7. L’EntityEngine convertit ces actions en requêtes SQL pour le serveur de base de données.
8. Le service ou le gestionnaire d’évènement renvoie le résultat de leur action.
9. L’évènement transmet ce résultat au ControlServlet.
10. À partir du résultat de l’évènement, le ControlServlet sélectionne la vue à afficher et
appelle le moteur de rendu adéquat.
11. À partir de la définition d’une vue, le moteur de rendu construit les différents sous-
éléments de cette dernière.
17
2.3. PRÉSENTATION DES APPLICATIONS OFBIZ
12. Pour chaque sous-élément, il peut appeler des scripts BeanShell qui récupèrent et mettent
en forme les données à afficher.
13. Pour chaque sous-élément, il appelle le moteur de template qui se charge de générer le
code HTML correspondant.
14. Le moteur de rendu assemble les différents sous-éléments pour former une page web
complète.
15. Le controlServlet transmet la page générée au navigateur web de l’utilisateur.
2.3 Présentation des applications Ofbiz
2.3.1 Party
Le composant Party est la base d’une application de gestion des relations de l’entreprise
(CRM). Un contact peut représenter soit une personne physique soit un groupe (un groupe
pouvant être une entreprise, un organisme ou un ensemble de personnes). La notion de groupe
permet de modéliser des hiérarchies, des groupes de sécurité. Cette application est généralement
utilisée pour gérer les informations sur le personnel de l’entreprise, sur les relations avec ses
clients et ses fournissseurs, etc.
À chaque contact, on peut associer de nombreuses informations telles que des adresses, des nu-
méros de téléphones, des rôles, et par un mécanisme d’extension, des données supplémentaires.
2.3.2 Product
L’application Product gère les catalogues de produits d’une entreprise. Les produits sont
organisés en catégories et en nomenclatures. Une catégorie est une structure hiérarchique dans
laquelle un produit peut appartenir à plusieurs catégories. L’application gère aussi la notion de
variante pour un même produit.
Un catalogue de produits est aussi un point de départ pour toutes les informations de prix. En
effet, plusieurs prix peuvent être associés à un produit comme peuvent l’être les coûts. Les prix
peuvent être fixés pour différentes monnaies, différents stocks ou magasins et pour différentes
périodes de l’année (périodes normales et période des fêtes de Noël pour les jouets par exemple).
Pour chaque prix associé à un produit, on trouve deux informations : fromDate et thruDate. Ces
dates sont respectivement la date à partir de laquelle le prix est valide et la date à partir de
laquelle il ne l’est plus. Par exemple, cela peut être utilisé dans le cas de promotions ou lors de
changements de prix et permettre de garder ainsi un historique des prix d’un produit.
18
2.3.3 Facility
L’application Facility s’occupe de la gestion des stocks de l’entreprise et dispose de quelques
outils de logistique. L’élément important est l’InventoryItem qui représente un élément de stock
pouvant être associé à un bâtiment et même à un endroit spécifique du bâtiment. En relation
avec un produit, il conserve les informations sur les quantités disponibles immédiatement et à
venir, sur les seuils d’alerte, sur les quantités économiques, etc.
Un autre élément important est le « Facility » qui représente un bâtiment ou un emplacement
physique. Différents types de bâtiments sont possibles comme les stocks, les magasins, les
docks, les bureaux, les pièces d’un bâtiment, etc. Les bâtiments peuvent être regroupés en
groupe de bâtiments, eux-mêmes pouvant faire partie de groupes de bâtiments. Ces groupes
sont par exemple des chaînes de magasins, régions, départements. Des personnes ou groupes
de personnes peuvent aussi être associés à des bâtiments pour définir où une personne travaille,
qui gère le bâtiment, etc.
2.3.4 Order
L’application Order joue un rôle fondamental dans l’activité commerciale de l’entreprise
en gérant les ordres d’achat et de vente passés par ses clients ou par elle-même pour ses
fournisseurs. Elle permet la saisie, le suivi et le traitement des ordres ainsi que la gestion des
retours de marchandises.
Un ordre se compose d’un en-tête de commande et de lignes de commandes qui décrivent les
détails de l’ordre et des ajustements tarifaires. Ces ajustements correspondent aux promotions,
aux taxes et aux frais de ports appliqués à l’ordre.
Une demande pour un produit peut être suivie et être éventuellement transformée en nécessité
qui sera ensuite utilisée pour créer un « Work Effort », qui satisfera le besoin.
2.3.5 Shipment
L’application Shipment gère l’ensemble des échanges de produits avec l’extérieur autrement
dit les réceptions et les expéditions ainsi que les entrées et sorties de stock. Un Shipment est
composé de ShipmentItem, chacun représentant une certaine quantité d’un produit à expédier.
Shipment fait aussi le lien avec les services des transporteurs pour le suivi des colis et des
livraisons.
2.3.6 Content
Les entités Content ou Contenu gèrent les documents. Elles sont utilisées pour enregistrer et
manipuler les contenus généraux et les bases de connaissance. Ces entités incluent de nombreux
concepts tels que : la séparation de l’information et l’organisation des données qui peuvent être
19
utilisées dans beaucoup de structures de données comme des arbres, listes ou des Maps d’objets.
À partir de là, des outils évolués de recherche d’information peuvent être créés pour automatiser
la création de nouvelles structures et permettre à l’entreprise de gérer les documents. Cette
application est largement utilisée pour associer des éléments entre les différents composant
d’Ofbiz.
2.3.7 Accounting
Cette application est actuellement en phase de développement. Elle doit permettre à terme
de gérer les comptabilités clients et fournisseurs ainsi que celle de l’entreprise elle-même. Les
entités de comptabilité sont organisées par date et sur des principes comme la comptabilité à
double entrée, un registre général avec des comptes hiérarchisés.
2.3.8 Marketing
Ce module est utilisé pour suivre les campagnes de marketing et les informations reliées
comme les contacts : courriels, listes de diffusion ou téléphonique.
2.3.9 Work Effort

L’application Work Effort peut être considérée comme la couche de persistance des données
du moteur de Workflow. Les unités manipulées par un Workflow sont des « Work Efforts ».
Ils peuvent représenter une tâche, une phase d’un projet, quelque chose à faire et même une
gamme ou une activité d’une gamme. Il s’agit principalement d’un processus semi-automatique
qui implique des activités automatiques réalisées par la machine et manuelles réalisées par une
personne ou par un dispositif externe contrôlé par une personne.
2.3.10 Human Ressources

Les entités de ressources humaines sont utilisées pour suivre les positions, responsabilités,
compétences, salaires et autres informations en relation avec la gestion du personnel.
20
Chapitre 3
Présentation de Néogia
Bien qu’Ofbiz soit un logiciel écrit en Java, ses auteurs ont privilégié une approche Entité-
Relation plutôt qu’une approche orientée objet pour la modélisation du système d’information
de l’entreprise. Ce choix est motivé par un souci de simplicité et de généricité au niveau de la
couche de persistence de données d’Ofbiz (Entity Engine). Cependant, ce type de modélisation
présente le problème de s’attacher plus aux données qu’à la dynamique du système. En consé-
quence, on est souvent amené à manipuler directement les tuples de la base de données ce qui
peut poser des problèmes de cohérence et de duplication de code. De plus, cette approche ne
permet pas d’utiliser le haut niveau d’abstraction qu’offre le langage de programmation.
Pour pallier à cet inconvénient, Néréide a entrepris en mai 2004 le développement d’un nouveau
projet appelé « Néogia », publié sous la licence GPL. L’objectif de ce projet est de fournir à la
communauté un ensemble d’outils et d’extensions permettant de développer des applications
Ofbiz à l’aide d’une modélisation objet. Ces extensions se présentent sous la forme de compo-
sants Ofbiz générés à partir de diagrammes UML. Le temps gagné par la technique de généra-
tion de code employée dans Néogia permet aux développeurs de se consacrer principalement à
la modélisation de leur application et donc d’augmenter la qualité du produit final.
Les outils de génération de code utilisés par le projet Néogia se basent sur une technologie mise
au point par Code-Lutin, une société de services en logiciels libres nantaise, membre du réseau
Libre-Entreprise et spécialisée dans le développement applicatif en Java. Cette technologie,
appelée « LutinGenerators », permet à partir d’une modélisation UML stockée dans un fichier
XMI1 de générer n’importe quel type de fichier dès l’instant qu’un générateur correspondant
existe. L’utilisation de cette technologie est le fruit d’une collaboration entre Néréide et Code-
Lutin dans le cadre d’un transfert de compétences au sein du réseau Libre-Entreprise.
1 Format XML permettant l’échange de modèles UML entre outils de développement logiciel.
21
3.1. ARCHITECTURE
3.1 Architecture
Le projet Néogia fournit donc des générateurs de code basés sur les LutinGenerators qui
permettent la création de tous les fichiers nécessaires à un composant Ofbiz à partir de dia-
grammes UML grâce à une phase de génération. Le composant est ensuite directement installé
dans Ofbiz via un processus d’intégration spécialisé.
F IG . 3.1 – Architecture de Neogia
3.2 Les générateurs

Les générateurs se chargent de créer toute la couche de persistance de données entre les
objets issus de la modélisation et les entités gérées par l’Entity Engine d’Ofbiz, et de créer
l’interface graphique et les services associés. L’intérêt des composants généré par Néogia par
rapport aux composants Ofbiz est qu’ils sont issus de diagrammes UML et que leur code est
généré à 70 %. L’un des reproches qui est souvent fait aux outils de génération de code est
de ne pas pouvoir distinguer les éléments générés des éléments développés lors de générations
successives. Les générateurs de Neogia ont été conçus pour éviter ce genre de cas en séparant
les parties développées des parties générées.
22
3.3. LES COMPOSANTS
Voici quelques générateurs fournis par Néogia :

– générateur de services ;
– générateur d’entités ;
– générateur de la couche d’abstraction Objet<->Entité ;
– générateur d’interfaces graphiques par défaut pour les objets modélisés ;
– générateur des formulaires de recherche ;
– générateur des fichiers d’internationalisation.
3.2.1 Processus de génération d’un composant Néogia

1. Édition du diagramme UML du composant avec un outil graphique tel que Poséidon
UML.
2. Transformation du fichier UML en un fichier XML plus simple à traiter par les généra-
teurs LutinGenerators
3. Les générateurs de code sont ensuite appelés successivement pour créer les différents
fichiers nécessaires à un composant Ofbiz.
4. Le développeur écrit ensuite des extensions au code généré dans des fichiers dits « déve-
loppés ».
3.3 Les composants

On distingue deux types de composants parmi ceux fournis par Néogia, les composants
fonctionnels et les composants techniques. Les premiers apportent une véritable valeur ajoutée
à Ofbiz alors que les seconds servent juste à intégrer le mieux possible Néogia au sein d’Ofbiz.
3.3.1 Composants fonctionnels
Composant Rôle
Manufacturing Remplace complètement le composant de même nom sous Ofbiz. Il
remplit les mêmes fonctions mais a été entièrement repensé à partir
d’une modélisation UML.
Facility Remplace le module de gestion des stocks d’Ofbiz. Le modèle de
données a été entièrement revu et il apporte en plus la gestion des
inventaires physiques.
Accounting Remplacera le composant Accounting d’Ofbiz et supportera la compta-
bilité analytique.
ServiceMgnt gère toutes les activités de services ou d’un projet. Il n’y a pas
d’équivalent dans Ofbiz.
TAB . 3.1 – Composants fonctionnels de Néogia
23
3.3. LES COMPOSANTS
3.3.2 Composants techniques

Le rôle de ces composants est d’adapter, dans la mesure du possible, les interfaces d’Ofbiz
à celles de Neogia et inversement. Par exemple dans Néogia, chaque entité est représentée par
un objet et toutes les opérations vers la base de données sont effectuées via cet objet. Certains
composants fonctionnels de Néogia dépendent de composants existants dans Ofbiz, si l’on veut
accéder aux entités de ces composants en utilisant les mécanismes d’appel de Neogia, on est
obligé de les modéliser sous Néogia pour que l’objet adéquat soit généré.
Composant Rôle
Common permet de stocker les énumérations et les statuts utilisés dans Neogia
dans les entités correspondantes d’Ofbiz.
Order permet d’accéder aux entités OrderHeader et OrderItem d’Ofbiz.
Party permet d’accéder aux entités du composant Party d’Ofbiz.
Product permet d’accéder aux entités du composant Product d’Ofbiz et redirige
une partie de la gestion des stocks vers le composant Facility de Neogia.
TAB . 3.2 – Composants techniques de Neogia
3.3.3 Processus d’intégration des composants Néogia dans Ofbiz :

1. Récupération de la version de référence d’Ofbiz ;
2. Copie de la version de référence d’Ofbiz en ofbizNeogia ;
3. Application de tous les patchs d’intégration sur ofbizNeogia ;
4. Copie des composants Néogia dans ofbizNeogia.
24
Chapitre 4
Mes réalisations au sein de Néréide
Au cours de mon stage, j’ai eu la chance de pouvoir effectuer de nombreuses tâches dif-
férentes dans divers domaines : modélisation UML, codage, intégration, gestion de projet ou
encore écriture de documentation. Mon travail chez Néréide a essentiellement porté sur les trois
axes suivants :
1. ajout de fonctionnalités au composant Order d’Ofbiz pour le rendre utilisable dans un
commerce de type « business to business » ;
2. réorganisation du projet Néogia pour faciliter son utilisation et ses évolutions futures ;
3. intégration du composant Facility de Neogia dans Ofbiz.
Ces différentes réalisations vont maintenant être décrites en détail dans les sections suivantes.
À chaque fois que cela est possible, les objectifs initiaux, les outils et méthodes utilisés, et le
résultats obtenus sont donnés afin de mieux cerner le travail réalisé.
25
4.1. AMÉLIORATION DU COMPOSANT ORDER
4.1 Amélioration du composant Order
4.1.1 Pourquoi ?
Le composant Order joue un rôle primordial dans un ERP comme Ofbiz ; en relation avec
les composants Product, eCommerce et Accounting, il gére l’ensemble des ordres d’achats et
de ventes passés par l’entreprise ou par ses clients. Il se doit donc d’être parfaitement adapté
au type de commerce que l’entreprise effectue avec ses clients et/ou fournisseurs. En effet, des
contraintes peuvent varier sur ce composant selon que l’on se trouve dans un commerce de type
B2C (« Business to Consumer ») ou dans un commerce de type B2B (« Business to Business »).
Dans le second cas, le client a plus de pouvoirs au regard des volumes et des sommes échangés.
Il peut exiger, par exemple, le respect des dates de livraison sous peine de pénalités financières.
Dès sa création, Order a été pensé avec le souci de prendre en compte les contraintes du
commerce B2B. Cependant, toutes les fonctionnalités associées à ce type de commerce ne sont
pas encore accessibles car le composant est toujours en phase de développement. Bien que
ses fondations soient stables (les modèles de données et les services existent et sont prêts à
être utilisés en production), l’interface graphique du composant n’offre pas encore toutes les
fonctionnalités sous-jacentes.
4.1.2 Cahier des charges

Néréide m’a donc chargé d’apporter quelques modifications à ce composant afin le rendre
plus facilement utilisable dans un commerce de type B2B. C’est aussi pour moi un moyen de
découvrir le framework Ofbiz et son utilisation. Les modifications apportées correspondent aux
besoins fonctionnels suivants :
1. Pouvoir saisir des informations complémentaires sur un ordre comme la date de livraison
souhaitée ou un commentaire.
2. Pouvoir saisir les personnes et/ou groupes liés à un ordre. Par exemple : le vendeur, le
donneur d’ordre, etc.
3. Étudier la possibilité de modifier un ordre après sa création. Exemple de scénario : modi-
fier la quantité commandée suite à une erreur de saisie.
Besoins non fonctionnels :

1. Éviter la modification du modèle de données.
2. Être le moins invasif dans le code existant.
3. Envoyer les modifications effectuées aux mainteneurs d’Ofbiz pour une future intégration
dans Ofbiz.
Ce cahier des charges a été établi en collaboration avec Jacopo Cappelato. Les besoins exprimés
correspondent à de réels besoins exprimés par des clients de la société (Tau) dans laquelle il
travaille.
26
Avant de poursuivre sur les améliorations apportées à ce module, il est nécessaire de saisir son
fonctionnement interne, objet de la section suivante, pour la bonne compréhension de la suite
de ce rapport.
4.1.3 Présentation détaillée du composant Order

Le composant Order est riche en fonctionnalités : il permet de saisir un ordre, de saisir les
paiements effectués, d’effectuer les réservations de stock nécessaires, d’envoyer des notifica-
tions aux clients, de suivre son état d’avancement, d’établir les plannings de livraison et enfin
de gérer les retours de produits. Toutes ces fonctionnalités sont accessibles via une application
web : « Order Management Application » (cf. Fig. 4.1).
Cette richesse de fonctions rend le composant Order complexe et peu abordable au débutant.
Pour donner une idée, Order compte près de 170 services et 125 entités. C’est pourquoi, son
étude appronfondie ne se limitera qu’aux éléments qui interviennent dans la suite de ce rapport :
– Présentation de l’organisation du composant order pour comprendre à quel niveau et à
quel endroit se situent les modifications.
– Présentation du processus de saisie pour identifier tous les éléments qui interviennent
durant la saisie.
– Présentation du cycle de vie d’un ordre de vente.
F IG . 4.1 – Point d’entrée dans l’application web « Order Management Application »
27
4.1.3.1 Organisation du composant
ofbiz/components/order/ contient :
build/ les fichiers générés pendant la compilation
config/ les fichiers de configuration du composant
data/ les données du composant
email/ les scripts de notification par email
entitydef/ les définitions du modèle de donnée
scripts/ les scripts en minilanguage
servicedef/ les définitions des services
src/ les fichiers sources java du composant
webapp/ les applications web du composant
ordermgr/ l’application de gestion des ordres
entry/ le code des pages et des formulaires de l’interface de saisie d’un ordre
error/ le code de gestion des erreurs
lookup/ le code des formulaires de recherche
order/ le code de l’interface d’édition des ordres saisis
reports/ le code de l’interface des rapports
return/ le code de l’interface de gestion des retours
templates/ le code commun à toutes les pages de l’application
WEB-INF/ les paramètres de l’application web
actions/ les scripts de mise en forme des données de l’application
pagedefs/ les définitions des pages de l’application
controler.xml définit les points d’entrée de l’application (URI)
jpublish.xml définit les paramètres du moteur de template
web.xml définit les paramètres de l’application web
build.xml définit les règles de construction du composant
ofbiz-component.xml définit les ressources du composant ofbiz (données, services, webapps)
TAB . 4.1 – Organisation du composant Order
Dans Ofbiz, tous les composants respectent à peu près la même organisation pour faciliter
la maintenance du projet. Les répertoires les plus importants sont entitydef, servicedef, src
et webapp. De même, toutes les applications web disposent du répertoire WEB-INF et des
fichiers web.xml et controler.xml. La plupart des modifications apportées touche l’application
web ordermgr située dans le répertoire webapp. Notamment les dossiers entry, lookup, order,
actions et pagedefs.
28
4.1.3.2 Processus de saisie d’un ordre
La première étape de ce processus consiste à créer un objet sur le serveur que l’on appelle le
« ShoppingCart ». Ce dernier peut être considéré comme le pannier ou le caddie souvent utilisé
sur les sites de eCommerce. Cet objet permet de conserver toutes les informations saisies par
l’utilisateur pendant toute la durée de la session jusqu’à la création ou l’annulation de l’ordre.
Durant cette étape, l’utilisateur doit choisir le type d’ordre : vente ou achat. Pour la suite, on ne
travaille qu’avec des ordres de vente pour simplifier la compréhension et ne pas surcharger ce
rapport.
Saisie du type d’ordre (vente

ou achat) et du donneur
d’ordre.
F IG . 4.2 – Saisie d’un ordre – étape 1
L’étape suivante est la plus importante de tout le processus. L’utilisateur ajoute des produits
à son ordre. L’ajout d’un produit déclenche automatiquement le calcul des promotions et des
règles de prix. Toutes ces informations sont conservées dans le ShoppingCart.
Saisie des produits à inclure

dans l’ordre.
29
Saisie de l’adresse de
livraison.
L’étape 4 permet de saisir des informations complémentaires pour la livraison :

– sélection de la méthode de livraison avec estimation des frais de port.
– autorisation ou non de séparer la commande en plusieurs envois.
– saisie des instructions à donner au livreur.
– si la commande est un cadeau, saisie d’um message personnel à délivrer.
Saisie des options de

livraison.
30
Saisie de la méthode de
paiement.
Confirmation de l’ordre.
Après avoir confirmé l’ordre, l’objet ShoppingCart est utilisé pour insérer dans la base de
données toutes les données saisies. La figure 4.8 donne l’ensemble des entités créées lors de
cette opération. Le ShoppingCart est ensuite réinitialisé pour pouvoir être réutilisé.
31
F IG . 4.8 – Modèle de données simplifié du composant Order
F IG . 4.9 – Diagramme de séquence simplifié du processus de saisie d’un ordre
32
4.1.3.3 Cycle de vie d’un ordre
De sa création à sa finalisation, un ordre va passer par de nombreux états intermédiaires qui

déterminent les actions que l’on peut effectuer sur ce dernier. En outre, le passage d’un état à
un autre peut dépendre de conditions complexes. Les diagrammes d’état suivants présentent les
différents états et leur précédence par lesquels un ordre et ses orderItem peuvent passer, le but
étant d’avoir une idée assez précise de leur cycle de vie.
Created l’ordre vient d’être créé et est en attente de paiement

Rejected l’entreprise a refusé le traitement de l’ordre
Processing l’ordre est en attente de paiement et en cours de traitement par
l’entreprise
Canceled l’ordre a été annulé par le client
Approved le paiement a été reçu et les produits sont en cours de préparation
Send la commande a été expédiée
Completed le client a reçu la livraison
TAB . 4.2 – Les différents états d’un ordre
F IG . 4.10 – Cycle de vie d’un ordre
F IG . 4.11 – Cycle de vie d’un OrderItem
33
4.1.4 Amélioration de l’interface de saisie des articles

4.1.4.1 Objectifs
Le but de cette première modification est d’ajouter, pour chaque article saisi dans un ordre,
un commentaire et une date de livraison souhaitée. (cf. Fig. 4.12). Ces nouvelles informations
nécessitent l’ajout de champs supplémentaires dans le formulaire de saisie d’un article et elles
doivent être affichées pour les articles précédemment saisis. Enfin, l’interface graphique doit
être pensée de manière à simplifier la saisie de ces informations par l’utilisateur. Par exemple,
il n’est pas rare d’avoir à saisir plusieurs articles successifs ayant les mêmes informations.
F IG . 4.12 – Modification de l’interface de saisie des articles
34
4.1.4.2 Plan de développement
Le plan de développement suivi pour réaliser cette première modification sera réutilisé pour
toutes les autres modifications du composant Order. Il se décompose en trois étapes :
1. Vérifier que le modèle de données contient les entités et les champs nécessaires pour
intégrer la modification souhaitée. Cette étape est particulièrement importante lorsque
l’on souhaite éviter de modifier le modèle sous-jacent.
2. Réaliser l’interface graphique : écriture des fichiers d’interface, des scripts de récupéra-
tion et de mise en forme des données, et définition des nouveaux points d’entrée dans le
ControlServlet.
3. Implémenter les services et les évènements associés.
Réaliser l’interface graphique avant les services peut sembler incorrect par rapport à un dé-
veloppement traditionnel mais cette solution permet de tester plus simplement les services
pendant leur phase de développement. En effet, contrairement à l’interface graphique qui peut
être modifiée durant l’exécution d’Ofbiz, la modification d’un service entraîne le plus souvent
un arrêt suivi d’un redémarrage du serveur ce qui fait perdre à chaque fois 3 à 4 minutes.
4.1.4.3 Solution
1. Vérification du modèle de données

Les informations à ajouter concernent un article saisi, représenté dans le composant Order par
l’entité OrderItem. L’étude de son modèle de données, défini dans le fichier entitymodel.xml
situé dans le dossier entitydef du composant, a permis d’extraire le modèle simplifié représenté
par la figure 4.13. L’entité OrderItem contient des champs comments et estimatedDeliveryDate
qui pourraient être utilisés pour nos besoins, une rapide recherche au sein d’Ofbiz ayant montré
qu’ils n’étaient pas encore utilisés.
F IG . 4.13 – Modèle de données simplifié d’un OrderItem
35
2. Réalisation de l’interface graphiqe

L’interface graphique de l’étape à modifier est définie dans le fichier showcart.ftl situé dans
le dossier webapp/ordermgr/entry du composant Order. Ce fichier contient le code HTML à
afficher ainsi que des instructions FreeMarker qui permettent la mise en forme de la page et la
récupération de données depuis le moteur de rendu. Voici la liste des modification effectuées :
1. Ajout des deux nouveaux champs au formulaire de saisie d’un article ainsi que des cases à
cocher pour utiliser les valeurs saisies comme valeur par défaut pour les articles suivants.
Pour simplifier la saisie de la date de livraison souhaitée, un lien vers un calendrier a été
ajouté.
2. Dans le listing des articles saisis, les informations ont été ajoutées pour chaque ligne. Les
données à afficher auront été préalablement placées dans le contexte du moteur de rendu
par un script BeanShell.
3. Écriture de ce script qui récupère les informations à afficher depuis le ShoppingCart et
qui les met en forme pour le moteur de rendu.
4. Modification de la déclaration de la page showcart.ftl pour que le script précédent soit ap-
pelé avant la génération de la page. Cette déclaration est située dans le fichier webapp/WEB-
INF/pagedefs/entry/showcart.xml.
3. Modification des évènements et du ShoppingCart

Maintenant que l’interface graphique est prête, il faut que lorsque l’utilisateur ajoute un article
à un ordre, les informations saisies soient conservées jusqu’à la création effective de l’ordre.
Pour cela, on utilise le ShoppingCart en apportant les modifications suivantes :
1. Modification du ShoppingCart et des ShoppingCartItem pour qu’ils conservent ces nou-
velles informations et les transmettent au service de création d’ordre le moment venu.
2. Modification du gestionnaire d’évènement appelé lorsqu’un article est ajouté pour qu’il
valide les informations saisies et les transmette au ShoppingCart.
Le détails des opérations nécessaires pour réaliser cette petite amélioration a pour but de montrer
la complexité du système. En effet, il faut un certain temps pour appréhender les différents
mécanismes mis en oeuvre par le ControlServlet. Cependant, cette complexité permet de réaliser
des applications puissantes.
36
4.1.5 Ajout d’une étape de saisie des acteurs

4.1.5.1 Problématique
Dans une entreprise, la gestion des achats et des ventes est une fonction essentielle. De
nombreux acteurs interviennent à différents moments dans la passation d’un ordre et il est
impératif que l’entreprise conserve ces informations. Par exemple, il est courant de verser des
commissions aux vendeurs sur la base du nombre de commandes passées. Souvent, dans un
commerce entre deux entreprises, on conserve le nom et les coordonnées de la personne avec
laquelle on peut faire des affaires. Toutes ces informations sont la base d’un système de gestion
des relations clients/fournisseurs (CRM1 ).
Un acteur, ou Party dans le vocabulaire Ofbiz, peut désigner une personne physique, un groupe
de personnes ou bien un organisme. Il est possible de lui assigner différents rôles. Ainsi, dans le
cadre de la gestion des ordres d’achats et de ventes, on trouve généralement les rôles suivants :
– la personne qui a passé commande ;
– la personne à qui la facture sera adressée ;
– la personne qui a traité l’ordre ;
– la personne qui a réalisé la vente ;
– le transporteur chargé de la livraison ;
– etc.
Actuellement, le composant Order n’offre pas la possibilité de saisir les différents acteurs et
leurs rôles respectifs durant la saisie d’un ordre. Or ce type d’information est essentiel dans
un commerce de type B2B. C’est pourquoi Néréide m’a demandé d’ajouter une étape durant
la saisie d’un ordre pendant laquelle l’opérateur peut saisir ces différentes informations. La
solution a été établie sur la base du cas d’utilisation suivant :
1. Avant de confirmer un ordre, l’opérateur se voit proposer la saisie des acteurs.
2. Il sélectionne un acteur à ajouter.
3. Il choisit les rôles à associer à ce dernier.
4. Il valide sa saisie.
5. Soit il retourne en 2 pour saisir de nouveaux acteurs, soit il passe à la confirmation de
l’ordre.
À tout moment, l’opérateur doit pouvoir visualiser les acteurs et rôles déjà saisis et pourvoir les
supprimer avant de passer à l’étape suivante.
Pour réaliser cette solution, le plan de développement suivi est le même que pour l’amélioration
précédente.
1 CRM : Customer Relationship Managememnt
37
F IG . 4.14 – Interface de saisie des acteurs réalisée
4.1.5.2 Solution
1. Vérification du modèle de données

La première chose à faire a donc été de vérifier que le modèle de données disposait des tables
et des champs nécessaires pour implémenter cette nouvelle fonctionnalité. La figure 4.15 est un
extrait de la modélisation existante des acteurs et des rôles au sein du module order.
F IG . 4.15 – Modélisation existante des acteurs et des rôles dans order
Après quelques recherches au sein du composant Order, il s’avère que le modèle de données
existe mais est peu utilisé pour l’instant.
38
2. Réalisation de l’interface graphique

L’objet de cette partie est d’avoir une vision globale sur l’ensemble des fichiers créés et/ou mo-
difiés pour réaliser cette interface. Pour suivre le processus de développement, cette présentation
suit l’enchaînement des actions réalisées dans la boucle d’évènements présentée dans la figure
4.16. Comme le montre la figure 4.14, l’interface se compose de deux parties : un formulaire de
saisie (SetAdditionalParty.ftl) et un listing des acteurs déjà saisis (additionalPartyListing.ftl).
F IG . 4.16 – Boucle d’évènements de la page de saisie des acteurs
1. Il faut déclarer les points d’entrée de notre extension ainsi que la vue utilisée dans le
contrôleur de l’application web (ordermgr/WEB-INF/controller.xml).
39
<request-map uri="setAdditionalParty">
<security https="true" auth="true"/>
<response name="success" type="view" value="setAdditionalParty"/>
</request-map>
<request-map uri="addAdditionalParty">
<event type="java" invoke="addAdditionalParty"
path="org.ofbiz.order.shoppingcart.ShoppingCartEvents"/>
<response name="error" type="view" value="setAdditionalParty"/>
</request-map>
<request-map uri="removeAdditionalParty">
<event type="java" invoke="removeAdditionalParty"
path="org.ofbiz.order.shoppingcart.ShoppingCartEvents"/>
<response name="error" type="view" value="setAdditionalParty"/>
</request-map>
<view-map name="setAdditionalParty" type="jpublish"

page="/entry/setAdditionalParty.ftl"/>
2. Si la requête correspond à l’ajout ou à la suppression d’un acteur, le ControlServlet

appelle nos évènements de gestion des acteurs et de leur rôle.
3. Nos évènements modifient en conséquence le ShoppingCart, objet contenant l’ensemble
des saisies de l’utilisateur durant la session.
4. Lorsque le ControlServlet reçoit une des requêtes définies précédemment, il lance le
moteur de rendu JPublish pour créer notre page.
5. JPublish cherche d’abord la définition de la page à créer dans le fichier ordermgr/WEB-
INF/pagedefs/entry/setAdditionalParty.xml. Ce fichier définit les scripts BeanShell à ap-
peler avant de générer la page.
<?xml version="1.0" encoding="UTF-8"?>

<page>
<template>main</template>
<property name="title">Order Entry</property>
<property name="headerItem">orderentry</property>
<property name="leftbar">/includes/entry_left.ftl</property>
<property name="rightbar">/includes/entry_right.ftl</property>
<content-action name="/entry/setAdditionalParty.bsh"/>
<content-action name="/entry/additionalPartyListing.bsh"/>
</page>
6. Le script setAdditionalParty.bsh est exécuté.
40
import org.ofbiz.entity.*;
import org.ofbiz.base.util.*;
delegator = request.getAttribute("delegator");
if (request.getParameterValues("additionalRoleTypeId") == null) {
partyType = request.getParameter("additionalPartyType");
context.put("additionalPartyType", partyType);
additionalPartyId = request.getParameter("additionalPartyId");
context.put("additionalPartyId", additionalPartyId);
roles = delegator.findByAnd("PartyRole", UtilMisc.toMap("partyId", additionalPartyId));

roleData = new LinkedList();
it = roles.iterator();
while (it.hasNext()) {
role = it.next();
roleData.add(role.getRelatedOne("RoleType"));
}
context.put("roles", roleData);
}
7. Ce script interroge la base de données pour récupérer les rôles d’un acteur actuellement
sélectionné et les places dans le contexte de la servlet.
8. Ensuite le script additionalPartyListing.bsh est exécuté.
9. Ce script interroge le ShoppingCart pour récupérer les acteurs et leurs rôles déjà saisis et
les place dans le contexte de la servlet.
10. Après l’exécution de ces scripts, JPublish commence la génération de page en commen-
çant par le template indiqué dans la définition de la page.
11. JPublish passe ensuite la main à FreeMarker pour générer le contenu de la page
12. Le formulaire de saisie d’un acteur et de ses rôles est généré automatiquement à partir de
sa définition dans le fichier XML ordermgr/entry/PartySettingsForm.xml
<forms>
<form name="quickAddOptionalParty" default-title-style="tableheadtext"
default-tooltip-style="tabletext" default-widget-style="inputBox"
target="addOptionalParty" title="" type="single">
<field name="optionalPartyId" title="partyId">
<lookup target-form-name="LookupPerson"/>
</field>
<field name="optionalRoleTypeId" title="roleTypeId">
<drop-down allow-empty="false">
<entity-options description="${description}"
entity-name="RoleType"
key-field-name="roleTypeId"/>
</drop-down>
</field>
<field name="submitButton" title="Add" widget-style="smallSubmit">
<submit button-type="button"/>
</field>
</form>
</forms>
13. Le listing des acteurs et des rôles déjà saisis est généré par FreeMarker.
41
14. Enfin JPublish renvoie la page générée au ControlServlet qui la renvoie lui-même au
navigateur internet de l’utilisateur.
3. Modification des évènements et du ShoppingCart

À ce stade, on dispose d’une interface graphique mais il reste encore à réaliser les traitements
pour la rendre fonctionnelle.
1. Il faut modifier le ShoppingCart pour qu’il conserve la liste des acteurs et de leur rôle
durant la saisie de l’ordre.
2. Il est nécessaire d’implémenter les évènements addAdditionalParty et removeAdditional-
Party pour qu’ils modifient le ShoppingCart lorsque l’utilisateur ajoute ou supprime un
rôle et/ou un acteur.
3. Enfin, il faut qu’au moment de la création de l’ordre, les informations saisies soient
enregistrées dans les tables adéquates de la base de données. Le service qui réalise cette
action se nomme « StoreOrder » et est défini dans le fichier
order/src/org/ofbiz/order/order/OrderServices.java.
4. Il faut indiquer au Service Engine que ce service prend un attribut supplémentaire option-
nel en entrée appelé « OrderAdditionnalPartyRoleMap » :
<service name="storeOrder" engine="java" validate="true" auth="true"

location="org.ofbiz.order.order.OrderServices" invoke="createOrder">
<description>Creates order entities</description>
<attribute name="partyId" type="String" mode="IN" optional="false"/>
<attribute name="visitId" type="String" mode="IN" optional="true"/>
<attribute name="affiliateId" type="String" mode="IN" optional="true"/>
<attribute name="productStoreId" type="String" mode="IN" optional="true"/>
<attribute name="webSiteId" type="String" mode="IN" optional="true"/>
<attribute name="distributorId" type="String" mode="IN" optional="true"/>
<attribute name="orderTypeId" type="String" mode="INOUT" optional="false"/>
<attribute name="orderItems" type="java.util.List" mode="IN" optional="false"/>
<attribute name="orderAdjustments" type="java.util.List" mode="IN" optional="false"/>
<attribute name="billingAccountId" type="String" mode="IN" optional="true"/>
<attribute name="shippingAmount" type="Double" mode="IN" optional="true"/>
<attribute name="firstAttemptOrderId" type="String" mode="IN" optional="true"/>
<attribute name="currencyUom" type="String" mode="IN" optional="false"/>
<attribute name="grandTotal" type="Double" mode="IN" optional="true"/>
<attribute name="taxAmount" type="Double" mode="IN" optional="true"/>
<attribute name="orderShipmentPreferences" type="java.util.List" mode="IN" optional="true"/>
<attribute name="orderPaymentPreferences" type="java.util.List" mode="IN" optional="true"/>
<attribute name="orderContactMechs" type="java.util.List" mode="IN" optional="true"/>
<attribute name="orderItemContactMechs" type="java.util.List" mode="IN" optional="true"/>
<attribute name="orderItemPriceInfos" type="java.util.List" mode="IN" optional="true"/>
<attribute name="orderProductPromoUses" type="java.util.List" mode="IN" optional="true"/>
<attribute name="orderItemSurveyResponses" type="java.util.List" mode="IN" optional="true"/>
<attribute name="trackingCodeOrders" type="java.util.List" mode="IN" optional="true"/>
+ <attribute name="orderAdditionalPartyRoleMap" type="java.util.Map" mode="IN" optional="true"/>
<attribute name="orderId" type="String" mode="OUT" optional="false"/>
<attribute name="statusId" type="String" mode="OUT" optional="false"/>
</service>
42
4.1.6 Étude de la modification d’un ordre après sa création

4.1.6.1 Problématique
Actuellement, une fois qu’un ordre est créé, il n’y a aucun moyen de le modifier par la suite
hormis l’annuler. Ainsi, si la personne qui saisit l’ordre commet une erreur, elle est obligée
de l’annuler et de recommencer toute la procédure de saisie. Imaginez un ordre comprenant
plus d’une centaine articles et être obligé de le retaper juste à cause d’une erreur de frappe. Ce
comportement est inacceptable dans un commerce de type B2B car c’est une perte de temps.
C’est pourquoi Néréide m’a demandé d’étudier la faisabilité de changer le composant order
pour qu’il autorise la modification d’un ordre après sa création. L’objectif principal étant d’être
capable de répondre aux futurs clients de Néréide s’ils demandent si cette fonctionnalité peut
être implémentée facilement ou non.
Il y a tellement de problématiques liées à la modificatoin d’ordre que cela m’aurait pris plusieurs
mois pour les résoudre. Néréide m’a donc demandé de me limiter aux plus simples car je n’avais
que trois semaines pour faire cette étude. Voici quelques exemples de modifications d’ordre
difficiles à résoudre :
– Comment gérer les promotions déjà appliquées lorsque la quantité et/ou le prix d’un
article est modifié.
– Comment traiter les paiements déjà effectués lorsque les prix sont modifiés.
– Comment traiter les promotions et les prix basés sur des dates.
4.1.6.2 Étude et mise en oeuvre
Après avoir identifier et classer selon leur niveau de difficulté les différentes probléma-
tiques concernant la modification d’ordre, j’ai retenu la modification des attributs d’orderItem
suivants :
– quantité commandée ;
– prix unitaire ;
– commentaire ;
– date de livraison désirée.
Ces attributs sont ceux qui présentent le moins de contraintes de gestion par rapport aux dif-
férents statuts d’un ordre. Ensuite, la mise en oeuvre de ces modifications s’est faite à travers
l’interface d’administration des ordres qui a été modifiée pour permettre l’édition des différents
attributs cités précédemment (cf. Fig. 4.17).
43
F IG . 4.17 – Implémentation de la modification d’ordre dans l’interface d’administration
4.1.6.3 Conclusion
Après avoir longuement étudié la modification d’un ordre après sa création, il apparaît que la
conception actuelle du composant order n’est pas du tout adaptée à ce problème. En effet, la
modification d’ordre nécessite de recoder une grande partie des méthodes du ShoppingCart pour
obtenir les mêmes règles de gestion que dans l’interface de saisie.
Le problème provient de l’utilisation de plusieurs objets java à la place d’entités pour modéliser
le ShoppingCart. Or une fois qu’un ordre est créé, il n’est plus possible d’utiliser les méthodes
du ShoppingCart. On est alors obligé de dupliquer les traitements en développant des services
similaires à ces méthodes.
J’ai été confronté à un bug concernant le calcul de l’estimation des frais de livraison qui était
différent entre l’interface de saisie d’un ordre et son interface d’administration. Dans le premier
cas, le calcul était effectué dans une méthode du ShoppingCart alors que dans le second, il était
effectué par un service spécialisé. Or, un bug dans ce dernier donnait un calcul différent. Cet
exemple montre à quel point la duplication de code est difficile à maintenir synchronisée et est
source d’erreurs.
C’est pourquoi je pense qu’il y a deux solutions à ce problème :
1. Conservation du ShoppingCart actuel : On simule la saisie d’un nouvel ordre à partir des
données de l’ordre à modifier, l’utilisateur modifie les informations souhaitées et il recrée
44
l’ordre modifié. L’ordre initial est annulé. Cette solution est la plus propre au niveau des
règles de gestion mais elle n’évite pas la duplication de code et n’est pas idéale du point
de vue utilisateur.
2. Remplacement du ShoppingCart par des entités en base de données : Cette solution né-
cessite de repenser complètement le processus de saisie mais pourra éviter un maximum
de duplication de code grâce à l’utilisation de services pour le traitement des règles de
gestion. Cependant, l’utilisation d’entités aurait peut-être des conséquences sur la montée
en charge du serveur dans le cadre d’applications de eCommerce.
45
4.2. RÉORGANISATION DE NÉOGIA
4.2 Réorganisation de Néogia

Lors de mon arrivée dans l’entreprise, le projet Néogia n’avait que deux mois d’existance
et sortait juste de sa phase de conception. Étant un projet innovant et utilisant des outils à
la pointe de la technologie, trouver l’organisation et les processus de développement les plus
adaptés au projet dès le départ n’était pas chose facile. C’est donc avec la stabilisation des
outils de génération et l’utilisation progressive du projet par l’équipe de Néréide, qu’est apparu
le besoin de simplifier et de rationnaliser l’organisation de Néogia. Cette réorganisation était
aussi motivée par la future publication du projet auprès de la communauté Ofbiz.
J’ai donc été chargé de mener à bien cette réorganisation en tenant compte des objectifs suivants :
1. simplifier la mise en oeuvre du projet pour le rendre plus accessible ;
2. centraliser la production des documents du projet ;
3. améliorer la productivité des développeurs ;
4. faciliter la maintenance du projet.
Sur les conseils d’Olivier Heintz, mon maître de stage, le processus de réorganisation du projet
s’est effectué en plusieurs itérations successives pour assurer une transition progressive et sans
heurt. Les trois étapes les plus importantes de ce processus ont été les suivantes :
– Mise en place d’une nouvelle organisation des fichiers du projet permettant de remplir les
objectifs 1 et 3.
– Mise en oeuvre de Maven pour la gestion du projet permettant de remplir les objectis 2 et
4.
– Mise en oeuvre d’un système d’automatisation de l’intégration des composants Néogia
dans Ofbiz pour atteindre les objectifs 1, 3 et 4.
46
4.2.1 Mise en place d’une nouvelle organisation de Néogia

Initialement, le projet Néogia se décomposait en plusieurs éléments séparés :
– ofbiz-neogia-generators pour les générateurs de code,
– ofbiz-neogia pour l’environnement de génération des composants,
– neogia pour conserver les composants générés,
– neogia-ofbiz pour la plateforme de test Ofbiz.
Ces éléments ont été créés pour vérifier la faisabilité du projet et pour l’élaboration de son
architecture mais ils ne se prêtent pas à une utilisation régulière du projet aussi bien pour
les développeurs que pour les utilisateurs. Les processus de génération et d’intégration des
composants Néogia dans Ofbiz sont complexes et ne sont pas automatisés.
4.2.1.1 Solution
Pour mettre au point une solution efficace, j’ai approfondi les objectifs initiaux selon les
points de vue des développeurs et des utilisateurs. Cette étude m’a permis d’extraire les diffé-
rents points à améliorer par rapport à l’ancienne organisation de Néogia.
• Du point de vue développeur :
– Regrouper l’ensemble des projets liés à Néogia dans une seule arborescence.
– Gérer automatiquement les dépendances entre ces différents projets.
– Structurer les composants Néogia indépendamment des uns des autres.
– Normaliser et simplifier le processus de génération de composants Néogia.
– Faciliter le processus d’intégration de ces composants dans Ofbiz.
– Simplifier la gestion du projet sous Maven.
– Utiliser les fonctionnalités de génération de rapports de Maven.
• Du point de vue utilisateur :
– Présenter une plate-forme facile et rapide à mettre en oeuvre.
– Automatisation des processus.
4.2.1.2 Mise en oeuvre et résultats

• Regroupement des générateurs et des composants Néogia dans un répertoire neogia sous
la forme de sous-projets.
• Suppression de tous les fichiers et dossiers non strictements nécessaires, notamment :
– Suppression de tous les fichiers liés à Topia mais non utilisés par Néogia.
– Réorganisation de tous les scripts Maven.
– Rationalisation de l’utilisation de certains fichiers.
• Séparation stricte des composans Néogia en les plaçant chacun dans leur propre dossier.
Permet ainsi de distinguer les auteurs, les versions, les dépendances vis-à-vis d’autres
composants, etc.
• Simplification des scripts Maven pour uniformiser l’utilisation de cet outil sur les diffé-
rents sous-projets.
47
• Gestion intelligente des dépendances entre les sous-projets.

• Génération automatique du composant Ofbiz à partir du composant Néogia.
neogia contient :
generators/ Les générateurs Néogia
doc/ Documentation des générateurs
src/ Code source des générateurs
maven.xml Script Maven
project.xml Définition du projet
projetct.properties Propriétés Maven du projet
components/ Les composants Néogia
ofbiz-component-template/ Fichiers communs à tous composants Ofbiz.
neogia-component-template/ Fichiers communs à tous composants Néogia.
doc/ Documentation du composant
dist/ composant Ofbiz généré
src/ Sources du composant
zuml/ Diagrammes UML du composant
uilabels/ Fichiers de traduction du composant
project.xml Définition du composant
projetct.properties Propriétés Maven du composant
accouting/ *
common/ *
content/ *
facility/ *
manufacturing/ *Composants Néogia basés sur neogia-component-template
order/ *
neogia/ *
party/ *
product/ *
servicemgnt/ *
neogia-component-deps.xml Modèle de composant Néogia pour Maven
ofbiz-patchs/ Patchs d’intégration de Néogia dans Ofbiz.
build.xml Script Ant chargé de l’intégration de Néogia dans Ofbiz.
neogia-build.xml Bibliothèque de cibles Ant bas-niveau pour l’intégration
neogiaproject.xml Modèle de projet Néogia pour Maven
project.xml Définition du projet Néogia
project.properties Propriétés de Maven pour ce projet
LICENSE.txt Licence du projet Néogia
README Informations sur la mise en oeuvre de Néogia
TAB . 4.3 – Nouvelle organisation de Néogia
48
4.2.2 Mise en oeuvre de Maven pour la gestion du projet Neogia

Néogia utilise des composants logiciels que l’on peut qualifier de l’état de l’art en matière
de génération de code. Or ces composants utilisent les dernières avancées technologiques en
matière de développement logiciel. Notamment, LutinGenerators composant sur lequel repose
les générateurs Néogia, qui nécessite l’utilisation de l’outil de gestion de projet Maven.
Chez Néréide, peu de personnes connaissaient Maven avant son utilisation dans Néogia, j’ai
donc été chargé d’étudier sa mise en oeuvre et d’adapter son utilisation pour le projet Néogia.
4.2.2.1 Qu’est-ce que Maven ?
Maven est un logiciel libre de la fondation Apache dédié à la gestion et à la compréhension

de projet Java. Il se base sur le concept de modélisation objet du projet (POM) pour décrire
parfaitement l’ensemble des ressources (développeurs, site web, dépendances) qu’il utilise ainsi
que l’ensemble des éléments (logiciels, bibliothèques, documentations, rapports, ...) qu’il pro-
duit. La modélisation POM introduit aussi une notion d’héritage entre projets : un projet peut
hériter des propriétés d’un autre. Mais Maven va encore plus loin dans la gestion de projet en
proposant la génération automatique de son site web à partir des informations contenues dans
son POM et la génération de divers rapports sur la qualité du projet. Le but de Maven étant
d’obtenir à moyen terme une normalisation des méthodes et des processus de développement
de projets Java.
À la base du projet géré par Maven se trouve un fichier project.xml qui décrit tous ses éléments :
– le projet dont il hérite les propriétés ;
– sa description ;
– le site web du projet ;
– les mailing-lists du projet ;
– la license du projet ;
– ses développeurs ;
– ses contributeurs ;
– les dépots CVS et/ou subversion ;
– les dépendances du projet ;
– le code source ;
– le code source des tests ;
– les rapports et documentations à générer.
Ces informations sont ensuite utilisées dans tous les processus de développement du projet :
compilation, tests, déploiement, documentation, etc. Néanmoins la fonctionnalité la plus inté-
ressante de Maven est sans doute la génération automatique du site web du projet et de ses
rapports de qualité :
– rapport d’activité du projet et de ses développeurs
– rapport sur les modifications du projet
– rapport sur les non-respects des conventions de codage
– documentation du projet
49
– rapport sur la qualité du code source

– rapport sur les résultats des tests
4.2.2.2 Mise en oeuvre
La première étape a consisté à réaliser la modélisation POM des différents sous-projets de

Néogia. Cette modélisation est basée sur la nouvelle organisation de Néogia à savoir le projet
principal et ses sous-projets : générateurs et composants. Ensuite pour simplifier la maintenance,
deux modèles de projet ont été définis :
– NeogiaProjectTemplate, il définit les propriétés par défaut de tous les projets Néogia.
– NeogiaComponentTemplate, il définit les dépendances nécessaires à tous les composants
Néogia.
F IG . 4.18 – Modélisation POM du projet Néogia
Cette modélisation a ensuite servi à rédiger le fichier project.xml des différents sous-projets.
50
F IG . 4.19 – Site web Néogia entièrement généré par Maven
4.2.2.3 Problèmes rencontrés
Maven étant un logiciel relativement récent (la version 1.0 est sortie courant juillet), il y
a encore peu de retour d’expériences et de documentations sur sa mise en oeuvre et il est
donc difficile de saisir son fonctionnement. D’autant plus que Maven n’est pas un un logiciel
monobloc mais un ensemble de plugins ayant chacun leurs paramètres et leurs actions. Par
exemple, je n’ai trouvé aucune information sur les meilleures pratiques à utiliser lorsque tout
ou partie du code doit être généré avant d’être compilé.
Contrairement à d’autres programmes de gestion de projet tels que Make ou Ant, il n’y a que
très peu de code à écrire dans les fichiers Maven car ce dernier se base sur une normalisation des
processus de développement. En contre-partie, il est très difficile de changer le comportement
standard de l’outil. Ainsi, il n’a pas été possible de générer la documentation du code source
depuis le code déjà généré dans le dossier dist de chaque composant Néogia.
Ces problèmes seront résolus lorsque les projets Maven et Néogia auront atteint un plus grand
stade de maturité. Maven intégrera alors un meilleur support pour la génération de code source
et les processus de développement de Néogia se rapprocheront des standards en matière de
développements Java.
51
4.2.3 Mise en oeuvre d’un système d’automatisation de l’intégration de

Néogia dans Ofbiz
Pour simplifier l’intégration de Néogia dans Ofbiz, on utilise une série de patchs à appliquer sur
Ofbiz avant d’y intégrer les composants Néogia. Ces patchs sont tous situés dans le répertoire
ofbiz-patchs de Néogia et dépendent fortement de la version de référence d’Ofbiz.
Généralement, ces patchs correspondent :
– à des corrections de bugs non encore corrigés dans Ofbiz ;
– à des améliorations apportées sur Ofbiz mais non encore intégrées dans la version de
référence d’Ofbiz ;
– à du code permettant d’adapter les interfaces Ofbiz à celles de Néogia et inversement.
L’un des inconvénients majeurs de l’utilisation de patchs est qu’il faut veiller à ce que leur
application fonctionne toujours suite à des mises à jour de la version de référence d’Ofbiz. En
effet, il peut arriver qu’ils ne s’appliquent plus à cause de modifications apportées sur les fichiers
ciblés par le patch. Le cas échéant, il est nécessaire de faire un nouveau patch qui remplace
l’ancien. Ce procédé peut vite devenir long et fastidieux avec l’augmentation du nombre de
patchs à maintenir à jour.
De plus, dans la version initiale du projet, ces patchs devaient être appliqués manuellement
durant le processus d’intégration de Néogia dans Ofbiz. C’est pourquoi le besoin d’un système
de gestion des patchs automatisé s’est rapidement fait ressentir pour améliorer la productivité
des développements de Néogia.
4.2.3.1 Analyse des besoins
Pour mener à bien et dans les meilleures conditions ce développement, j’ai suivi un proces-
sus standard pour trouver les cas d’utilisation et les contraintes du système. La première étape
a donc consisté à identifier les différents types d’intervenant sur le projet, puis à rechercher les
fonctionnalités qu’ils attendent du système.
Rôle Besoin
Utilisateur il veut juste avoir un Ofbiz fonctionnel intégrant les composants
Néogia.
Développeur il développe des composants Néogia et veut les intègrer dans
Ofbiz.
Mainteneur il développe l’intégration de Néogia lors du changement de la
version de référence Ofbiz.
TAB . 4.4 – Rôles identifiés pour le système de gestion des patchs
52
Rôle Scénario
Utilisateur installation automatique d’Ofbiz intégrant les composants
Néogia.
Développeur application des patchs automatiques et installation des compo-
sants Néogia dans Ofbiz.
mise à jour automatique d’ofbizNeogia suite à un changement de
la version de référence d’Ofbiz.
Mainteneur mise à jour automatique des patchs lorsqu’il décide de passer à
une nouvelle version de référence d’Ofbiz.
TAB . 4.5 – Scénarios identifiés pour le système de gestion des patchs
Après avoir identifié les besoins fonctionnels à partir des différents rôles et scénarios associés
au système, il faut prendre en compte maintenant les besoins non fonctionnels suivants :
• tout comme Ofbiz, le système de gestion des patchs doit être multi-plateformes pour que
Néogia puisse être déployé sur les mêmes plateformes supportées par Ofbiz.
• enfin le système doit être simple à mettre en oeuvre pour rendre le projet Néogia acces-
sible à un maximum de personnes.
4.2.3.2 Réalisation
Pour respecter la contrainte d’exécution indépendante de la plateforme, le mécanisme de

gestion des patchs a été codé à l’aide de cibles dans le script Ant du projet. Ant étant écrit en
Java, il peut s’exécuter sur la plupart des JVM. Cependant, la réalisation et l’application d’un
patch nécessitent respectivement les utilitaires diff et patch qui n’ont pas d’équivalent Java à
l’heure actuelle, mais généralement ils sont disponibles sur toutes les plateformes.
Le système offre quatre cibles permettant de réaliser tous les scénarios cités précédemment :
• ant all – Effectue toutes les opérations nécessaires à l’installation complète de Neogia
dans Ofbiz : téléchargement d’Ofbiz, intégration des patchs et installation des composants
Néogia.
• ant – Destinée aux développeurs, la cible par défaut de Ant effectue uniquement l’instal-
lation des composants Néogia dans un Ofbiz préalablement téléchargé. Elle peut tout de
même appliquer les patchs pour Ofbiz si ça n’a pas été déjà fait.
• ant update – Destinée aux développeurs, cette cible leur permet de mettre à jour leur
version d’Ofbiz suite à un changement de la version de référence.
• ant upgrade – Destinée au mainteneur, cette cible télécharge une nouvelle version d’Of-
biz, essaye de mettre à jour tous les patchs et installe les composants dans Ofbiz.
53
4.3. INTÉGRATION DU COMPOSANT FACILITY DE NÉOGIA DANS OFBIZ
4.3 Intégration du composant Facility de Néogia dans Ofbiz

Le projet Néogia introduit un composant fonctionnel nommé Facility qui vient remplacer le
module de gestion des stocks d’Ofbiz. Or Néogia utilisant une modélisation objet, le modèle de
données de la gestion des stocks a été entièrement revu. Par conséquent, les composants d’Ofbiz
qui accèdaient directement aux entités de l’ancien module doivent être adaptés pour utiliser les
interfaces du composant Facility de Néogia.
Actuellement, seul les composants Order et Shipment utilisent la gestion des stocks :
– Order, pour connaître les quantités disponibles en stock et pour effectuer des réservations
de stocks lorsqu’un produit est commandé.
– Shipment, pour effectuer les mouvements de stocks nécessaires lorsqu’un produit s’ap-
prête à quitter l’entreprise.
Ce développement étant toujours en cours au moment de la rédaction de ce document, on se

limitera à la description de la méthodologie employé pour réaliser au mieux l’intégration entre
ces composants.
4.3.1 Mode opératoire

4.3.1.1 Étude des dépendances inter-modules
Pour chaque composant à modifier, il faut étudier ses dépendances avec l’ancien module de
gestion des stocks. Cette étape doit être menée avec rigueur sans quoi l’analyse des interfaces
à réaliser sera faussée et l’intégration sera inefficace. Le but de cette étape est de rechercher
tous les endroits dans le composant où ce dernier fait appel à des services et/ou méthodes et/ou
entités de l’ancienne gestion des stocks.
Généralement, il faut rechercher ces dépendances dans les fichiers sources java, dans les scripts
minilang, dans les fichiers d’interface FreeMarker et dans les scripts beanshell. Les dépendances
peuvent aussi se trouver au niveau des entités et des ECAs.
4.3.1.2 Solutions possibles
Une fois que l’analyse des dépendances a été effectuée, il faut passer aux solutions d’inté-
gration possibles. Cependant il n’a pas de solutions pré-définies, le type d’intégration se fait au
cas par cas.
Dans le cas du composant Order, les dépendances n’étaient que de type service. J’ai donc écrit
un ensemble de services de compatibilité qui se substituaient aux services de l’ancienne gestion
des stocks et qui redirigeaient leur appel vers les services adéquats de Facility (Ce travail a été
réalisé en collaboration avec Pierre Gaudin, un stagiaire de Code-Lutin).
54
Chapitre 5
Bilan du stage
5.1 Bilan professionnel

L’un des attraits du stage était de pouvoir travailler sur des logiciels libres à la pointe de
la technologie. Le développement d’applications d’entreprise dans un environnement J2EE a
atteint un très haut niveau de standardisation et des logiciels comme Maven pousse le concept
jusqu’à la normalisation des processus de développements logiciels.
Par ailleurs, ce stage m’a conforté dans l’idée que les processus de développement itératifs sont
plus performants que les traditionnels cycles en V. Ce type de développement n’exclut pas la
rigueur et le sérieux que nécessite la conception d’un projet mais il a l’avantage de coller au
mieux aux besoins de ce dernier tout au long de son développement. Ce jugement se base sur
l’évolution du projet Neogia qui n’aurait pas atteint un stade de maturité aussi rapidement avec
un cycle en V car certains besoins ne sont apparus qu’après quelques itérations.
Outre l’aspect purement technique, le stage m’a aussi considérablement apporté sur le côté
fonctionnel, notamment dans la modélisation des systèmes d’information d’entreprise. J’ai ainsi
pu découvrir certains domaines de l’informatique de gestion et les règles qui s’y appliquent.
5.2 Bilan personnel

Choisir d’effectuer un stage dans une SSLL était pour moi l’occasion de développer et de
travailler entièrement avec des logiciels libres, expérience que je souhaitais mener depuis un
certain temps. Mais cela m’a aussi permis de m’investir dans des projets libres et de découvrir
le travail communautaire. Ce dernier point a été véritablement enrichissant grâce aux divers
collaborations effectuées avec Jacopo Cappelato et Pierre Gaudin.
55
Bibliographie
• The Data Model Resource Book – Revised Edition – volume 1

A Library of Universal Data Models for All Entreprise
Len Silverston, Ed. Wiley 2001
• Apache Ant 1.6.2 Manual

http://ant.apache.org/manual/index.html
• Maven User Guide

http://maven.apache.org/reference/user-guide.html
56
Annexe A
Plaquette de la société
57
Développements sur l’ERP libre Ofbiz
Résumé
Entre juin et septembre 2004, j’ai effectué un stage comme analyste programmeur à Néréide,
une société de services française spécialisée dans l’intégration de l’ERP Open Source Ofbiz.
Dans un premier temps, j’ai apporté de nombreuses améliorations au module de gestion des
ordres d’achat et de vente d’Ofbiz, et sur la gestion de l’internationalisation du logiciel. Puis
dans un second temps, j’ai travaillé sur l’intégration d’un projet de la société – Néogia – dans
Ofbiz. Particulièrement sur la migration de la gestion des stocks d’Ofbiz vers celle de Neogia.
Mots-clés
Ofbiz, ERP, Neogia, Gestion des ordres
Abstract
Between june and september 2004, I carried out a training as analyst programmer at Nereide,
a french service company specialized in integration of Ofbiz ERP free software. In a first time,
I have braught many enhancements to Ofbiz sale / purchase order management module and on
software localization management. In a second time, I have worked on integration of company
project Neogia into Ofbiz. Particularly on migration to Ofbiz facility to Neogia’s one.
Keywords
Ofbiz, ERP, Neogia, Order Management
Étudiant : Reponsable de Stage :

Peter G ORON Olivier H EINTZ
EPU-DI 2e année Néréide
Année 2004 3 bis les Isles
37270 Veretz

RapportNereide PGoron

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

RapportNereide PGoron

Transféré par

Droits d'auteur :

Formats disponibles

Université François R ABELAIS Tours

École Polytechnique Universitaire - Département Informatique

Reponsable de Stage : Étudiant :

4 Mes réalisations au sein de Néréide 25

2.1 Organisation d’Ofbiz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.1 Composants fonctionnels de Néogia . . . . . . . . . . . . . . . . . . . . . . . 23

4.1 Organisation du composant Order . . . . . . . . . . . . . . . . . . . . . . . . 28

2.1 Architecture n-tiers d’Ofbiz . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.1 Architecture de Neogia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.1 Point d’entrée dans l’application web « Order Management Application » . . . 27

4.15 Modélisation existante des acteurs et des rôles dans order . . . . . . . . . . . . 38

« La collaboration et les bonnes pratiques en action. »

Durant ma période de stage, 2 stagiaires étaient présents :

1.2 Le réseau Libre-Entreprise

1.3 Le réseau Libre Partage

1.4 Le maître de stage

2.1 Son architecture

2.1.1 Architecture générale

F IG . 2.1 – Architecture n-tiers d’Ofbiz

F IG . 2.2 – Architecture J2EE d’Ofbiz

2.1.2 Architecture d’Ofbiz

TAB . 2.1 – Organisation d’Ofbiz

2.1.3 Notion de composant

F IG . 2.3 – Architecture en couches d’Ofbiz

2.2 Présentation du framework Ofbiz

Composant État Description

TAB . 2.2 – Composants du framework Ofbiz

2.2.1 Présentation de l’Entity Engine

F IG . 2.4 – Schéma fonctionnel de Entity Engine

création, d’enregistrement, de suppression, de recherche, de mise en cache des données.

F IG . 2.5 – Exemple de définition d’entité

2.2.2 Présentation du Service Engine

F IG . 2.6 – Schéma fonctionnel du Service Engine

F IG . 2.7 – Exemple de définition de service

2.2.3 Présentation du ControlServlet

TAB . 2.3 – Moteurs de rendu du ControlServlet

F IG . 2.8 – Boucle d’évènements dans Ofbiz

1. L’utilisateur clique sur un lien hypertexte ou valide un formulaire. Le navigateur envoie

2.3 Présentation des applications Ofbiz

2.3.9 Work Effort

2.3.10 Human Ressources

F IG . 3.1 – Architecture de Neogia

3.2 Les générateurs

Voici quelques générateurs fournis par Néogia :

3.2.1 Processus de génération d’un composant Néogia

3.3 Les composants

3.3.1 Composants fonctionnels

3.3.2 Composants techniques

TAB . 3.2 – Composants techniques de Neogia

3.3.3 Processus d’intégration des composants Néogia dans Ofbiz :

Mes réalisations au sein de Néréide

4.1 Amélioration du composant Order

4.1.2 Cahier des charges

Besoins non fonctionnels :

4.1.3 Présentation détaillée du composant Order

F IG . 4.1 – Point d’entrée dans l’application web « Order Management Application »

4.1.3.1 Organisation du composant

TAB . 4.1 – Organisation du composant Order

4.1.3.2 Processus de saisie d’un ordre

Saisie du type d’ordre (vente

F IG . 4.2 – Saisie d’un ordre – étape 1

Saisie des produits à inclure