Développement d un composant de «gestion de stocks» pour l ERP libre Ofbiz

Transcription

1 Université François RABELAIS Faculté Des Sciences Et Techniques - DESS Compétence Complémentaire En Informatique Parc de Grandmont TOURS Développement d un composant de «gestion de stocks» pour l ERP libre Ofbiz Au sein de la Société Code Lutin 2, rue Robert le Ricolais, BP Nantes cedex3 Reponsable de Stage : Mai - Septembre 2004 Cédric PINEAU PIERRE GAUDIN Maitre de Stage : DESS CCI Tours promotion 2004 Olivier HEINTZ Société Néréide

2 Remerciements Mes remerciements vont tout d abord à Cédric Pineau et Benjamin Poussin qui m ont permis de réaliser ce stage au sein de leur entreprise, et tout au long duquel leur aide technique et leur disponibilité ont été fortement appréciables Je remercie également Olivier Heintz pour m avoir encadré au cours du stage et plus particulièrement pour son aide toujours pertinente, ses conseils et sa grande disponibilité. Je tiens à remercier Yannick Thebault et Peter Goron qui ont su répondre à mes nombreuses questions. Enfin, je n oublie pas Catherine Heintz pour son accueil chaleureux et son aide tout au long de ce stage. i

3 Table des matières Remerciements i 1 Présentation Générale Problématiques Les ERP Définition d un ERP Les différents acteurs du marché La nouvelle donne des ERP libres Les enjeux de la Génération de code Cadre du stage La société Code Lutin Le réseau Libre Entreprise La société Néréide Objectifs du stage Présentation du logiciel Ofbiz et du projet Neogia l ERP Ofbiz Présentation Générale Architecture L Entity Engine Le Service Engine Le ControlServlet le projet Neogia Présentation Générale Objectifs détaillés ii

4 TABLE DES MATIÈRES Organisation Processus d intégration des composants Néogia dans Ofbiz Développement du composant «gestion des Stocks» Déroulement du stage Outils et bonnes pratiques Eclipse 1 : Un EDI Poseidon 2 : Le logiciel de modélisation Les logiciels de constructions de projets Ant Maven CVS 5 : un logiciel d échange de données Fonctionnement avant mise en place Etat des lieux Analyse des besoins Modification de l organisation des magasins Développement d un outil d inventaire Améliorations fonctionnelles de la plannification des besoins Modélisation UML L entité L attribut L association Génération de code les générateurs Organisation des fichiers générés Rôle des fichiers générés Interface graphique Définition des tables de la base de données Classes java http :// 2 http :// 3 http ://ant.apache.org/ 4 http ://maven.apache.org/ 5 Concurent Versions System, https :// iii

5 TABLE DES MATIÈRES Contrôles et Services Intégration des fichiers générés au composant Programmation du code métier L interface Graphique Les services Les classes Les Scripts BeanShell Les requêtes sur l Entity Engine Architecture des magasins Inventaire Centralisation des événements planifiés Fonctionnement actuel Modification de l organisation des magasins Ajout d une ligne de stock Transfert de Stock Outil d inventaire Améliorations fonctionnelles de la plannification des besoins Plannification d une commande Aménagement en cours et Améliorations Conclusion 49 Bilan du projet Bilan personnel Annexes 51 A Diagrammes UML 51 B Exemple de code 57 B.1 Défintion de table NFacility pour l entity Engine : entitymodel.xml B.2 Définition d un contrôle : controle.xml B.3 Définition d un service : services.xml B.4 Exemple de getteur et de setteur implémenté dans les classes de base : NFacilityBase.java iv

6 TABLE DES MATIÈRES B.5 Exemple de code développé dans une classe : NFacility.java B.6 Exemple de méthode statique d intérogation de la base de données via l Entity Engine : StockEventPlannedQuerry.java B.7 Définition d une page : EditAssocInventory.xml B.8 Définition d une vue utilisant l affichage conditionnel (use-when) : NInventoryItem.xml B.9 Définition des labes utilisés dans l interface graphique : FacilityUiLabels.properties 64 C Vue standard vs vue modifée 65 v

7 Liste des tableaux 1.1 Les principaux ERP Open Source du marché Moteurs de rendu du ControlServlet Tags utilisés pour le paramétrage des entités Tags utilisés pour le paramétrage des attributs sources :JDN 23/07/2004 vi

8 Table des figures 1.1 Organisation d un ERP Répartition des parts de marché en Architecture d Ofbiz Organisation du projet Neogia Organisation d un composant Neogia Exemple d organisation de la hiérarchie des emplacements de stockage Diagramme de classe représentant l architecture du facility Organisation du code généré Liste de tous les magasins Ajout d une ligne de stock depuis un magasin Liste de toutes les lignes de stock Enregistrement d un transfert de stock Liste des transferts de stock plannifiés Liste de toutes les lignes de stock Vue de la liste des Inventaires Vue d édition d un inventaire Ajout d un magasin à un inventaire Vue de la liste des lignes d inventaire suite à l ajout d un magasin Ajout d un produit dans un inventaire Vue de la liste des lignes d inventaire suite à l ajout d un produit à un inventaire Vue d édition d un inventaire : réalisation de l inventaire Ajout d une ligne d inventaire en cours de comptage Vue de la liste des lignes d inventaire après ajout d une ligne d inventaire vii

9 TABLE DES FIGURES 3.19 Vue de la liste des lignes d inventaire en cours de saisie Vue de la ligne d inventaire après validation d une ligne Vue d édition d un inventaire après clôture d un inventaire Vue de la liste des inventaires après clôture Vue d une commande depuis le composant Order d Ofbiz Liste des mouvements plannifiés de stock A.1 Organisation des magasins A.2 Organisation de l inventaire A.3 Plannification des événements sur les stocks A.4 Relation entre les composants Facility et Manufacturing A.5 Relation entre les composants Facility et Order C.1 vue standard C.2 vue modifiée en fonction du status des lignes d inventaire viii

10 ix

11 Chapitre 1 Présentation Générale 1.1 Problématiques Les ERP Définition d un ERP L ERP 1 est un progiciel présentant les principales fonctions nécessaires à la gestion des flux et des procédures de l entreprise (gestion des commandes, stocks, fabrication, comptabilité, contrôle de gestion, logistique, paie et ressources humaines...). Il accède à des ressources communes stockées sur une base de données. 1 Enterprise Resources Planning 1

12 1.1. PROBLÉMATIQUES FIG. 1.1 Organisation d un ERP Il doit permettre d assurer le contrôle global de l entreprise (contrôle de gestion, pilotage de production, suivi des processus). Ainsi il permet d automatiser et d intégrer les processus, de partager les données, de produire et d accéder à l information en temps réel Les différents acteurs du marché Quelques puissants fournisseurs privés dominent le marché des ERP qui reste relativement concentré. Ainsi, les trois plus gros fournisseurs, mentionnés ci-après se partageaient presque 50% des parts de marché en : 2 source IDC 2

13 1.1. PROBLÉMATIQUES FIG. 1.2 Répartition des parts de marché en 2002 Sur le marché des PME, de nouveaux acteurs apparaissent, à commencer par Microsoft. Cet éditeur est reconnu pour ses capacités de commercialisation et de popularisation de solutions informatiques La nouvelle donne des ERP libres Le marché des ERP devient progressivement un marché de "commodité". En effet, la lutte concurrentielle ne porte plus sur le produit qui est banalisé mais sur les services qui répondent aux «besoins métiers» de l entreprise (écoute du client, connaissance du métier du client,...). Il s agit alors d un terrain propice au logiciel type Open Source. L Open Source présente quatre avantages essentiels : la mutualisation des coûts de développement : la concentration de l investissement sur la partie métier du client la pérennité du code même si les concepteurs disparaissent. l absence de dogmatisme en matière de règles de gestion Une étude récente 3 a montré que 53% des personnes sont prêts à étudier l utilisation d un ERP libre en alternative à leur ERP existant. L intérêt des ERP libres devient donc réel, alors que jusqu à présent, les logiciels libres n avaient pas de place dans ce secteur. Depuis 2000 plusieurs projets sont en cours de développement. Il existe actuellement une dizaine de projets aboutis et utilisés en entreprise. 3 ERP 2004 INFOWORLD 3

