Rapport de stage Développements sur l ERP libre Ofbiz

Transcription

1 Université François RABELAIS Tours École Polytechnique Universitaire - Département Informatique 64, avenue Jean PORTALIS Tours Rapport de stage Développements sur l ERP libre Ofbiz Reponsable de Stage : Étudiant : Olivier HEINTZ Peter GORON Néréide EPU-DI 2 e année 3 bis les Isles Année Veretz

2 Table des matières Remerciements 1 Introduction 2 1 Présentation de l entreprise Néréide Le réseau Libre-Entreprise Le réseau Libre Partage Le maître de stage Présentation d Ofbiz Son architecture Architecture générale Architecture d Ofbiz Notion de composant Présentation du framework Ofbiz Présentation de l Entity Engine Présentation du Service Engine Présentation du ControlServlet Présentation des applications Ofbiz Party Product Facility Order Shipment i

3 TABLE DES MATIÈRES Content Accounting Marketing Work Effort Human Ressources Présentation de Néogia Architecture Les générateurs Processus de génération d un composant Néogia Les composants Composants fonctionnels Composants techniques Processus d intégration des composants Néogia dans Ofbiz : Mes réalisations au sein de Néréide Amélioration du composant Order Pourquoi? Cahier des charges Présentation détaillée du composant Order Organisation du composant Processus de saisie d un ordre Cycle de vie d un ordre Amélioration de l interface de saisie des articles Objectifs Plan de développement Solution Ajout d une étape de saisie des acteurs Problématique Solution Étude de la modification d un ordre après sa création Problématique Étude et mise en oeuvre ii

4 TABLE DES MATIÈRES Conclusion Réorganisation de Néogia Mise en place d une nouvelle organisation de Néogia Solution Mise en oeuvre et résultats Mise en oeuvre de Maven pour la gestion du projet Neogia Qu est-ce que Maven? Mise en oeuvre Problèmes rencontrés Mise en oeuvre d un système d automatisation de l intégration de Néogia dans Ofbiz Analyse des besoins Réalisation Intégration du composant Facility de Néogia dans Ofbiz Mode opératoire Étude des dépendances inter-modules Solutions possibles Bilan du stage Bilan professionnel Bilan personnel Bibliographie 56 A Plaquette de la société 57 iii

5 Liste des tableaux 2.1 Organisation d Ofbiz Composants du framework Ofbiz Moteurs de rendu du ControlServlet Composants fonctionnels de Néogia Composants techniques de Neogia Organisation du composant Order Les différents états d un ordre Nouvelle organisation de Néogia Rôles identifiés pour le système de gestion des patchs Scénarios identifiés pour le système de gestion des patchs iv

6 Table des figures 2.1 Architecture n-tiers d Ofbiz Architecture J2EE d Ofbiz Architecture en couches d Ofbiz Schéma fonctionnel de Entity Engine Exemple de définition d entité Schéma fonctionnel du Service Engine Exemple de définition de service Boucle d évènements dans Ofbiz Architecture de Neogia Point d entrée dans l application web «Order Management Application» Saisie d un ordre étape Saisie d un ordre étape Saisie d un ordre étape Saisie d un ordre étape Saisie d un ordre étape Saisie d un ordre étape Modèle de données simplifié du composant Order Diagramme de séquence simplifié du processus de saisie d un ordre Cycle de vie d un ordre Cycle de vie d un OrderItem Modification de l interface de saisie des articles Modèle de données simplifié d un OrderItem Interface de saisie des acteurs réalisée v

7 TABLE DES FIGURES 4.15 Modélisation existante des acteurs et des rôles dans order Boucle d évènements de la page de saisie des acteurs Implémentation de la modification d ordre dans l interface d administration Modélisation POM du projet Néogia Site web Néogia entièrement généré par Maven vi

8 vii

9 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

10 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 2 e 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

11 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

12 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 complé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 étendue 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

13 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 expertise, 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élioration du composant order d Ofbiz. 5

14 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 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 assurent 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 modification, 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

15 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 nombreux concepts de gestion. C est pourquoi, la première partie de mon stage a consisté à comprendre 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

