Rapport de Stage : Développement sur l'erp libre OFBiz Néogia

Faculté des Sciences Département d'informatique 1, Rue de Chartres 45067 Orléans cedex 2. Rapport de Stage : Développement sur l'erp libre OFBiz Néogia Responsable de Stage : Étudiant : Peter GORON Mickaël HARDOUIN Master 2 IRAD 3 bis, les Isles 37270 Véretz Année 2006

Remerciements Mes remerciements vont à toute l'équipe de Néreide, en commençant par Olivier Heintz pour sa disponibilité, ses explications, en particulier sur le plan fonctionnel, et sa patience à me les transmettre. Nicolas Malin, pour la générosité de son accueil à son domicile lors de ma semaine de formation; Peter Goron pour m'avoir encadré tout au long de mon stage et pour tous ses conseils techniques avisés; Sophie Benaroch pour la relecture de mes documentations fonctionnelles dans le but de les rendre plus claires. Je souhaite également remercier Jean Luc Malet et Pierre Gaudin, pour m'avoir également transmis des explications sur le plan fonctionnel ainsi que la bonne humeur qu'ils apportent à l'ambiance déjà très chaleureuse de l'équipe. Je n'oublie pas ma collègue stagiaire; Cécile Bourreau pour l'aide qu'elle m'a apportée notamment sur le module «Order». Pour mettre un trait d'honneur à ces remerciements, je voudrais remercier toute la famille Heintz, pour sa gentillesse et l'accueil qu'ils ont pu m'accorder au sein de leur domicile tout au long de ce stage; notamment durant les pauses déjeuners.

Table des matières Remerciements...3 Introduction...6 Présentation de l'entreprise...7 1. La société Néreide...7 2. Le réseau Libre Entreprise...8 Présentation de l'erp OfbizNéogia...9 1. Généralités sur les ERP...9 1.1 Définition...9 1.2 Avantages...9 1.3 Inconvénients...10 1.4 Les ERP libres...10 2. Le projet Ofbiz...11 2.1 Architecture d'ofbiz...12 2.2 Le framework...13 2.2.1 L'EntityEngine...13 2.2.2 Le Service Engine...14 2.2.3 Le Control Servlet...14 2.3 Les différents modules...16 2.3.1 Content...16 2.3.2 Accounting...16 2.3.3 Party...16 2.3.4 Product...16 2.3.5 Facility...17 3. Le projet Néogia...18 Contexte de travail...19 1. Outils utilisés...19 2. Méthode de travail...20 Développement Réalisés...21 1. Gestion des erreurs...21 1.1 Présentation et Objectifs...21 1.2 Analyse...22 1.3 Résultat...24 2. Liste de transferts...26 1.1 Présentation et Objectifs...26 1.2 Analyse...27 1.3 Résultat...29 Conclusion...32 Résumé...33 Abstract...33 Bibliographie...34

Index des illustrations Illustration 1: Logo entreprise Néreide...7 Illustration 2: Logo du réseau Libre Entreprise...8 Illustration 3: Logo ERP Ofbiz...11 Illustration 4: Architecture ERP Ofbiz...12 Illustration 5: Boucle d'évènement...15 Illustration 6: Logo Projet Néogia...18 Illustration 7: Exemple de déclenchement d'erreur...21 Illustration 8: Résultat du diagramme UML après modification...23 Illustration 9: Écran listant les erreurs enregistrer en base...24 Illustration 10: Écran d'édition des permission ( lecture / écriture ) sur les erreurs...25 Illustration 11: Écran d'ajout de transfert à une liste de transfert...26 Illustration 12: Relation de l'entité TransfertList avant la création de l'entité TransfertListModel...27 Illustration 13: Relation après la création de TransfertListModel...28 Illustration 14: Création du modèle de la liste de transfert...29 Illustration 15: Écran d'ajout de transfert à un modèle de liste de transfert...29 Illustration 16: Création de la liste de transfert...30 Illustration 17: Liste des transfert planifiés ne faisant pas partie d'une liste...30

Introduction On ne présente plus les logiciels libres, aujourd'hui reconnus pour leurs qualités 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. Par 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. 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. Néréide est une de ces nouvelles SSLL (Société de Services en Logiciels Libres). Elle propose à ses clients un PGI basé sur le logiciel libre Open For Business (Ofbiz) pour lequel elle peut développer des besoins spécifiques pour chacun d'entre eux. Voulant élargir mes connaissances dans le domaine fonctionnel et par la même occasion découvrir le monde du travail dans les SSLL, mon choix s'est naturellement orienté vers cette jeune entreprise qui m'a accueilli du début du mois d'avril jusqu'à fin septembre sous la responsabilité de Peter Goron. La première partie de mon travail a consisté en l'étude du fonctionnement de l'erp OfbizNéogia. Pour m'aider dans cette tâche, j'ai effectué une semaine de formation avec 3 autres stagiaires. Cette formation m'a permis de connaître les bases du fonctionnement de l'application, notamment les interconnexions entre les différents modules que compose l'erp. Contrairement à certains de mes collègues qui se sont spécialisés sur un module, mes développements ont été divers et variés. J'ai commencé par travailler sur un module technique puis continuer sur des modules fonctionnels.