14 1.1. PROBLÉMATIQUES Nom Origine Licence Environnement Fonctionnalités Aria Nola GPL PHP, MySQL Comptabilité, inventaire, paie. Compiere Jorg J2EE, JBoss Janke Mozilla Public Licence Gestion des ventes, gestion des catalogues, des tarifs, suivi des commandes, gestion des achats, des stocks, de la logistique, gestion comptable et financière ERP5 Nexedi GPL Python, Zope Gestion de production, gestion financière, CRM, chaîne logistique, e-business, groupware Fisterra Igalia GPL GNOME2 development platform, PostgreSQL OFBiz David (Open E. Jones For Business) + Andy Zeneski PGI Suite Value Enterprise Gestion d entrepôts, des stocks, de trésorerie, facturation. MIT XML, J2EE Gestion clients, fournisseurs, employés, gestion des articles, des stocks, des commandes, gestion de projet, e-commerce Taïka GPL Linux, Apache, MySQL, PHP Emryn GPL Delphi/Kylix, Java Gestion financière, des achats, gestion commerciale, des ventes et des stocks. Comptabilité, gestion de production, CRM. TAB. 1.1 Les principaux ERP Open Source du marché Les enjeux de la Génération de code L intérêt d un ERP libre est réel. Toutefois ces applications sont en général très complexes du fait du grand nombre de fonctionnalités développées et du volume de données très important à manipuler de façon sécurisée. Ceci implique un temps de développement très long. Or les problématiques actuelles de conception de logiciels libres sont en totale opposition. En effet, du fait du nombre réduit de développeurs, la conception d un logiciel libre nécessite de : limiter le temps de développement assurer la souplesse de la plateforme notamment lors d un changement de technologie limiter les efforts liés à la maintenance du code. Dans ce contexte, la génération de code qui consiste à automatiser la création du code dit d architecture, est un enjeu important pour les sociétés de services dans le logiciel libre. En effet, cela permet à la société de concentrer ses efforts non sur le codage d architecture qui ne sera pas source de valeur ajoutée mais sur la demande spécifique des clients qui quant à elle, sera génératrice de valeur ajoutée. 4

15 1.1. PROBLÉMATIQUES Toutefois, pour que l utilisation de cette génération de code soit optimale, il est essentiel de respecter quatre principes pouvant s énoncer comme suit : La Qualité : un code généré doit être de qualité identique à celle présentée par un code écrit manuellement. Il doit être correctement structuré, facile à débuguer et distinct du code conçu manuellement. La Cohérence : le code doit utiliser des noms de classe et de méthode qui soient cohérents entre eux. La Productivité : un générateur de code doit être plus productif qu un code rédigé à la main. Cela se mesure surtout lors d une régénération afin de généraliser certaines fonctionnalités. L Abstraction : elle doit permettre l évolution du code généré notamment lors du changement de technologie de la plateforme. 5

16 1.2. CADRE DU STAGE 1.2 Cadre du stage La société Code Lutin Code lutin est une jeune Société de Services Nantaise spécialisée dans l environnement libre (SSLL). Elle a été créée en 2002 par Cédric Pineau et Benjamin Poussin. Son activité est axée sur trois domaines : Le développement de logiciels libres pour le traitement et la publication d information en utilisant notamment Java et XML. Le déploiement et la maintenance de systèmes «clefs en main» basés sur des solutions libres : accès à l Internet sécurisé, services de mail, de partage de fichiers, d impression et de sauvegarde. Le conseil et la veille technologique sur le monde des logiciels libres et sur les technologies java et xml Le réseau Libre Entreprise La société Code Lutin fait partie du réseau «Libre -entreprise». Il s agit d un regroupement de sociétés de services en informatique spécialiste des logiciels libres et du système GNU/Linux. Le réseau rassemble 10 sociétés implantées dans toute la France et à l étranger. L objectif est de regrouper différents acteurs du marché afin d avoir une couverture la plus complète possible de l environnement libre. Par ailleurs il existe un «laboratoire» dénommé labs.libre-entreprise.org qui met à la disposition de la communauté du logiciel libre un ensemble de ressources sous licences libres (outils de développement, bibliothèques sous licence GPL, logiciels complets sous licences GPL, documentations, supports de cours et articles de fond sous licence FDL). Il héberge actuellement 55 projets La société Néréide Néréide est une Société de Service en Logiciel Libre, située à Veretz, près de Tours. Elle a été créée en mars 2004, avec pour activité principale le développement et l intégration de l ERP libre OFBiz. Elle propose également tous les services de post-implémentation d un ERP. La société Néréide fait également partie du réseau libre-entreprise. 6

17 1.3. OBJECTIFS DU STAGE 1.3 Objectifs du stage La société Code Lutin a développé un générateur de code utilisant des diagrammes UML, dénommé LutinGenerators. La société Néréide, quant à elle, souhaite utiliser LutinGenerators dans le cadre de son projet Neogia qui a pour but le développement de nouvelles fonctionnalités du logiciel Ofbiz. Dans ce cadre, la société Code Lutin souhaite participer au projet Neogia en développant un composant qui sera intégré dans ce projet afin de valider le générateur de code et l améliorer. Le but du stage est donc de participer à la mise en place du générateur de code et de tester la génération de code en créant un composant de gestion de stock qui sera intégré au projet Neogia. Il sera également nécessaire de coder l ensemble des règles métiers propres au composant. Pour ce faire, le stage s est déroulé en trois étapes : 1. Modélisation UML du composant de gestion de stock 2. Test du générateur de code, débuggage du code généré et intégration du code généré au composant 3. Codage de la partie métier et intégration dans Ofbiz 7

18 Chapitre 2 Présentation du logiciel Ofbiz et du projet Neogia 2.1 l ERP Ofbiz Présentation Générale Ofbiz est un logiciel de gestion de production communément appelé ERP. Ce projet a été initié en mai 2001 par deux américains David E. Jones et Andy Zeneski. Leur souhait était de créer des outils et une application pour le commerce. Dès le début, les outils et l architecture ont été développés afin d une part, de faciliter le développement de fonctionnalité et d autre part, de réduire le temps de maintenance du code existant. Une des caractéristiques fortes de cet ERP est son appartenance au monde des logiciels libres. En effet, les deux concepteurs ont appliqué une licence «MIT Open Source License» qui implique le libre accès aux sources mais également le droit de les modifier, de les utiliser et même de les vendre. La seule contrainte de cette licence est de respecter le copyright des sources. Aujourd hui, le projet rassemble une quinzaine de développeurs dans le monde. Ofbiz est fortement orienté vers le e-commerce mais son architecture modulaire a permis d intégrer des composants dédiés à l ensemble des fonctions que l on retrouve dans différents types d entreprise (service, industrie, commerce...) Architecture 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 8

19 2.1. L ERP OFBIZ 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 d Ofbiz 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 L Entity Engine L Entity Engine est un composant Ofbiz qui se charge de gérer les transactions avec la base de données. Il est constitué d une collection d API qui implémente des objets java qui vont accéder aux données de la table via des méthodes. Ainsi le développeur n accède pas aux 9

20 2.1. L ERP OFBIZ données directement mais via une couche abstraite qui se charge d accéder aux données et de sécuriser les transactions. Le code est ainsi indépendant du SGBD et le développeur n a pas à connaître le langage SQL. Ses principales caractéristiques sont : accès aux données via une interface unique, le «GenericDelegator». supporte l accès transparent à plusieurs bases 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é Le 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. Ainsi un composant peut appeler un service d un autre composant. Ils sont codés soit en XML Mini-Language qui est un outil d ofbiz soit codé directement en java, ils peuvent alors appeler d autres méthodes java. Les services sont définis par des fichiers xml L utilisation des services permet de garantir une uniformité dans la manipulation des données et d engendrer des contrôles tel que le login ou la gestion des erreurs Le 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 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. 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 : 1 Entity Event-Condition-Action 10

21 2.1. L ERP 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.1 Moteurs de rendu du ControlServlet 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. 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 correspondants. 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. 11

22 2.1. L ERP 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. 12

23 2.2. LE PROJET NEOGIA 2.2 le projet Neogia Présentation Générale Le projet Neogia initié par la société Néréide a pour objectif de compléter ou de modifier les fonctionnalités existantes d Ofbiz en adaptant certains composants et en réécrivant d autres. Ce projet a également pour but de mettre en œuvre un mécanisme de génération de code afin d accroître la productivité de développement et de limiter l effort à fournir pour maintenir le code. A contrario d Ofbiz, ce projet est sous licence GPL Objectifs détaillés Deux types de composant sont modifiés. Le premier est constitué des composants dits «fonctionnels», correspondant à la partie métier de l ERP. Ces composants sont soit nouveaux soit ils remplacent un composant d Ofbiz. Manufacturing : Il remplace le composant OFBiz existant. Il est remodélisé en UML et apporte les fonctions telles que le MRP 2 Facility : Il remplace la partie du composant OFBiz correspondant à la gestion des stocks. En effet la gestion des expéditions est conservée. Il est re-modélisé en UML et apporte de nouvelles fonctionnalités liées à la gestion de stocks (inventaire, plannification de mouvements, hiérachisation des emplacements) Accounting : Il remplace le sous-composant OFBiz existant. Il est re-modélisé en UML et apporte les fonctions de comptabilité analytique. Servicemgnt : C est un nouveau composant. Il est modélisé en UML et apporte de nouvelles fonctionnalités qui gèrent les activités de service ou de projet. Le second type de composant intégré au projet correspond aux «composants techniques». Ces éléments sont nécessaires à l intégration dans Ofbiz des «composants fonctionnels». En effet, ils nécessitent d accéder aux entités de composants Ofbiz. Il faut alors créer la couche objet qui permettra d y accéder. order : utilisé par Facility pour accéder aux objets des entités OrderItem et OrderHeader party : utilisé par tous les composants pour accéder aux objets des entités du composant Party d Ofbiz product : utilisé par tous les composants pour accéder aux objets des entités du composant Product d Ofbiz common : utilisé pour les liaisons avec les entités contenant les énumérations et les statuts content : utilisé pour unifier certaines règles de développement et pour la gestion des champs multi-langues. 2 Manufacturing Resource Planning 13