16 2.1. SON ARCHITECTURE 2.1 Son architecture Architecture générale Ofbiz est une application java client-serveur compatible avec la spécification J2EE définissant 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. FIG. 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 nombreux 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

17 2.1. SON ARCHITECTURE FIG. 2.2 Architecture J2EE d Ofbiz 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 logiciels, 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émarrage du serveur (vide par défaut). logs les fichiers d activité du serveur. TAB. 2.1 Organisation d Ofbiz 9

18 2.1. SON ARCHITECTURE 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. FIG. 2.3 Architecture en couches d Ofbiz 10

19 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 organisé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 exploitation, des interfaces graphiques, des outils de communication. (exemple : Eclipse) 2. Framework d intégration Middleware : pour fédérer des applications hétérogè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, maintenance, évolution). Ils permettent de formaliser une architecture adaptée aux besoinx 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 composant 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 systè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

20 2.2. PRÉSENTATION DU FRAMEWORK OFBIZ 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é «EECA 1» même si le SGBD sous-jacent n implémente pas cette fonctionnalité. FIG. 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 données s effectue par son interface unifiée. Cette interface permet d effectuer des opérations de 1 Entity Event-Condition-Action 12

21 2.2. PRÉSENTATION DU FRAMEWORK OFBIZ 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> FIG. 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

22 2.2. PRÉSENTATION DU FRAMEWORK OFBIZ Présentation du Service Engine Le Service Engine est l équivalent de l Entity Engine pour tous les traitements des composants 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. FIG. 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

23 2.2. PRÉSENTATION DU FRAMEWORK OFBIZ diaire d une transaction ainsi en cas d échec du service, la cohérence des bases de données est conservée. <!-- Tax Services --> <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> FIG. 2.7 Exemple de définition de service 15

24 2.2. PRÉSENTATION DU FRAMEWORK OFBIZ Présentation du ControlServlet Le ControlServlet est l élément clé de la communication entre les utilisateurs et les applications 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 JSP JPublish + FreeMarker FOP + FreeMarker JasperReport Description Les Java Server Pages permettent de générer des pages HTML dynamiquement. JPublish permet de construire une page HTML à partir de plusieurs 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 est un processeur XSL qui transforme un document XML traité avec FreeMarker en un document HTML ou PDF. 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

25 2.2. PRÉSENTATION DU FRAMEWORK OFBIZ FIG. 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 : 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

26 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 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 numéros de téléphones, des rôles, et par un mécanisme d extension, des données supplémentaires 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

27 2.3. PRÉSENTATION DES APPLICATIONS OFBIZ 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 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 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 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

28 2.3. PRÉSENTATION DES APPLICATIONS OFBIZ 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 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 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 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 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

29 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 composants Ofbiz générés à partir de diagrammes UML. Le temps gagné par la technique de génération 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 XMI 1 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

30 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 diagrammes 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é. FIG. 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

31 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 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érateurs 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éveloppé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 Composants fonctionnels Composant Manufacturing Facility Accounting ServiceMgnt Rôle 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. 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. Remplacera le composant Accounting d Ofbiz et supportera la comptabilité analytique. 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

32 3.3. LES COMPOSANTS 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 Common Order Party Product Rôle permet de stocker les énumérations et les statuts utilisés dans Neogia dans les entités correspondantes d Ofbiz. permet d accéder aux entités OrderHeader et OrderItem d Ofbiz. permet d accéder aux entités du composant Party d Ofbiz. 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 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

33 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 diffé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

34 4.1. AMÉLIORATION DU COMPOSANT ORDER 4.1 Amélioration du composant Order 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 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 : modifier 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

35 4.1. AMÉLIORATION DU COMPOSANT ORDER 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 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 notifications 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. FIG. 4.1 Point d entrée dans l application web «Order Management Application» 27

36 4.1. AMÉLIORATION DU COMPOSANT ORDER 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 / les scripts de notification par 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

37 4.1. AMÉLIORATION DU COMPOSANT ORDER 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. FIG. 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. FIG. 4.3 Saisie d un ordre étape 2 29