Présentation de l'entreprise 1. La société Néreide Illustration 1: Logo entreprise Néreide 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 OfbizNéogia. 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' OfbizNéogia, elle propose à ses clients toute une gamme de services centrés autour de l'erp : développements spécifiques, administration système, infogérance, 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). L'équipe de Néreide se compose de : Olivier Heintz, Directeur de projet; Jean Luc Malet, Directeur de projet; Yannick Thebault, Architecte. Pierre Gaudin, Développeur; Sophie Benaroch, Chargée d'affaires; Catherine Heintz, Responsable communication administration Peter Goron, Développeur; ( mon maître de stage ) Également présent en tant que stagiaire durant ma période de stage : Cécile Bourreau, Master de l'université de Poitiers DESSTAUP Cédric Vallée, 2ème année à Polytech Tours, département informatique; Simon Baudry, 2ème année à Polytech Tours, département informatique;

2. Le réseau Libre Entreprise Illustration 2: Logo du 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. 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.

Présentation de l'erp OfbizNéogia 1. Généralités sur les ERP 1.1 Définition Un PGI progiciel de gestion intégré (en anglais Enterprise Resource Planning ou ERP) est un: «logiciel qui permet de gérer l'ensemble des processus d'une entreprise en intégrant l'ensemble des fonctions de cette dernière comme la gestion des ressources humaines, la gestion comptable et financière, l'aide à la décision, mais aussi la vente, la distribution, l'approvisionnement, le commerce électronique»(définition du grand dictionnaire terminologique de l'office québécois de la langue française (OLF)) Le principe fondateur d'un ERP est de construire une application (paie, comptabilité, gestion de stocks ) de manière modulaire tout en partageant une base de données unifiée. Ainsi, les Achats, la Comptabilité, la Gestion des Stocks, les Ressources Humaines, la Gestion Commerciale, etc sont maintenant totalement interconnectés. Avec l'arrivée de l'erp, les données sont désormais standardisées et partagées entre les différents modules, ce qui élimine les saisies multiples et évite l'ambiguïté des données multiples de même nature. Ceci permet un accroissement considérable de la fiabilité des informations puisque la source des données est unique, d'où une réduction des délais et des coûts de traitements. L'autre principe qui caractérise un ERP est l'usage systématique de ce qu'on appelle un moteur de workflow, et qui permet, lorsqu'une donnée est entrée dans le système d'information, de la propager dans tous les modules du système qui en ont besoin, selon une programmation prédéfinie. Ainsi, on peut parler d'erp lorsqu'on est en présence d'un système d'information composé de plusieurs applications partageant une seule et même base de données, par le biais d'un système automatisé prédéfini éventuellement paramétrable (un moteur de workflow). 1.2 Avantages Comparés à des applications sur mesure, les ERP / PGI présentent plusieurs avantages : optimisation des processus de gestion (flux économiques et financiers) cohérence et homogénéité des informations intégrité et unicité du système d'information partage du même système d information facilitant la communication interne et externe minimisation des coûts: pas d interface entre les modules, synchronisation des traitements, maintenance corrective simplifiée car assurée directement par l'éditeur et non plus par le service informatique de l'entreprise globalisation de la formation (même logique, même ergonomie) maîtrise des coûts et des délais de mise en œuvre et de déploiement Il est important de remarquer que la mise en place d'un ERP dans une entreprise est souvent le déclencheur d'une réorganisation et rationalisation de l'ensemble des tâches et processus de l'entreprise.

1.3 Inconvénients Les ERP / PGI ne sont cependant pas exempts d'inconvénients : coût élevé périmètre fonctionnel souvent plus large que les besoins de l'organisation ou de l'entreprise lourdeur et rigidité de mise en œuvre difficultés d'appropriation par le personnel de l'entreprise nécessité d'une bonne connaissance des processus de l'entreprise nécessité d'adapter parfois certains processus de l'organisation ou de l'entreprise au progiciel ; nécessité d'une maintenance continue. 1.4 Les ERP libres Le secteur des ERP a subi depuis quelques années un petit bouleversement : l'arrivée de logiciels libres (OFBiz Tiny ERP, ERP5, Compiere,...) sur des terres où règnent en maîtres les logiciels propriétaires : SAP, BAAN, Oracle,... Le premier avantage des ERP Libre sur leurs alter ego propriétaires est bien sûr l'absence de coût de licence ; coût qui peut souvent apparaître comme prohibitif pour les PME. Un autre atout important est la possibilité d'adapter et de faire évoluer soi même le progiciel sans dépendre du bon vouloir de la société éditrice. En outre, le logiciel libre mobilise souvent des communautés, qui le font évoluer au gré des nouveaux besoins, et qui peuvent répondre rapidement à des demandes précises. De plus comme tout logiciel libre, les ERP libre donne la garantie de travailler sur des standards ouverts et donc inter opérables, avantages stratégiques pour beaucoup d'entreprises. En parallèle avec l'augmentation de l'utilisation des ERP en France :48 % des PME françaises sont équipées, et en janvier 2005, 9 % des PME françaises envisageaient d'acquérir et de mettre en place un nouvel ERP dans l'année (Atelier groupe BNP Paribas), l'intérêt porté par les entreprises sur le logiciel libre progresse. Ainsi, 58 % des entreprises envisageraient de passer de leur ERP propriétaire actuel à un ERP libre en 2004 (ERP2004 INFOWORLD). La présence du logiciel libre sur le marché des ERP n'est donc plus marginal et les ERP Open Source prennent leurs places dans ce secteur.

2. Le projet Ofbiz Illustration 3: Logo ERP Ofbiz Open For Business, ou Ofbiz, est un projet de progiciel de gestion intégré (PGI) 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écessaires à un PGI intégrant les modules de gestion suivants : SCM (Supply Chain Management), ou en français GCL, (Gestion de la Chaîne Logistique) CRM (Customer Relationship Management), ou GRC (Gestion de la Relation Client) MRP (Manufacturing Resource Planning), ou GPP (Gestion et Planification de la Production) CMS (Content Management System), ou SGC (Système de Gestion de Contenu) CMMS (Computerized Maintenance Management System), ou GMAO (Gestion de la Maintenance Assistée par Prdinateur ) Ofbiz se base sur de nombreux logiciels libres tels que Ant, Tomcat, JPublish, FreeMarker, etc. Ces logiciels sont reconnus pour leur qualité et ils assurent l'indépendance du projet. De même, pour garantir un maximum de compatibilité avec les systèmes existants et futurs, Ofbiz respecte de nombreux standards, notamment J2EE et XML. Ce dernier possède une part très importante dans le projet Ofbiz notamment pour décrire les données et les traitements. Un des avantages d'ofbiz réside dans sa parfaite compatibilité avec tous les serveurs d'applications J2EE et toutes les bases de données du marché. 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 mais également la pérennité du projet. 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.

2.1 Architecture d'ofbiz Ofbiz est une application java client serveur compatible avec la spécification J2EE qui définit une architecture logicielle standard. On retrouve ainsi les trois éléments caractéristiques d'une architecture 3 tiers : les clients légers : machines 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. Cependant Ofbiz à la possibilité de faire appel à des applications externes via des services locaux ou distants ( WebServices ). On peut donc considérer Ofbiz comme une architecture n tiers. Illustration 4: Architecture ERP Ofbiz 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.

2.2 Le framework Le fonctionnement du framework d'ofbiz repose sur 3 composants majeurs : l'entityengine, le ServiceEngine, le ControlServlet. 2.2.1 L'EntityEngine L'Entity Engine est un composant Ofbiz qui se charge de la gestion des données de tous les autres composants Ofbiz. L'Entity Engine possède de nombreux points forts : gestion automatique de la persistance de données; 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; Voici un exemple de définition d'une entité : <entity entity name="roletype" package name="org.ofbiz.party.party" default resource name="partyentitylabels" title="role Type Entity"> <field name="roletypeid" type="id ne"></field> <field name="parenttypeid" type="id"></field> <field name="hastable" type="indicator"></field> <field name="description" type="description"></field> <prim key field="roletypeid"/> <relation type="one" fk name="role_type_par" title="parent" rel entity name="roletype"> <key map field name="parenttypeid" rel field name="roletypeid"/> </relation> <! Begin neogia specific : value factory > <value factory class name="org.ofbiz.party.party.developed.roletypeservices" /> <! End neogia specific : value factory > </entity> Chaque entité possède un nom ( entity name ), un emplacement ( package name ), un titre, éventuellement un string définissant le fichier de labels à utiliser (default ressource name), une liste de champs ( field ) et pour la plupart du temps des relations avec une ou plusieurs entités.

2.2.2 Le Service Engine Le Service Engine se charge des traitements des composants Ofbiz. Ces traitements sont appelés Services et peuvent être exécutés localement ou à distance. L'avantage du Service Engine se situe dans la non nécessité de connaître l'emplacement ou l'implémentation des services pour pouvoir les lancer. 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. Chaque service doit comporter les éléments suivants : un nom une implémentation ( ici java ) sa localisation la méthode à invoquer la nécessité ou non d'être authentifié pour pouvoir l'appeler les paramètres d'entrée ( attribut en mode IN ) les paramètres de sortie si existant ( mode OUT ) Lors de l'appel à un service, une vérification automatique des paramètres d'entrée est effectuée pour contrôler que tous les paramètres obligatoires sont bien renseignés, et qu'ils sont du type attendu. 2.2.3 Le Control Servlet 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 interactions 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. Illustration 5: Boucle d'évènement

Voici l'ensemble des opérations effectuées suite à une interaction avec l'utilisateur pour lui afficher une page à l'aide de JPusblish et FreeMarker : 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. 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. 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 Les différents modules 2.3.1 Content Le module Content assure la gestion de contenu (CMS). Ses entités 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 de l organisation des données qui peuvent être utilisés dans beaucoup de structures de données comme des arbres, listes ou des Maps d objets. Une fois ces structures créées, des outils évolués de recherche d information sont utilisés pour automatiser la création de nouvelles structures et permettre à l entreprise de gérer les documents. 2.3.2 Accounting Les entités de Comptabilité sont organisées sur des principes généralement admis comme la comptabilité à double entrée, un registre général avec des comptes hiérarchisés... Elles sont structurées pour que l'on puisse gérer la comptabilité de plusieurs organisations. 2.3.3 Party

Le module Party permet d'assurer la gestion de la relation client (CRM). Un Party peut représenter soit une personne physique soit un groupe (un groupe pouvant être une entreprise, un fournisseur 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 fournisseurs, 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'extensions, des données supplémentaires. 2.3.4 Product Les entités de Product contiennent les informations générales sur les produits vendables, achetables d'une entreprise. Les produits peuvent être des articles (matières premières, produits finis...), des services,... Les produits peuvent être organisés en catégories et en catalogue (notion de promotions, canaux de ventes...). Ils peuvent être associés à une multitude de prix selon la devise, le fournisseur, les dates, la quantité achetée, etc. 2.3.5 Facility Un «Facility» est un bâtiment ou un emplacement physique tel que les stocks, les magasins, les docks, les bureaux,... En général un «Facility» aura un contact associé : une adresse, un numéro de téléphone,... 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. Ce module permet de gérer les stocks d'une entreprise, il connaît ainsi pour un produit ses lieux de stockages, les quantités stockées et les indices de gestion de stock : seuils d'alerte, quantité économique...

3. Le projet Néogia Illustration 6: Logo Projet Néogia L'objectif du projet Néogia est d'être une sur couche objet de l'erp Ofbiz pour appliquer un développement objet et s'affranchir de la structure de la base de données, de disposer de composants fonctionnels basés sur une modélisation UML et à partir de ces modèles UML de générer automatiquement le plus de code possible. 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 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. Cette génération de code est extrêmement utile car il permet de gagner un temps précieux en développement; en effet on estime à environ 70 % de fichier généré. Les fichiers générés sont les : fichiers de définition des services ; fichiers de définition des entités ; fichiers Java permettant l'abstraction Objet< >Entité ; fichiers d interfaces graphiques par défaut pour les objets modélisés ; fichiers de formulaires de recherche ; fichiers d'internationalisation.

Contexte de travail 1. Outils utilisés OfbizNéogia étant un vaste projet en logiciel libre utilisant plusieurs technologies, les outils utilisés sont nombreux et variés et ceux ci se veulent libres également. On retrouve les programmes suivants : Eclipse WTP Ant Apache ireport ( générateur de fichier Pdf ) OpenJms ( implémentation open source de Sun Microsystems's Java Message Service ) BeanShell ( éditeur de fichier bsh ) FreeMarker ( éditeur de fichier ftl ) Firefox ( avec le plugins Selenium ide, Xpath checker et Web developer ) Poséidon Eclipse n'est plus à présenter, il s'agit d'un formidable outil de développement qui intègre notamment CVS. En revanche, on connaît moins Eclipse WTP ( Work Tool Project ) qui est une extension d'eclipse contenant des éditeurs intégrés pour HTML, Javascript, CSS, JSP, SQL, XML, DTD, XSD et WSDL. Eclipse a été utilisé conjointement avec Ant ( utilitaire de compilation pour Java ). Étant donné qu'un utilisateur de OfbizNéogia n'a besoin que d'un navigateur internet pour tester le logiciel, Firefox a été d'une grande utilité pour pouvoir effectuer des tests. Il permet de disposer de plusieurs plugins indispensable pour des développeurs web: Web developper afin d'afficher toutes les caractéristiques d'un formulaire ( son nom, la(les) requêtes à effectuer lors des actions sur le(s) boutons, les champs avec leur valeurs et leur clef y compris les champs cachés). Tout ceci a permis d'accélérer les phases de debuggage; Xpath checker quant à lui, il nous donne les identifiants des places des composants des différents formulaires; utilisé conjointement avec Sélénium ide pour enregistrer des scénarios de déroulement. Par exemple des scénarios de commande d'achat, ou des ordres de fabrication. Seul Poséidon n'est pas un logiciel libre et fait pâle figure dans cette liste. Il n'a malheureusement pas pu, pour le moment, être remplacé. Il est utilisé pour la modélisation UML de toutes les entités de l'erp. Combiné à LutinGenerators il permet de générer 70% du code du projet.

2. Méthode de travail Afin que la communauté participant au développement du projet OfbizNéogia puisse suivre l'évolution de chacun, que les mainteneurs puissent intégrer le travail des différentes contributeurs; plusieurs outils sont indispensables : CVS, SourceForge qui héberge OfbizNéogia pour sa gestion des trackers, ainsi que les mailing list qui permettent de suivre toutes les modifications par mail (mail présentant les différences entre deux versions d'un même fichier). Afin de préserver la stabilité du projet, on utilise la notion de «Branche». Le projet OfbizNéogia se trouve sur la branche principale appelée Head. C'est sur celle ci que se grefferons les développements. Lors du début d'un nouveau développement, chaque développeur crée une nouvelle branche, créée à partir d'un identifiant de tracker obtenu sur le site SourceForge; cette identifiant va permettre de retrouver le but du développement, la personne affectée à ce développement, son statut et d'autres informations. Cette nouvelle branche va alors être indépendante du projet principale et ne perturbera pas ce dernier. Une fois toutes les modifications apportées à cette branche, et les test Selenium validés, le développeur change alors le statut du tracker en TBT, cela signifie que ces nouvelles modifications devront être testées par un des mainteneurs du projet pour être validées et intégrées au projet global. Une fois validées, une documentation fonctionnelle et / ou technique est écrite sur le Wiki du projet améliorant la compréhension des utilisateurs finaux ou obtenir des informations techniques pour de futures modifications ou utilisations et ainsi assurer un meilleur suivi. Afin de participer au développement du projet OfbizNéogia on peut distinguer 3 types de développements : les évolutifs ( ajout de nouvelles fonctionnalités), les correctifs ( résolution de bugs ), les spécifiques ( réponse au besoins des clients ). J ai eu à réaliser de nombreuses tâches sur l ERP, il n est pas possible de toutes les présenter dans la limite des pages qui m'est imparti. J ai donc choisi d expliquer les deux principales. Un développement évolutif : La gestion des erreurs, un spécifique : les modèles de liste de transferts ( qui passa dans le projet principal étant donné l'atout majeur qu'apporta ce développement ).

Développement Réalisés 1. Gestion des erreurs 1.1 Présentation et Objectifs Dans tout logiciel qui se respecte, il existe une gestion des erreurs. Dans OfbizNéogia cette gestion d'erreur est existante. Chaque erreur possède un statut qui est plus ou moins à tenir en compte; certaines ne sont qu'à titre d'information et d'autre sont incontournables. Ces dernières déclenchent alors des rollback ( annulation de modification ) dans les bases. On peut distinguer deux types d'erreurs : les erreurs fonctionnelles ( le plus souvent déclenchées par des erreurs humaines, par exemple une valeur manquante dans un formulaire) et les erreurs techniques ( Null pointer exception, GenericEntitityException ). Ces dernières sont dues à des erreurs de programmations ou à un manque de sécurité. Si une telle erreur se produit c'est qu'une correction d'un code est à revoir, ce ne seront donc pas normalement des erreurs récurrentes. En revanche les erreurs fonctionnelles sont bien plus nombreuses, «l'erreur est humaine» et c'est ce type d'erreur qui devra être visible directement par l'utilisateur. Celles ci sont visibles par l'utilisateur grâce des messages d'alerte qui s'affichent en rouge. Illustration 7: Exemple de déclenchement d'erreur Malgré la visibilité de ces erreurs, il peut arriver que l'utilisateur n'en tienne rigueur ou qu'il ne s'en rende compte. Pour cette raison, l'idée d'enregistrer ces alertes et erreurs en bases est apparue. De cette manière, l'administrateur peut accéder à l'ensemble des erreurs qui a été engendrées. Ce

mécanisme était présent lors du commencement de mon travail, néanmoins il n'était pas utilisé car il n'existait aucun écran fonctionnel permettant d'y accéder. Mon travail fut donc d'en créer un générique dans un premier temps, de façon à ce qu'il puisse être utilisé à n'importe quel endroit de l'application. Dans un second temps, il m'a été demandé d'améliorer la sécurité de cet écran afin de limiter l'accès seulement à des utilisateurs ayant certaines permissions. 1.2 Analyse Cette tache fut la première que j'ai eu à développer pour le compte de l'erp OfbizNéogia, ce fut donc une réelle confrontation avec le fonctionnement complet. En effet, dès ma première approche j'ai dû analyser deux composants bien distincts : Party et Common. Cependant, malgré de grosse différences, un grand nombre d'éléments du composant party dépend du composant Common. Par exemple la notion des décorateurs de Party hérite des décorateurs de Common. J'ai mis un bon moment avant de pouvoir appréhender ces processus, car les aller retours entre les deux composants sont très nombreux et difficile à suivre pour une première approche. Néanmoins grâce à cette difficulté j'ai réussi à mieux percevoir la boucle des évènements de l'utilisation de l'erp par la suite, car pour cette tâche j'ai du réaliser la plupart de ces évènements. Lors du commencement de cette tâche j'ai dû analyser l'existant. Il s'avéra alors que certaines entités était déjà présentes : ApplicationLog ApplicationLogCode ApplicationLogLevel ApplicationLogStatus Ainsi ApplicationLog correspond à l'erreur. Chaque erreur contient un identifiant, un code d'erreur ( relié à ApplicationLogCode), un niveau d'erreur ( relié à ApplicationLogLevel ), un statut de lecture ( relié à ApplicationLogStatus ). Une fois avoir étudié les fichiers java correspondants à ces différentes entités, j'ai donc commencé par créer l'écran générique permettant de visualiser ces erreurs; ce qui constituait la première partie de cette tâche. Dans un second temps, j'ai eu à créer un procédé permettant de limiter l'affichage de ces erreurs. Auparavant, tout utilisateur avait la possibilité de visionner toutes les erreurs générées. Il est désormais obligatoire de posséder certains droits, il a donc fallu modifier le diagramme UML de façon à avoir une relation entre les acteurs ( en l'occurence la personne connectée ) et les erreurs générées. De cette nouvelle contrainte est apparues de nouvelles entités nécessaires à l'application de cette modification: ApplicationLogPerm ( Type de droit : lecture et modification ) PartyAppLogPerm ( Class d'association entre Party ( les acteurs ), ApplicationLogCode, ApplicationLogPerm ) Grâce à cette modification, pour pouvoir voir les erreurs ayant pour code X, il faut avoir une entrée dans la table PartyAppLogPerm correspondant à l'identifiant de l'utilisateur, le code X et le droit le lecture ; sans une telle entrée, aucune erreur ayant pour code X ne sera visible. Ce procédé représenta une réelle avancé pour la gestion des erreurs. Pourtant, il ne fût pas suffisant. Il est vrai qu'un très grand nombre d'erreurs peut être généré ce qui aurait pour conséquence d'agrandir au fur et à mesure la taille de l'écran à afficher. Pour cette raison, la modification suivante fût de n'afficher que les erreurs non lues. A ce stade, la gestion des erreurs au niveau technique était complète, mais au niveau fonctionnel il manquait encore un détail. Les erreurs ne sont que la