24 2.2. LE PROJET NEOGIA La modélisation UML de tous les composants Neogia permet de mettre en œuvre la génération de code. Elle est présentée au chapitre Organisation L organisation du projet Neogia a évolué tout au long de son avancement afin de séparer très distinctement les composants, des outils d intégration dans Ofbiz. Les composants sont regroupés dans le dossier «component». On y retrouve les différents types de composant énoncés au chapitre Il existe en plus deux dossiers comportant la structure d un composant neogia à utiliser lors de la création d un nouveau composant «neogia-componet-template» et un dossier comportant les fichiers utiles au fonctionnement du composant dans Ofbiz «ofbiz-common-component-files» Le dossier «doc» contient la documentation du projet. Les fichiers utilisés ont l extension «.rst». Ils sont utilisés pour la création du site Internet du projet via Maven et la commande : «maven site». Le dossier «generators» contient l ensemble des fichiers nécessaires à la construction des bibliothèques (jar) des générateurs et qui seront utilisées lors de la génération des composants. Le dossier «ofbiz-patchs» contient les patchs à appliquer à Ofbiz lors de l intégration des composants Neogia. Le dossier «neogia» contient, à sa racine, un ensemble de fichiers utilisés par les utilitaires Maven et Ant afin de générer l ensemble des composants ou d intégrer les composants dans Ofbiz (cf section 2.2.4) 14

25 2.2. LE PROJET NEOGIA FIG. 2.2 Organisation du projet Neogia Tous les composants du projet possèdent la même organisation. Elle permet de séparer le code généré du code finalisé. Le dossier «dist» contient la version «stable» du composant. Lors de l intégration du composant dans Ofbiz ce sont ces fichiers qui sont utilisés. Dans ce dossier il n y a donc que des fichiers qui ont été testés et qui sont fonctionnels. C est également ce dossier qui est mis à jour sur le serveur CVS. Le dossier «src» contient le fichier «.zuml» créé par Poseidon et qui correspond à la modélistation UML du composant. Ce fichier est utilisé par les générateurs de code (cf section 3.5) Le dossier «target» est créé lors de la génération du code. Il est composé d un dossier «gen» qui contient le code généré qui sera utilisé par le développeur (cf section 3.5) et un dossier «src Build» qui est le dossier de travail des générateurs. 15

26 2.2. LE PROJET NEOGIA Le dossier contient, à sa racine, un ensemble de fichiers utilisés par l utilitaire Maven afin de générer le composant. FIG. 2.3 Organisation d un composant Neogia Processus d intégration des composants Néogia dans Ofbiz Les composants développés dans le cadre du projet doivent être intégrés dans Ofbiz. Or Néogia possède son propre enviromnement. Il est donc nécessaire d intégrer les nouveaux composants dans l architecture d Ofbiz. Pour ce faire, une procédure a été mise au point afin de 16

27 2.2. LE PROJET NEOGIA faciliter cette étape. Elle utilise l utilitaire Ant via la commande : Ant all. Voici un résumé des différentes étapes : 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. 17

28 Chapitre 3 Développement du composant «gestion des Stocks» 3.1 Déroulement du stage Le développement du composant de gestion de stock a constitué quatre étapes dans le déroulement du stage : 1. Mai : appropriation du fonctionnement d ofbiz 2. juin à mi-juin : modélisation UML 3. mi-juin à mi-juillet : test du générateur de code, débuggage du code généré 4. mi-juillet à mi-septembre : codage de la partie métier et intégration du composant dans ofbiz 18

29 3.2. OUTILS ET BONNES PRATIQUES 3.2 Outils et bonnes pratiques Le travail réalisé au cours du stage a nécessité l utilisation de plusiseurs logiciels libres. Le présent chapitre a pour but de présenter ces outils et la méthode de travail utilisée pour la réalisation du projet Neogia. Ces outils peuvent être présentés selon quatre catégories : les EDI 1 : Eclipse les logiciels de modélisation : Poseidon Edition Community les logiciels de construction de projets : Maven, Ant les logiciels d échange de données : CVS, Subversion Eclipse 2 : Un EDI Eclipse a été créée par la société IBM, laquelle a, part la suite, cédée le code à la communauté afin qu elle poursuive son développement. Son but est de fournir une plate-forme modulaire pour permettre des développements informatiques, grâce à une architecture construite de modules nommés «plug-ins». Si les principaux modules fournis en standard avec Eclipse sont orientés vers le langage Java, d autres modules pour les langages comme C++, Cobol, mais aussi pour d autres aspects du développement (base de données, conception avec UML...) sont en cours de développement. Dans le cadre du projet Neogia, Eclipse est utilisé comme EDI afin de développer l ensemble des composants intégrés à cet EDI Poseidon 3 : Le logiciel de modélisation Poseidon est un logiciel de modélisation UML développé en Java par la société Gentleware. Ce produit existe en différentes versions commerciales ou libre. La version libre appelée «Edition Community» peut générer des diagrammes UML respectant les standards UML 1.4. Elle a donc été estimée suffisante pour la réalisation du projet Neogia. La création d un diagramme est simplifiée par l utilisation de l interface visuelle et d une palette de composants qu il suffit de déposer sur l interface graphique. Outre la facilité que présente Poséïdon pour créer des diagrammes UML, l intérêt de ce logiciel est lié au type de fichiers générés. En effet,poséïdon crée des fichiers au format XMI 4, format standard de représentation de modèles UML. Ce format est utilisé par les éditeurs UML 1 Integrated Development Environment 2 http :// 3 http :// 4 XML Metadata Interchange 19

30 3.2. OUTILS ET BONNES PRATIQUES pour réaliser les imports / exports de modèles d un outil vers un autre outil. Poséïdon est utilisé dans le projet Neogia afin de modéliser l architecture du composant et de générer des fichiers de type XMI qui seront interprétés par les générateurs de code Les logiciels de constructions de projets La communauté libre a développé plusieurs outils facilitant la construction d applications java parmi lesquels figurent Ant et Maven Ant 5 Ant est un projet du groupe Apache-Jakarta écrit en java. Son but est d automatiser les opérations répétitives (compilation, exécution de tâches post et pré-compilation... ) et de permetre la construction d applications sans dépendance vis- à-vis de la plateforme. Il trouve toute son utilité pour des projets développés sur différents systèmes d exploitation ou devant fonctionner sur plusieurs systèmes d exploitation. Il est également utilisé pour migrer des projets d un système à un autre. Il repose sur un fichier de configuration XML dénommé «build.xml» qui contient un ensemble de cibles (target). Chaque cible contient une ou plusieurs tâches. De nombreux plug-ins permettent d intégrer Ant aux EDI tel Eclipse. L appel d une cible se fait en ligne de commande : ant [option] [cible] Ant est utilisé dans le projet Ofbiz afin de lancer des tâches telles que la compilation du projet : ant, la suppression du contenu des tables de la base de données : ant clean-data, le chargement de données standard et l initialisation : ant run-install. Il est également utilisé dans le projet Neogia afin de copier ou de supprimer dans Ofbiz un des composants ou l ensemble des composants : ant Maven 6 Maven est développé par le groupe Apache-Jakarta. Cet outil permet également d automatiser la gestion de projets Java. Il offre les fonctionnalités de compilation et de déploiement 5 http ://ant.apache.org/ 6 http ://maven.apache.org/ 20