38 4.1. AMÉLIORATION DU COMPOSANT ORDER Saisie de l adresse de livraison. FIG. 4.4 Saisie d un ordre étape 3 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. FIG. 4.5 Saisie d un ordre étape 4 30

39 4.1. AMÉLIORATION DU COMPOSANT ORDER Saisie de la méthode de paiement. FIG. 4.6 Saisie d un ordre étape 5 Confirmation de l ordre. FIG. 4.7 Saisie d un ordre étape 6 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

40 4.1. AMÉLIORATION DU COMPOSANT ORDER FIG. 4.8 Modèle de données simplifié du composant Order FIG. 4.9 Diagramme de séquence simplifié du processus de saisie d un ordre 32

41 4.1. AMÉLIORATION DU COMPOSANT ORDER 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 Rejected Processing Canceled Approved Send Completed l ordre vient d être créé et est en attente de paiement l entreprise a refusé le traitement de l ordre l ordre est en attente de paiement et en cours de traitement par l entreprise l ordre a été annulé par le client le paiement a été reçu et les produits sont en cours de préparation la commande a été expédiée le client a reçu la livraison TAB. 4.2 Les différents états d un ordre FIG Cycle de vie d un ordre FIG Cycle de vie d un OrderItem 33

42 4.1. AMÉLIORATION DU COMPOSANT ORDER Amélioration de l interface de saisie des articles 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. FIG Modification de l interface de saisie des articles 34

43 4.1. AMÉLIORATION DU COMPOSANT ORDER 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ération 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 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 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. FIG Modèle de données simplifié d un OrderItem 35

44 4.1. AMÉLIORATION DU COMPOSANT ORDER 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 appelé 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 nouvelles 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

45 4.1. AMÉLIORATION DU COMPOSANT ORDER Ajout d une étape de saisie des acteurs 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 (CRM 1 ). 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

46 4.1. AMÉLIORATION DU COMPOSANT ORDER FIG Interface de saisie des acteurs réalisée 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. FIG 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

47 4.1. AMÉLIORATION DU COMPOSANT ORDER 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 modifié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 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). FIG 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

48 4.1. AMÉLIORATION DU COMPOSANT ORDER <request-map uri="setadditionalparty"> <security https="true" auth="true"/> <response name="success" type="view" value="setadditionalparty"/> </request-map> <request-map uri="addadditionalparty"> <security https="true" auth="true"/> <event type="java" invoke="addadditionalparty" path="org.ofbiz.order.shoppingcart.shoppingcartevents"/> <response name="success" type="view" value="setadditionalparty"/> <response name="error" type="view" value="setadditionalparty"/> </request-map> <request-map uri="removeadditionalparty"> <security https="true" auth="true"/> <event type="java" invoke="removeadditionalparty" path="org.ofbiz.order.shoppingcart.shoppingcartevents"/> <response name="success" type="view" value="setadditionalparty"/> <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 à appeler 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

49 4.1. AMÉLIORATION DU COMPOSANT ORDER 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

50 4.1. AMÉLIORATION DU COMPOSANT ORDER 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 optionnel 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

51 4.1. AMÉLIORATION DU COMPOSANT ORDER Étude de la modification d un ordre après sa création 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 Étude et mise en oeuvre Après avoir identifier et classer selon leur niveau de difficulté les différentes problématiques 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 diffé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

52 4.1. AMÉLIORATION DU COMPOSANT ORDER FIG Implémentation de la modification d ordre dans l interface d administration 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

53 4.1. AMÉLIORATION DU COMPOSANT ORDER 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

54 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

55 4.2. RÉORGANISATION DE NÉOGIA 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 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 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

56 4.2. RÉORGANISATION DE NÉOGIA 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 maven.xml Script Maven 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 maven.xml Script 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

57 4.2. RÉORGANISATION DE NÉOGIA 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 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 produit. 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

58 4.2. RÉORGANISATION DE NÉOGIA rapport sur la qualité du code source rapport sur les résultats des tests 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. FIG 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

59 4.2. RÉORGANISATION DE NÉOGIA FIG Site web Néogia entièrement généré par Maven 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