conséquence de procédés ayant mal fonctionnés, or c'est justement ce que l'on souhaite éviter à l'avenir. Malheureusement à ce moment rien ne permettait de savoir quel était le procédé qui était en cause. Il a donc fallu revoir la modélisation pour pouvoir corriger ce problème. C'est ainsi qu'un attribut (runid, un identifiant généré lors de lancement d'un processus ) et plusieurs relations supplémentaires furent introduits pour pouvoir tracer à la source le problème; donnant lieu au nouveau diagramme UML ci dessous : Illustration 8: Résultat du diagramme UML après modification 1.3 Résultat L'écran de visualisation des erreurs étant générique, il n'existe pas de visualisation de celui ci. En revanche un écran implémentant une partie de ces possibilités est accessible et pleinement opérationnel depuis le menu des acteurs, comme on peut le voir sur l'illustration 9. Lors de l'appel à l'écran générique on peut lui passer deux paramètres optionnels ( runid et partyid) qui vont permettre de faire du tri respectivement sur le processus à afficher, et sur les permissions du partyid ( l'acteur ) ; on peut bien sûr combiner les deux.

Illustration 9: Écran listant les erreurs enregistrer en base Malgré les documentations créées pour l'utilisation de cette fonctionnalité, elle n'est utilisée qu'à deux endroits différents d'après ce que j'ai pu constater. Contrairement à l'écran de visualisation de la liste d'erreur, l'écran d'édition des permissions ( illustration 10 ) n'est pas générique, et ne possède pas les mêmes contraintes de sécurité pour son accès. C'est à dire que tous les utilisateurs pourront visionner leur droit. En revanche un autre mécanisme de sécurité déjà présent dans l'erp permet d'activer ou de désactiver la possibilité d'édition de ces permissions. Étant donné que pour faire la capture de l'illustration 10, je m'étais connecté en administrateur il va de soit que l'édition était possible, dans le cas contraire le lien jaune ne sera pas visible, et la requête effectuée par ce lien ne serait pas non plus atteignable.