31 3.2. OUTILS ET BONNES PRATIQUES des applications Java, de gestion des librairies requises par l application, d exécution des tests unitaires et de génération des documentations du projet (site web, pdf, Latex). Ainsi Maven présente des similitudes avec Ant. Toutefois, le fichier de configuration de Maven est plus simple que le fichier de configuration nécessaire à Ant. De plus, il offre des fonctionnalités que Ant ne possède pas et reste plus flexible car il permet aux utilisateurs la création de leurs propres plug-ins à la différence de Ant qui reste relativement statique. Enfin, les scripts Ant ne sont pas réutilisables entre projets, alors que le but de Maven est justement de fournir des fonctionnalités réutilisables. Afin de bien gérer les dépendances, Maven s appuie sur des repositories de librairies (jar). Ces repositories peuvent être contenus dans la machine locale ou accessibles via HTTP. Ainsi, à sa première exécution, Maven télécharge les différents plug-ins dont il a besoin et les installe. Ces mêmes librairies peuvent être réutilisées entre les différents projets. L appel d une cible se fait en ligne de commande : maven [option] [cible] Maven est utilisé dans le projet Neogia afin de construire les librairies (jar) nécessaires à la génération de code puis afin de générer le code CVS 7 : un logiciel d échange de données CVS est un outil de suivi de version. Il permet de conserver une trace de l historique des modifications d un fichier, ou d un ensemble de fichiers, et de revenir simplement à n importe quel état antérieur. Pour garder cet historique, CVS stocke uniquement les différences entre deux versions successives, réalisant ainsi un gain de place. Un autre de ses avantages est de faciliter le travail en groupe. En effet, il permet un stockage centralisé du code source sur un serveur et gère les accès concurrents sur les fichiers de développement. De plus, il offre la possibilité aux développeurs d accéder en même temps à un même fichier afin de le modifier. CVS assure la prise en charge des modifications lorsque celles-ci ne génèrent pas de conflits. En voici quelques lignes de commande : 7 Concurent Versions System, https :// 21

32 3.2. OUTILS ET BONNES PRATIQUES cvs checkout cvs update cvs commit cvs add cvs remove rapatrie l ensemble des fichiers d un module contenu sur le serveur vers l ordinateur local mise à jour des fichiers locaux à partir de versions situées sur le serveur intègre les modifications d un fichier en local sur le serveur avec vérification préalable des conflits et attribution d un numéro de version ajoute un fichier en local. Il est nécessaire de mettre à jour le serveur en utilisant la commande cvs commit supprime le fichier sur le serveur. L historique du fichier est conservé Le projet Neogia est contenu sur un serveur CVS. L ensemble des développeurs utilise CVS pour intégrer leurs modifications effectuées en local et pour récupérer les mises à jour des autres développeurs. Le projet Ofbiz était initialement sous CVS. Au cours de l été, il a migré pour être contenu sur un serveur Subversion. Développé par la même équipe, Subversion correspond à l optimisation de CVS. Il apporte notament une gestion en version des répertoires, la possibilité de renommer un fichier dans le référentiel ou de le déplacer et la gestion atomique des transactions. 22

33 3.3. FONCTIONNEMENT AVANT MISE EN PLACE 3.3 Fonctionnement avant mise en place Etat des lieux L application Ofbiz intègre un module de gestion des stocks dénommés «facility». Ce composant permet de définir l ensemble des emplacements physiques d une société tels que les stocks, les magasins, les docks, les bureaux, les pièces d un bâtiment. Plusieurs éléments peuvent être réunis en groupes de batiments qui, eux-même peuvent faire partie d autres groupes de même type. Pour chaque élément, il est possible d associer des personnes ou groupes de personnes afin de définir par exemple le lieu de travail d employés ou d associer un responsable à un atelier. Enfin, dans le cas de magasins, de stock ou d autre lieu de stockage, chaque élément peut être associé à un ou plusieurs produits. Ainsi les produits du magasin constituent une ligne de stock (inventoryitem). Pour chaque ligne de stock, un ensemble de paramètres est défini tel que les quantités en stock, les quantités disponibles, l emplacement dans le lieu de stockage, le numéro de série, le numéro de lot, la date d expiration, le prix unitaire. En plus d une gestion statique, le composant propose un ensemble de fonctionnalités permettant la gestion dynamique des stocks tel que l inventaire, les mouvements de stock. L inventaire du stock est réalisé par un simple ajustement des quantités réelles pour chaque ligne de stock via une interface graphique. Les mouvements de stock (transfert, commande, réapprovisionnement,... ) sont réalisés sans aucune centralisation. Les notions de quantité en stock et de quantité disponible sont prises en compte dans Ofbiz. Toutefois la quantité de produit disponible est calculée uniquement en fonction de prévisions et sans tenir compte de la date de réalisation de l événement Analyse des besoins L étude de l architecture du composant montre certaines insuffisances et amène à envisager une réécriture totale du composant. Seront présentés ci-après les principaux axes de réorganisation du composant Modification de l organisation des magasins L organisation du composant ne permet pas d avoir une vue arborescente des magasins. Seule la notion de groupe et de sous-groupe existe. Or il est très fréquent qu un lieu de stockage comprenne d autres zones de stockage constituant alors une hiérarchie. Il apparaît donc nécessaire de mettre en place la notion de sous-magasin, chaque sous-magasin ayant une référence au magasin qui le contient. 23

34 3.3. FONCTIONNEMENT AVANT MISE EN PLACE FIG. 3.1 Exemple d organisation de la hiérarchie des emplacements de stockage Cette organisation permet l application en cascade à tous les sous niveaux de modifications. Par exemple, le blocage d un magasin lors d un inventaire ou lors d un contrôle qualité se propagera à tous les sous-niveaux afin d interdire tous mouvements de stock sur l ensemble de ces sous-niveaux Développement d un outil d inventaire L outil d inventaire proposé par Ofbiz est très insuffisant au regard des obligations légales. C est pourquoi il est nécessaire de développer un module spécifique à la création, la réalisation et l enregistrement des inventaires physiques. La création d un inventaire peut se faire selon les produits ou les localisations à inventorier. De même il existe différentes techniques de réalisation d inventaires dont il faut tenir compte. Ces caractéristiques servent lors de la création du listing de l inventaire. Cette réalisation se décompose en trois étapes. La première consiste à éditer les feuilles de saisie en indiquant les produits et les emplacements à compter. Une fois l inventaire en cours de réalisation, chaque ligne de stock inventorié doit être bloquée afin d éviter tout mouvement de produit sur cette ligne. Enfin il est nécessaire d affecter à chaque comptage un groupe de personne. 24

35 3.3. FONCTIONNEMENT AVANT MISE EN PLACE L enregistrement est la dernière partie d un inventaire. Chaque comptage est saisi et comparé automatiquement avec le stock théorique à des fins de contrôle. En cas d écart important, il est possible d effectuer un nouveau comptage. Une fois les quantités saisies, chaque ligne est validée et lorsqu il existe un écart entre le stock théorique et la quantité réelle, un mouvement de stock est engendré et archivé. Lorsque l inventaire est clos tous les emplacements sont débloqués. Cet inventaire et l ensemble des lignes de comptage sont alors archivés Améliorations fonctionnelles de la plannification des besoins Ofbiz ne permet pas de centraliser les mouvements de stocks planifiés, de telle sorte que l état du stock à une date donnée ne peut être déterminé de manière précise. L ensemble des mouvements (transfert, commande, réapprovisionnemt, production...) doit être centralisé afin de pouvoir calculer à tout moment et pour une date donnée les quantités disponibles d un produit. Cela permet d améliorer à la fois la planification des besoins en produit et la planification de la disponibilité des produits. 25

36 3.4. MODÉLISATION UML 3.4 Modélisation UML Après l analyse des besoins, l architecture du composant de gestion de stock a été modélisé à l aide de diagrammes de classe UML. L ensemble des diagrammes créés est contenu dans l annexe A. Voici un exemple représentant l architecture du nfacility. Ce diagramme illustre notamment l organisation hiérarchique des magasins. FIG. 3.2 Diagramme de classe représentant l architecture du facility L entité Dans Ofbiz, la notion d entité correspond aux tables d une base de données. Les entités sont représentées par des classes dont le stéréotype est «entity». Pour chaque entité, il existe une série de «tags» propres au projet Neogia. Ces tags sont interprétés lors de la générération de code et permettent de modifier les fichiers et le code généré. 26

37 3.4. MODÉLISATION UML Tag Valeur Signification shortname "texte" attribue un nom dans Ofbiz en respectant la limite de taille qui est de trente caractères. orderby "nomattribut" permet de faire un tri selon un ou plusieurs champs afin d afficher une liste organisée. cache true permet de préciser si le cache est utilisé lors de l accès aux données d une autre table par un getteur. gui ce tag est utilisé pour la génération de l interface utilisateur. Les valeurs prises par ce tag sont définies par des sous-tags qui prennent la valeur true s ils sont présents. listall la transaction permettant d afficher l ensemble des données d une entity est générée. list la transaction List qui liste le contenu d une table est générée. A la différence de listall, list propose une possibilité de recherche selon les attributs ayant le tag indexed. edit génère la transaction Edit qui permet de modifier un enregistrement d une entité. show génère la transaction Show qui permet depuis une transaction List d afficher les données du champ associé. showlist génère la transaction ShowList qui permet depuis une transaction List d afficher les données du champ associé. lookup génère la transaction Lookup qui permet d afficher dans une po-up les enregistrements de l entité afin de faciliter la saisie de données. drop-down indique que l entité apparaît dans un drop-down pour les associations. Ceci est utilisé notamment pour l affichage des statuts ou des énumérations dd-descriptiononly indique que dans les drop-down, seule la description est affichée defaultvalue affiche pour les énumérations et les statusitem ou toute autre association une valeur par défaut dans le drop-down. Ce tag est utilisé lorsque un tag identique n est pas défini sur l association. TAB. 3.1 Tags utilisés pour le paramétrage des entités L attribut Les attributs correspondent aux champs de la table, chaque entité en possèdant. Le nom des attributs doit respecter la syntaxe java. Leurs types sont ceux utilisables dans java et leur visibilité est «protected». Comme pour les entités, il existe une série de tags propres au projet 27

38 3.4. MODÉLISATION UML Neogia qui sont interprétés par les générateurs afin de modifier le code généré. Tag Valeur Signification readonly spécifie que la valeur de cet attribut ne sera pas modifiable primarykey true/ false indique que cet attribut sera une clé primaire. ofbizentitytype indique un type défini dans Ofbiz. staticvalue définie la valeur d un attribut comme «static» et «final». defaultvalue spécifie pour le type booelan la valeur par défaut (true ou false) dans un drop-down value paramètre la manière dont sera créée la valeur de l attribut. Ce tag utilise des sous-tags nextseqid la valeur de cet attribut est générée automatiquement par Ofbiz l utilisateur ne poura pas générer ou modifier cette valeur. userorseq la valeur de cet attribut est générée par l utilisateur. S il ne le compléte pas, ceci est fait automatiquement. i18n insère une valeur en différents langages. Ceci génère une icône afin d entrer les différentes valeurs selon le langage gui utilisé pour la génération de l interface utilisateur. Ce tag utilise des sous-tags indexed Indique qu un attribut est présent dans la vue de recherche et que l utilisateur poura donc faire une recherche avec cet attribut calculated booleen to say the attribute must be in display in the edit Form. hidden Précise que l attribut ne sera visible sur aucune forme. listlookup Indique que l attribut est présent dans le listlookup. list idname description indique que l attribut est présent dans le list. indique que cet attribut est l ID de l entité. Il est utilisé lors de l affichage des valeurs d une association. «[idname] description» indique que cet attribut est la description de l entité. Il est utilisé lors de l affichage des valeurs d une association. «[idname] description» TAB. 3.2 Tags utilisés pour le paramétrage des attributs L association Les associations représentent les liaisons qui existent entre les différentes tables. Tous les types disponibles dans UML sont utilisables. La cardinalité doit être indiquée à chaque extrémité. 28

39 3.4. MODÉLISATION UML associations relation entre deux entités classe d association lorsque la cardinalité est *, * une classe est créée agrégation montre l appartenance, la destruction du tout se propage a ces parties composition indique que l entitée est «composée de» Remarque La modélisation UML présente deux avantages. D une part, elle donne une vision globale de l architecture du composant et d autre part, le fichier généré dans Poséïdon sera utilisé par les générateurs de code. 29

40 3.5. GÉNÉRATION DE CODE 3.5 Génération de code les générateurs Les générateurs sont utilisés afin de créer toute la couche java de persistance entre les objets issus de la modélisation et les entités gérées par Ofbiz, ainsi que l interface graphique standard et les services associés. La technologie utilisée par les générateurs provient d un logiciel libre appelé Topia, réalisé par la société Code-Lutin. La génération est lancée grâce à l utilitaire Maven. La première étape consiste à transformer les fichiers XMI en fichiers XML appelés «objectmodel». Ces fichiers reprennent la description des classes contenue dans le modèle UML mais avec une DTD propre à Topia. Au cours de la génération, ces fichiers sont parsés afin de créer en mémoire un modèle objet qui servira à accéder aux différents éléments du diagramme. Par ailleurs, la génération nécessite un fichier java dont la méthode principale sera appelée par Topia. Cette méthode comporte le corps du texte à générer entre des balises «/*{» et «}*/». Il comporte également des variables dont la valeur sera déterminée au moment de la génération. Ces variables étant contenues entre les balises «<%» et «%>». Voici quelques générateurs développés pour 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 standards pour les objets modélisés ; générateur des formulaires de recherche ; générateur des fichiers d internationalisation. Cette génération en trois phases à l avantage d être extrêmement souple puisqu elle permet de créer n importe quel type de fichier Organisation des fichiers générés Les fichiers générés sont répartis dans deux types de dossiers : les dossiers «\generated» qui contiennent les fichiers qui seront re-générés automatiquement et qui ne doivent pas être modifiés manuellement. les dossiers «\developped» qui contiennent les fichiers développés par le programmeur. Ils peuvent comporter des fichiers générés dont le nom se termine alors par la lettre «G». Ces fichiers sont renommés et utilisés pour compléter les méthodes des objets de base. 30

41 3.5. GÉNÉRATION DE CODE FIG. 3.3 Organisation du code généré Rôle des fichiers générés Afin de faciliter la compréhension des différents fichiers générés, il est possible de les regrouper selon leur fonction : 31

42 3.5. GÉNÉRATION DE CODE Interface graphique La gestion des écrans standards est définie dans les fichiers freemarker (ftl) (cf chapitre ). Il existe 4 types prédéfinis : «edit», «list», «editassoc» et «show» ; ils sont générés en fonction des tags utilisés dans le modèle UML. edit<entity>.ftl list<entity>.ftl editassoc<entiy>.ftl show<entity>.ftl écran d édition d un enregistrement d une entité écran d affichage sous forme de liste du contenu d une entité écran de visualisation des entités associées à une ligne d enregistrement écran de show Pour chaque entité, l organisation des champs dans un écran standard est définie dans un fichier XML qui comporte l organisation des différents types de vue. form<entity>.xml organisation des champs pour les différentes vues possibles Les valeurs affichées dans les pages sont récupérées par un script beanshell. edit<entity>.bsh find<entity>.bsh editassoc<entity>.bsh script de récupération des données pour l affichage d une interface graphique de type edit script de récupération des données pour l affichage d une interface graphique de type liste suite à une recherche script de récupération des données d entités associées pour l affichage d une interface graphique de type editassoc Définition des tables de la base de données entitymodel.xml entitygroup.xml définition des entités pour l entity engine définition des entités pour l entity engine (exemple de fichier cf annexe B.1) Classes java <entity>base.java <entity>g.java implémentation des objets de base et des méthodes de base (setteur et getteur) permettant d accéder au champ d une table classe héritant d un <entity>baseet implémentant les constructeurs de l objet. C est à partir de ces fichiers qu est développée une partie de la couche métier (exemple de fichier cf annexe B.4) 32

43 3.5. GÉNÉRATION DE CODE Contrôles et Services controlerg.xml servicedefg.xml <entity>service.java définition des contrôles de base qui sont appelés lors du ControlServlet. Les définitions de ce fichier sont recopiées dans le fichier controler.xml définitions des services de base. Les définitions de ce fichier sont recopiées dans le fichier service.xml implémentation des services de base de contrôle de transaction depuis une interface visuelle (exemple de fichier cf annexe B.2 et B.3) Intégration des fichiers générés au composant Une fois les fichiers générés, ils sont intégrés dans le nouveau composant Ofbiz. Remarques Le code généré permet au composant d être quasiment fonctionnel sans besoin pour le développeur d ajouter du code. Le paramétrage de certains fichiers xml permet d activer les fonctions de base du composant. Toutefois cette génération appelle deux remarques : l utilisation des générateurs de code est une technique neuve et leur mise au point est une phase très longue (un mois et demi) pour obtenir la génération d un code exempt de bug. Le code généré a également subi de nombreuses modifications dans le but d optimiser l architecture générale du projet Neogia ce qui a entrainé de nombreuses refontes totales de l organisation du composant. bien que le composant soit opérationnel quant aux fonctions de base, on peut considérer qu il reste encore 30% du code à créer par le développeur. En effet, il faut adapter une partie du code généré mais aussi coder l ensemble des couches métiers. 33