Illustration 10: Écran d'édition des permissions ( lecture / écriture ) sur les erreurs

2. Liste de transferts 1.1 Présentation et Objectifs Dans une grande société ou dans un groupe possédant des stocks importants de produits et différents lieux de stockage, il est régulier de devoir faire des transferts de produits d'une zone à une autre; et afin de procéder aux transfert et d'améliorer la traçabilité des produits et ainsi éviter qu'il ne se perde dans la nature ; des feuilles de suivis comportant des listes de transferts sont imprimées. Le mécanisme de création de liste de transferts était déjà existant, cependant la création d'une telle liste de transfert pouvait être longue et fastidieuse. En effet pour chaque transfert d'objet, l'utilisateur était obligé de le rajouter manuellement à la liste via cet écran : Illustration 11: Écran d'ajout de transfert à une liste de transfert

Sur cet écran on peut remarquer que pour chaque objet que l'on veut transférer on doit remplir au moins 4 informations: la zone de provenance, la zone de destination, le produit, ainsi que la quantité désirée. Pour de courtes listes de transferts, le temps à créer ces listes est relativement rapide, mais dès que cette liste dépasse une centaine d'objets, ce processus devient très rébarbatif. Or il est régulier que des listes de transfert soient très similaires dans le temps. A partir de cette constatation et afin d'améliorer le temps de création de ces listes; on m'a chargé de créer des modèles de liste de transferts, grâce à ces modèles la création de longue liste de transfert ne se ferait plus qu'en quelques instants (sous condition d'avoir créer le modèle au préalable). 1.2 Analyse Comme pour le procédé de gestion des erreurs, j'ai dû reprendre les modélisations et développement déjà préexistant afin de les analyser. Mais contrairement à la gestion des erreurs qui n'était pas utilisé, la création de liste de transfert était déjà utilisé par plusieurs clients de l'erp. Je ne pouvais donc pas me permettre de modifier les processus déjà livrés, qui auraient entraîné une perte de temps et donc d'argent pour ses sociétés. Illustration 12: Relation de l'entité TransfertList avant la création de l'entité TransfertListModel