44 3.6. PROGRAMMATION DU CODE MÉTIER 3.6 Programmation du code métier La programmation du code métier consiste à créer des fichiers de toutes pièces ou à modifier certains fichiers générés. Toutes ces modifications sont contenues dans les dossiers «\developped» (voir également le graphique 3.3). Quatre éléments sont essentiellement modifiés L interface Graphique ajout ou suppression de champs. masquage ou affichage de champs en fonction de la valeur de variables (cf annexe B.8 et C ). ajout d un bouton afin d activer un service. modification de l action d un bouton en fonction de la valeur de variables. développement complet de vues non standards Les services modification de la définition de services afin d intégrer des nouvelles variables à un service standard. ajout de nouveaux services java permettant un traitement non standard des données, appelés via une interface graphique modifiée (cf annexe B.3) Les classes ajout de méthodes qui sont appelées par un service. ajout de méthodes de calcul de données ou de traitement particulier (cf annexe B.5) Les Scripts BeanShell création ou modification de scripts afin de récupérer des valeurs de variables non fournies par les scripts générés automatiquement Les requêtes sur l Entity Engine création de méthodes statiques d interrogation de la base de données en utilisant les méthodes fournies par l entity Engine (cf annexe B.6). Voici présentées ci-dessous les principales modifications effectuées pour chaque partie du composant de gestion de stock. 34

45 3.6. PROGRAMMATION DU CODE MÉTIER Architecture des magasins La modélisation UML du composant et la génération de code ont suffi à obtenir une gestion statique des magasins. Toutefois, certaines fonctions liées à leur gestion dynamique ont dû être développées. Ainsi de nouvelles méthodes ont été ajoutées afin de trouver l ensemble des sous-magasins d un magasin et d appliquer à cette sous-hiérarchie une modification. Les services permettant les transferts planifiés de stock ont également été développés. Enfin, certaines interfaces ont été modifiées afin de sécuriser ou de faciliter la saisie des données Inventaire La modélisation UML de l inventaire et la génération de code ont permis de mettre en place les tables de la base de données. Par contre, l ensemble des interfaces graphiques a dû être modifié. En effet, l affichage et les fonctions disponibles doivent êtres modifiées en fonction de l état d avancement de l inventaire. Des nouveaux services ont été développés afin de déclencher, de valider ou de clore un inventaire. Ces services font appel à des méthodes, qui elles aussi, ont été développées Centralisation des événements planifiés La mise en place de la centralisation des événements planifiés n a pas nécessité de modification de l interface graphique. Le principal travail a consisté à créer de nouveaux services afin de faire communiquer le composant de gestion des stocks avec d autres composants. Ainsi, des services ont été développés pour enregistrer une commande dans les événements planifiés et pour obtenir les quantités de produits disponibles à une date donnée. Le même travail a été réalisé avec le composant «manufacturing». Remarques Ces modifications peuvent paraître modestes. Toutefois, il faut garder à l esprit que le code généré au début de l utilisation des générateurs était de qualité très inférieur à celui obtenu actuellement. En effet, de nombreuses modifications qui étaient apportées manuellement aux fichiers ont été intégrées aux générateurs. Ainsi, le travail fourni au début de l utilisation des générateurs n est plus visible. Enfin Ofbiz est un framework relativement complexe et aucun diagramme UML n a été utilisé afin de décrire le fonctionnement des différents composants. Ainsi, l intégration des composants Neogia dans Ofbiz est une étape très complexe qui nécessite un important travail préalable pour déterminer les services d Ofbiz utilisés et accéder au nouveau composant. 35

46 3.7. FONCTIONNEMENT ACTUEL 3.7 Fonctionnement actuel Modification de l organisation des magasins Les magasins ont une organisation hiérarchique. Ils contiennent une référence au magasin parent (cadre rouge) qui peut être précisée à la création de celui-ci ou lors de son édition. La vue ci-dessous liste l ensemble des magasins de l environnement de test. FIG. 3.4 Liste de tous les magasins Ajout d une ligne de stock Depuis chaque magasin, une ligne de stock peut être ajoutée. Pour cela, il faut éditer le magasin, "cliquer" sur le bouton "Stock" puis sur "Add StockItem". Une fois les champs renseignés, l ajout de la ligne de stock se fait en cliquant sur "Ajouter". 36

47 3.7. FONCTIONNEMENT ACTUEL FIG. 3.5 Ajout d une ligne de stock depuis un magasin Une nouvelle ligne apparait alors dans la liste des StockItems. Depuis cette vue, vous pouvez éditer, supprimer une ligne de stock ou créer une nouvelle ligne en cliquant sur "Création". FIG. 3.6 Liste de toutes les lignes de stock 37

48 3.7. FONCTIONNEMENT ACTUEL Transfert de Stock Le transfert de stock se fait depuis la vue d édition d une ligne de stock. Il faut ensuite cliquer sur "Transfert". La vue suivante est alors automatiquement renseignée. Il ne reste plus qu à indiquer la destination, les quantités à transférer ainsi que la date du transfert. Il est également possible d effectuer un transfert directement en cliquant sur l onglet transfert. Dans ce cas, aucun champ n est préalablement renseigné. FIG. 3.7 Enregistrement d un transfert de stock Une fois tous les champs complétés, le service d enregistrement est lancé en cliquant sur "ajouter". Si aucune date n a été saisie ou si cette date est antérieure à la date actuelle, le transfert est effectué instantanément sinon, il est enregistré comme transfert plannifié dans la table des mouvements plannifiés. FIG. 3.8 Liste des transferts de stock plannifiés Depuis cette vue, le transfert peut être "édité", "annulé" ou "effectué". Lorsqu il est effectué, Il est supprimé de la table des mouvements plannifiés et enregistré dans la table des mouvements 38

49 3.7. FONCTIONNEMENT ACTUEL de stock. Par ailleurs, le stock d origine est décrémenté et une nouvelle ligne de stock est créée dans le magasin de destination. FIG. 3.9 Liste de toutes les lignes de stock Outil d inventaire L inventaire se déroule en trois étapes : création réalisation(comptage,saisie,validation) clôture. La création se fait depuis la vue de recherche d un inventaire en cliquant sur "Création". Une fois celui-ci créé, il apparait dans la liste des inventaires. Son statut est alors "Editing". FIG Vue de la liste des Inventaires Pour ajouter des lignes d inventaire, trois choix sont possibles : soit les lignes sont saisies une à une depuis la vue d édition des lignes d inventaire, soit se sont les magasins qui sont 39

50 3.7. FONCTIONNEMENT ACTUEL ajoutés à l inventaire (inventaire par emplacement), ou soit se sont les produits qui sont ajoutés (inventaire par produit). FIG Vue d édition d un inventaire 40

51 3.7. FONCTIONNEMENT ACTUEL Si l inventaire est par emplacement, chaque élément est ajouté à partir de la vue NInventoryItemFacility. Tous les emplacements contenus dans celui-ci sont ajoutés automatiquement. FIG Ajout d un magasin à un inventaire Une ligne d inventaire est créée pour chaque ligne de stock. FIG Vue de la liste des lignes d inventaire suite à l ajout d un magasin 41

52 3.7. FONCTIONNEMENT ACTUEL Si l inventaire est par produit, chaque produit nécéssitant un inventaire est ajouté manuellement à partir de la vue ci-dessous. FIG Ajout d un produit dans un inventaire Pour chaque produit, une recherche est effectuée sur l ensemble des magasins afin de trouver les lignes de stock correspondant à ce produit. Une ligne d inventaire est créée pour chaque ligne de stock. FIG Vue de la liste des lignes d inventaire suite à l ajout d un produit à un inventaire 42

53 3.7. FONCTIONNEMENT ACTUEL Une fois l ensemble des lignes de stock créé, l inventaire doit étre réalisé. Ceci est fait depuis la vue d édition de l inventaire en cliquant sur "réaliser". Le statut de l inventaire devient alors "perform" et le statut de toutes les lignes de stock passe automatiquement à "count". Afin d éviter tout mouvement sur les stocks, le statut des lignes de stock inventoriées devient "Inventory locked". Si l inventaire est créé par emplacement, le statut des magasins en cours d inventaire devient également "Inventory locked". FIG Vue d édition d un inventaire : réalisation de l inventaire 43

54 3.7. FONCTIONNEMENT ACTUEL Au cours du comptage, une nouvelle ligne d inventaire peut être ajoutée. Ceci est utilisé lorsqu un stock non inventorié est trouvé. FIG Ajout d une ligne d inventaire en cours de comptage Une ligne d inventaire ainsi qu une ligne de stock sont alors créées FIG Vue de la liste des lignes d inventaire après ajout d une ligne d inventaire 44

55 3.7. FONCTIONNEMENT ACTUEL Pour chaque ligne de stock, les quantités trouvées sont saisies en cliquant sur "saisir". Plusieurs comptages sur une même ligne peuvent être saisis. FIG Vue de la liste des lignes d inventaire en cours de saisie Une fois les quantités saisies, chaque ligne de stock est validée. Cette opération compare le stock théorique au stock réel. Si un écart apparait, le stock théorique est ajusté et un mouvement de stock est enregistré. FIG Vue de la ligne d inventaire après validation d une ligne 45

56 3.7. FONCTIONNEMENT ACTUEL Lorsque toutes les lignes d inventaire sont validées, l inventaire est clos en cliquant sur "clôturer" depuis la vue d édition. FIG Vue d édition d un inventaire après clôture d un inventaire Seule les opérations de consulations sont alors disponibles FIG Vue de la liste des inventaires après clôture Améliorations fonctionnelles de la plannification des besoins Plannification d une commande Cet exemple montre l intéraction entre le composant Order de Ofbiz et le composant Facility de Neogia. Il illustre également le regroupement dans une seule table de tous les mouvements plannifiés de stock. Pour cet exemple, deux produits sont commandés. 46

57 3.7. FONCTIONNEMENT ACTUEL FIG Vue d une commande depuis le composant Order d Ofbiz Suite à l enregistrement de la commande, une réservation des deux produits est enregistrée dans la table des mouvements plannifiés. FIG Liste des mouvements plannifiés de stock 47

58 3.8. AMÉNAGEMENT EN COURS ET AMÉLIORATIONS 3.8 Aménagement en cours et Améliorations Le composant de gestion de stock développé au cours de ce stage est devenu fonctionnel. Toutefois, son intégration dans Ofbiz en remplacement de l actuel composant ne peut être envisagée pour le moment, trois points restant à travailler. En premier lieu, il reste à finaliser les interactions du composant de gestion de stock avec le composant Expédition d Ofbiz. Actuellement, un diagramme UML et un diagramme fonctionnel ont été élaborés mais le code doit encore être généré et les services et méthodes nécessaires à cette communication doivent être créés. De même, le fonctionnement général du composant doit être encore travaillé. En effet, bien qu il apporte des améliorations fonctionnelles et architecturales, certaines fonctionnalités présentes dans Ofbiz ne sont pas implémentées. On peut donc considérer que le composant a un niveau fonctionnel inférieur à celui d Ofbiz et il apparaît nécessaire de finaliser un ensemble d outils, concernant notamment la gestion des personnes et le réapprovisionnement. Enfin, comme tout logiciel, il doit être sécurisé et testé. Bien que ces deux notions soient constamment présentes lors du développement du composant, il est important d accroître la sécurité du code notamment par l utilisation d EECA ou d interfaces graphiques dont l affichage est modifié en fonction de valeurs. Une fois le composant intégré à Ofbiz, différentes optimisations peuvent être envisagées, dont les principaux exemples peuvent être donnés comme suit : l ajout d outils de reporting notamment pour les inventaires, la gestion des stocks et la planification des événements ; le développement de nouvelles vues améliorant l érgonomie de l IHM (vue hiérarchique des magasins, affichage sélectif des événements planifiés...) ; l intégration de nouvelles règles métier pour l inventaire et la gestion des stocks ; l intégration des événements planifiés dans le worklow ; 48

59 Conclusion Bilan du projet L ERP Ofbiz est un logiciel très complet proposant de nombreux composants «métier» mais également des composants «techniques» qui sont liés au framwork (entity Engine, Sevice Engine, Control Servlet...). Toutefois, cette richesse s accompagne d une complexité architecturale difficile à appréhender dans sa totalité. La création d un composant constitue alors une tâche d autant plus complexe. La génération de code proposée par la société Code Lutin et utilisée dans le projet Neogia, est une alternative très intéressante au développement «classique» d un composant. Bien qu il soit toujours nécessaire de consacrer un temps important pour la compréhension du logiciel, elle permet d automatiser la génération d éléments de base, lesquels devront simplement être paramétrés, facilitant ainsi une partie du travail du développeur. Enfin, elle oblige à réaliser un diagramme de classes qui donne une vision globale du composant. Cependant, ces remarques peuvent être nuancées. En effet, le temps de mise au point des générateurs assurant un code généré exempt de bug est une phase très longue. Pour ce projet, ce travail aura duré plus d un mois. Le temps disponible pour le codage de la partie métier a dès lors été fortement réduit. Ainsi on peut considérer que pour le projet Neogia, le temps de développement d un composant via les générateurs de code a été au moins égal au temps qu il aurait été nécessaire de consacrer sans les générateurs de code. Cette vision, à court terme, doit également être nuancée. En effet, le temps nécessaire pour maintenir le code à jour notamment après une évolution du framework ou lors de l intégration de nouvelles fonctions de base sera fortement réduit. De même, si un nouveau composant devait être créé maintenant, son temps de développement serait beaucoup plus court. Les générateurs de code sont donc des outils qui augmentent la productivité à moyen et long terme. Ainsi, ils peuvent répondre à la problématique des entreprises du logiciel libre qui doivent consacrer le moins de temps possible à la partie basse du code au profit du code métier. 49

60 3.8. AMÉNAGEMENT EN COURS ET AMÉLIORATIONS Bilan personnel Le stage éffectué au sein des sociétés Code Lutin et Néreide m a permis d intégrer deux entreprises travaillant dans le logiciel libre dont les orientations technologiques m ont donné la possibilité de travailler sous le système gnu/linux et plus généralement d utiliser des logiciels Libres qui pour certains d entre eux m étaient jusqu alors peu familiers. Par ailleurs, la réalisation du projet Neogia a été un travail de groupe avec l aide de logiciels de partage de données (CVS, Subcersion, Jabber,...), ce qui a imposé une certaine rigueur, acquise au fil du projet. Enfin, ayant travaillé sur un ERP, ce stage aura été l occasion de faire le lien entre certaines connaissances acquises lors de mon expérience professionnelle précédente dans le secteur de l industrie agroalimentaire et des connaissances en informatique. 50

61 Annexe A Diagrammes UML 51

62 52

63 FIG. A.2 Organisation de l inventaire 53

64 FIG. A.3 Plannification des événements sur les stocks 54

65 FIG. A.4 Relation entre les composants Facility et Manufacturing 55

66 FIG. A.5 Relation entre les composants Facility et Order 56

67 Annexe B Exemple de code B.1 Défintion de table NFacility pour l entity Engine : entitymodel.xml... <entity entity-name="nfacility" package-name="org.ofbiz.facility.location"> <field name="idname" type="name"></field> <field name="locations" type="name"></field> <field name="parentfacilityidname" type="name"></field> <field name="statusfacilitystatusid" type="id-ne"></field> <field name="nfacilitytypeenumid" type="id-ne"></field> <prim-key field="idname"/> <relation type="many" title="childfacilities" rel-entity-name="nfacility"> <key-map field-name="idname" rel-field-name="parentfacilityidname"/> </relation> <relation type="one-nofk" title="parentfacility" rel-entity-name="nfacility"> <key-map field-name="parentfacilityidname" rel-field-name="idname"/> </relation> <relation type="one-nofk" rel-entity-name="statusitem"> <key-map field-name="statusfacilitystatusid" rel-field-name="statusid"/> </relation> <relation type="one-nofk" rel-entity-name="enumeration"> <key-map field-name="nfacilitytypeenumid" rel-field-name="enumid"/> </relation> </entity>... 57

68 B.2. DÉFINITION D UN CONTRÔLE : CONTROLE.XML B.2 Définition d un contrôle : controle.xml... <request-map uri="editnfacility"> <security https="true" auth="true"/> <event type="service" invoke="editnfacility"/> <response name="success" type="view" value="editnfacility"/> <response name="error" </request-map>... type="view" value="editnfacility"/> B.3 Définition d un service : services.xml... <service name="editnfacility" default-entity-name="nfacility" engine="java" location="org.ofbiz.facility.location.generated.nfacilityservices" invoke="editnfacility" auth="true"> <description>create or Update a NFacility</description> <auto-attributes include="all" mode="inout" optional="true"/> <attribute name="actionform" type="string" mode="in" optional="false"/> </service>... <service name="addplannedproductorder" default-entity-name="orderstockeventplanned" engine="java" location="org.ofbiz.facility.stockevent.developed.orderstockeventplannedservices" invoke="addplannedproductorder" auth="true"> <description>create a OrderStockEventPlanned. You can specifie the Facility or the StockItem</description> <auto-attributes include="all" mode="inout" optional="true"/> <attribute name="productstoreid" type="string" mode="in" optional="true"/> <attribute name="productproductid" type="string" mode="in" optional="true"/> <attribute name="quantity" type="double" mode="in" optional="true"/> <attribute name="releasedate" type="timestamp" mode="in" optional="true"/> <attribute name="stockitemidname" type="string" mode="in" optional="true"/> <attribute name="quantitynotreserved" type="double" mode="out" optional="true"/> </service>... 58