Dans le modèle UML on distingue clairement l'emplacement de TransfertList, il s'agit d'une liste contenant des StockItem (les produits à transférer ). J'ai eu à reproduire un mécanisme similaire lors de la création de mes modèles de listes de transfert ( TransfertListModel ). Ces derniers contenants des TransfertUnitModel (identifiant de produit correspondant aux StockItem + quantité ). J'ai également introduit des mécanismes afin de choisir des emplacements sources et destination par défaut au cas ou l'utilisateur aurait oublier de les renseigner. Illustration 13: Relation après la création de TransfertListModel L'avantage de ce processus est indéniable pour la création de liste de transferts répétitives, néanmoins les transferts entre deux entrepôts peuvent être divers et variés, à cause de cela les modèles de liste de transfert n'ont aucune utilité dans certains cas ( liste demandé trop disparâtre par rapport aux modèles existants ). Or de très nombreux StockEventPlanned ( Transferts planifiés ) sont créés seul ( sans appartenir à une liste ). Par conséquent on se retrouve avec des milliers de transferts planifiés directement accessibles via un seul écran, et parmi ces milliers de transferts une bonne partie ont de grande chance d'être répétés. J'ai donc créé un processus qui permettrait de produire des listes à partir de transferts planifiés. Une simple sélection des éléments à reprendre ( seul ceux n'appartenant pas déjà à une liste sont sélectionnables ) et un clic de souris sont désormais suffisant pour créer une liste de transfert, de plus, plus la base de données des transferts planifiés est grande plus l'on trouve tous les transferts que l'on a besoin et moins d'éditions de la liste de transferts sont nécessaires.

1.3 Résultat Le processus d'amélioration à la création de liste de transfert est pleinement opérationnel et à été déployé chez le client demandeur. Pour l'utilisateur le procédé est très simple il lui suffit de renseigner les trois champs ( illustration 14). Le champ description correspond à une phrase qui lui permettra de reconnaître plus facilement le modèle par la suite ( voir illustration 16 ) Illustration 14: Création du modèle de la liste de transfert Une fois le modèle de transfert crée il ne reste plus qu'à l'éditer ( Illustration 15 ) de façon à rajouter tous les transferts que l'on aura besoin. Sur la partie gauche de l'écran on dispose des données que l'on à renseigner lors de l'illustration 14. Illustration 15: Écran d'ajout de transfert à un modèle de liste de transfert Sur la partie droite, un écran nous invite à renseigner les données nécessaires à la création d'un nouveau transfert. Enfin la partie inférieure liste les transferts déjà présents. Une fois que l'on

dispose d'un modèle on peut passer à la création de la liste de transfert (Illustration 16). Illustration 16: Création de la liste de transfert Sur cet écran on dispose de deux possibilités : laisser l'identifiant du modèle de liste de transfert vide, dans ce cas on utilise le processus standard; ou sélectionner un modèle. Ce choix rend les autres champs obligatoires ou non. Nous allons nous concentrer sur la deuxième possibilité. A partir de cet instant seule la date de réalisation est nécessaire; les magasins de destinations et d'origine s'il ne sont pas remplis le seront par ceux par défaut du modèle de liste de transferts. A partir du moment où l'utilisateur cliquera sur «Ajouter» le processus créera la liste de transfert avec tout les transferts contenu dans le modèle. Illustration 17: Liste des transfert planifiés ne faisant pas partie d'une liste Une fois validée cette liste créera automatiquement des transferts planifiés ayant un identifiant de liste indiquée dans la case «Préparation» de l'illustration 17. Pour créer une liste de transferts avec la deuxième nouvelle façon ( à partir des transferts planifiés ), il suffit de sélectionner ceux désirés comme sur l'illustration 17 et de cliquer sur le bouton «Créer». Une nouvelle liste de transferts sera alors produite et nous redirigera alors sur son écran d'édition. Bien que les manipulations utilisateurs se soient considérablement amoindris, il reste encore des lacunes pour la création de liste de transferts. Il n'est pas possible de créer des listes de transferts à partir de transferts planifiés appartenant déjà à des listes; or la plupart du temps les transferts de marchandise ne se font pas à l'unité, le coût de transports étant beaucoup trop grand. Par conséquent on risque de se retrouver dans le cas où aucun transferts planifiés ne sera sélectionnable, on ne pourra donc utiliser que la première solution.

Un des autres points à améliorer est la vitesse de création de liste à partir d'un modèle, en effet lors de mes tests, je ne me suis basé que sur des courtes listes par manque de temps, or il s'avère que de longue liste pose quelque soucis de lenteur.

Conclusion Durant le long de mon cursus universitaire, nous avons étudié de nombreux domaines, mais pour la plupart, seulement sur la partie théorique. Ce stage m'a permis de les voir sous une autre approche, la pratique. En effet j'ai dû utiliser mes connaissances en UML, en J2EE, en base de données, en réseau et même en Théorie des langages, chose à laquelle je ne m'attendais pas du tout! Il est indéniable que sur le plan technique j'ai énormément gagné, je suis désormais plus confiant; mais outre la technique, j'ai surtout appris sur le plan fonctionnel et le relationnel. Un ERP permettant d'améliorer la gestion de toute une entreprise, il va de soit que j'ai eu à comprendre de nombreux domaines tel que la gestion des ressources humaines, la gestion des stocks et de nombreux autres. Malgré ces six mois; je sais qu'il me reste une masse phénoménale d'informations à encore apprendre mais c'est la diversité de ce stage qui l'a rendu aussi attrayant. OfbizNéogia étant un logiciel libre, j'ai également pris conscience de l'importance des documentations. En effet il est primordial d'avoir une documentation aussi exhaustive que possible afin de permettre l'amélioration ou la correction future. J'ai également eu la possibilité d'avoir des contacts directs avec des clients du projet Néogia ce qui m'a également permis d'entrevoir le plan relationnel et me rendre compte de l'importance de la communication entre tous les différents acteurs d'un tel projet.

Résumé Mon stage de 2ème année de Master s est déroulé au sein de l entreprise Néréide, depuis début février 2006 jusqu'à fin septembre 2006, sous la responsabilité de Monsieur Peter Goron. Cette entreprise est une Société de Services en Logiciels Libres spécialisée dans l intégration de l ERP libre Ofbiz. Au cours de ces 6 mois de stage, j ai effectué de nombreuses tâches autour du développement de cet ERP. J ai notamment apporté des nouvelles fonctionnalités au module de gestion des stock ou la gestion des ressources humaines. Ce projet m a permis d enrichir mes connaissances en programmation Java, mais surtout mes connaissances fonctionnels quasiment inexistante auparavant. Mots clés : PGI, Logiciels Libres, JAVA, UML, Développement Abstract My internship took place within the company Néréide, since the beginning of April to the end of September, under the responsibility of Mister Peter Goron. This company only used Open Source software and is specialized in Ofbiz ERP integration. During those 6 months, I carried out a lot of different work around the development of this ERP. In particular I carried out some new fonctionnality in the component in charge of inventory control and human ressources. This project enabled me to enrich my knowledge in Java development, but especially my functional knowledge which was almost inexistant before. Key Words : ERP, Open Source, JAVA, UML, Development

Bibliographie The Neogia Project. http://wiki.neogia.org/ Démonstration du projet Néogia http://demo.neogia.org/ The Open For Business Project. David E. Jones et Andy Zeneski. http://www.ofbiz.org/ Le réseau Libre Entreprise. http://www.libre entreprise.com/