69 B.4. EXEMPLE DE GETTEUR ET DE SETTEUR IMPLÉMENTÉ DANS LES CLASSES DE BASE : NFACILITYBASE.JAVA B.4 Exemple de getteur et de setteur implémenté dans les classes de base : NFacilityBase.java... public String getlocations(){ if (exist ) return ((String) nfacility.get("locations")); return null; } public void setlocations(string _locations ){ if (exist ) if ( _locations!= null ) nfacility.set("locations", _locations); else if ( nfacility.get("locations")!= null) nfacility.set("locations", null); return; }... B.5 Exemple de code développé dans une classe : NFacility.java... /** * Find all sub-child nfacility: Facility in which you want to find sub-child */ protected void FindChild(NFacility nfacility){ List listnfacilitychild = new ArrayList(); Map map = new HashMap(); NFacility locnfacility = null; listnfacilitychild =NFacilityQuery.findByAnd(nFacility.getIdName()); for (int i= 0; i< listnfacilitychild.size();i++){ this.childlist.add(listnfacilitychild.get(i)); map = (Map)listNFacilityChild.get(i); String NFacilityIdName = (String)map.get("idName"); locnfacility= new NFacility(locDelegator,NFacilityIdName); this.findchild(locnfacility); } } /** * Find all sub-child Facility List of all sub-child NFacility */ public List FindAllChild(){ this.findchild(this); return this.childlist; }... 59

70 B.6. EXEMPLE DE MÉTHODE STATIQUE D INTÉROGATION DE LA BASE DE DONNÉES VIA L ENTITY ENGINE : STOCKEVENTPLANNEDQUERRY.JAVA B.6 Exemple de méthode statique d intérogation de la base de données via l Entity Engine : StockEventPlannedQuerry.java... public static List findbyand(string productproductid, String nfacilityidname){ try{ return new ArrayList(delegator.findByAnd("StockEventPlanned",UtilMisc.toMap("productProductId", productproductid, "nfacilityidname",nfacilityidname))); } catch(genericentityexception e){ Debug.logError("findByAnd in StockEventPlannedQuery :" + e.getmessage(), module); return null; } } public static List findbyand(string productproductid, EntityComparisonOperator productentityoperator, Date releasedate, EntityComparisonOperator releasedateoperator ){ try{ return new ArrayList(delegator.findByAnd("StockEventPlanned",UtilMisc.toList(new EntityExpr("productProductId", productentityoperator, productproductid), new EntityExpr("releaseDate", releasedateoperator, releasedate)))); } catch(genericentityexception e){ Debug.logError("findByAnd in StockEventPlannedQuery :" + e.getmessage(), module); return null; } }... 60

71 B.7. DÉFINITION D UNE PAGE : EDITASSOCINVENTORY.XML B.7 Définition d une page : EditAssocInventory.xml... <?xml version="1.0" encoding="utf-8"?> <page> <template>main</template> <property name="titleproperty">facilityeditassocinventory</property> <property name="headeritem">inventory</property> <property name="submenu">/inventory/developed/tabbarphysicalinventory.ftl</property> <property name="tabbuttonitemproduct">product</property> <property name="tabbuttonitemninventoryitem">ninventoryitem</property> <property name="tabbuttonitemroletype">roletype</property> <property name="tabbuttonitemstatusinventory">statusinventory</property> <property name="tabbuttonitemnfacility">nfacility</property> <property name="singleformname">subeditinventoryfacilityinventory</property> <property name="viewsize">20</property> <property name="permission">facility</property> <property name="entityoperation">_update</property> <property name="permissiontype">simple</property> <property name="formdeffilesubeditninventoryitem">/inventory/developed/formsninventoryitem.xml</property> <property name="formdeffilesublistninventoryitem">/inventory/developed/formsninventoryitem.xml</property> <property name="formdeffilesublistinventoryfacility">/inventory/developed/formsinventoryfacility.xml</property> <property name="formdeffilesubeditinventoryfacility">/inventory/developed/formsinventoryfacility.xml</property> <property name="formdeffilesublistinventoryproduct">/inventory/developed/formsinventoryproduct.xml</property> <property name="formdeffilesubeditinventoryproduct">/inventory/developed/formsinventoryproduct.xml</property> <content-action name="/includes/checkpermission.bsh"/> <content-action name="/inventory/developed/editassocinventory.bsh"/> <content-action name="/includes/pagelistprep.bsh"/> <!-- <content-action name="/stockevent/developed/facilityinventory.bsh"/>--> </page>... 61

72 B.7. DÉFINITION D UNE PAGE : EDITASSOCINVENTORY.XML 62

73 B.8. DÉFINITION D UNE VUE UTILISANT L AFFICHAGE CONDITIONNEL (USE-WHEN) : NINVENTORYITEM.XML B.8 Définition d une vue utilisant l affichage conditionnel (usewhen) : NInventoryItem.xml... <form name="subeditninventoryiteminventory" type="single" target="editninventoryiteminventory" title="" default-map-name="formsdata" default-title-style="tableheadtext" default-widget-style="tabletext" default-tooltip-style="tabletext" > <alt-target use-when="formsdata.get("statusinventorystatusid").equals("s_inv_perform") &&!actionform.equals("input")" target="addninventoryitemwhenperform"/> <field name="actionform" use-when="!"${actionform}".equals("add")"><hidden value="commit${actionform}"/></field> <field name="actionform" use-when=""${actionform}".equals("add") && ("${siistatusid}".equals("s_inv_item_count") "${siistatusid}".equals("s_inv_item_recount"))"><hidden value="commitedit"/></field> <field name="actionform" use-when=""${actionform}".equals("add") &&!"${siistatusid}".equals("s_inv_item_count") &&!"${siistatusid}".equals("s_inv_item_recount")"><hidden value="commitadd"/></field> <field name="association"><hidden value="${association}"/></field> <field name="idname" title="${uilabelmap.facilityidname}" use-when="${isadd}!=null"><hidden/></field> <field name="idname" title="${uilabelmap.facilityidname}" use-when="${isadd}==null"><display/></field> <field name="facility" title="${uilabelmap.facilityfacility}" use-when="${isadd}==null "${actionform}".equals("input")" ><display/></field> <field name="facility" title="${uilabelmap.facilityfacility}" use-when=""${actionform}& quot;.equals("add") && "${formsdata.statusinventorystatusid}".equals("s_inv_perform")"><text/></field> <field name="facility" title="${uilabelmap.facilityfacility}" use-when=""${actionform}".equals("add") && "${formsdata.statusinventorystatusid}".equals("s_inv_perform")"> <lookup target-form-name="lookupfacility"/> </field> <field name="countnum" title="${uilabelmap.facilitycountnum}" use-when="${isadd}==null "${actionform}".equals("input")"> <display/> </field> <field name="facilitystockeventidname" title="${uilabelmap.facilityfacilitystockeventidname}"> <hidden/> </field> <field name="facilitystockeventdescription" title="${uilabelmap.facilitydescription}" use-when="${isadd}==null"><display/></field> <field name="stockitemidname" title="${uilabelmap.facilitystockitemidname}" use-when="${isadd}==null "${actionform}".equals("input")"><display/></field> <field name="stockitemidname" title="${uilabelmap.facilitystockitemidname}" use-when="${isadd}!=null &&!"${actionform}".equals("input") &&!"${formsdata.statusinventorystatusid}".equals("s_inv_perform")"><text/></field> <field name="statusinventoryitemstatusid" title="${uilabelmap.facilitystatusinventoryitemstatusid}" use-when="${isadd}==null"> <display/> </field> <field name="product" title="${uilabelmap.facilityproduct}" use-when=""${actionform}".equals("input") (${isadd}!=null && "${formsdata.statusinventorystatusid} ".equals("s_inv_perform"))"><text description="${product}"/></field> <field name="product" title="${uilabelmap.facilityproduct}" use-when=""${actionform}".equals("input") (${isadd}!=null && "${formsdata.statusinventorystatusid} ".equals("s_inv_perform"))"> <lookup target-form-name="lookupproduct"/> </field> <field name="inputdate" title="${uilabelmap.facilityinputdate}" use-when=""${actionform}".equals("input") (${isadd}!=null && "${formsdata.statusinventorystatusid}".equals("s_inv_perform"))"><date-time/></field> <field name="submitbutton" title="${uilabelbutton}" widget-style="smallsubmit" > <submit button-type="button"/></field> </form>... 63

74 B.9. DÉFINITION DES LABES UTILISÉS DANS L INTERFACE GRAPHIQUE : FACILITYUILABELS.PROPERTIES B.9 Définition des labes utilisés dans l interface graphique : FacilityUiLabels.properties... # Facility Main Title FacilityFacility=Facility FacilityStock=Stock FacilityShipment=Shipment FacilityTransfert=Transfert FacilityReceipt= Receipt FacilityReturn=Return FacilityPhysicalInventory=Physical Inventory FacilityCalendar=Calendar FacilityAllMovement=All Movement... 64

75 Annexe C Vue standard vs vue modifée 65

76 FIG. C.1 vue standard FIG. C.2 vue modifiée en fonction du status des lignes d inventaire 66