rapport code lut in

Université François RABELAIS

Faculté Des Sciences Et Techniques - DESS Compétence Complémentaire En InformatiqueParc de Grandmont

37200 TOURS

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

Ofbiz

Au sein de la Société

Code Lutin2, rue Robert le Ricolais, BP 20446

44304 Nantes cedex3

Reponsable de Stage : Mai - Septembre 2004Cédric PINEAU

PIERRE GAUDIN

Maitre de Stage : DESS CCI Tours promotion 2004Olivier HEINTZ

Société Néréide

Remerciements

Mes remerciements vont tout d’abord à Cédric Pineau et Benjamin Poussin qui m’ont permisde réaliser ce stage au sein de leur entreprise, et tout au long duquel leur aide technique et leurdisponibilité ont été fortement appréciables

Je remercie également Olivier Heintz pour m’avoir encadré au cours du stage et plus parti-culiè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 nombreusesquestions.

Enfin, je n’oublie pas Catherine Heintz pour son accueil chaleureux et son aide tout au longde ce stage.

i

Table des matières

Remerciements i

1 Présentation Générale 11.1 Problématiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1.1 Les ERP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1.1.1 Définition d’un ERP . . . . . . . . . . . . . . . . . . . . . . 1

1.1.1.2 Les différents acteurs du marché . . . . . . . . . . . . . . . 2

1.1.1.3 La nouvelle donne des ERP libres . . . . . . . . . . . . . . . 3

1.1.2 Les enjeux de la Génération de code . . . . . . . . . . . . . . . . . . . 4

1.2 Cadre du stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.2.1 La société Code Lutin . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.2.2 Le réseau Libre Entreprise . . . . . . . . . . . . . . . . . . . . . . . 6

1.2.3 La société Néréide . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.3 Objectifs du stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2 Présentation du logiciel Ofbiz et du projet Neogia 82.1 l’ERP Ofbiz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.1.1 Présentation Générale . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.1.2 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.1.2.1 L’Entity Engine . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1.2.2 Le Service Engine . . . . . . . . . . . . . . . . . . . . . . . 10

2.1.2.3 Le ControlServlet . . . . . . . . . . . . . . . . . . . . . . . 10

2.2 le projet Neogia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.2.1 Présentation Générale . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.2.2 Objectifs détaillés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

ii

TABLE DES MATIÈRES

2.2.3 Organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.2.4 Processus d’intégration des composants Néogia dans Ofbiz . . . . . . 16

3 Développement du composant « gestion des Stocks » 183.1 Déroulement du stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.2 Outils et bonnes pratiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.2.1 Eclipse1 : Un EDI . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.2.2 Poseidon2 : Le logiciel de modélisation . . . . . . . . . . . . . . . . . 19

3.2.3 Les logiciels de constructions de projets . . . . . . . . . . . . . . . . . 20

3.2.3.1 Ant3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.2.3.2 Maven4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.2.4 CVS5 : un logiciel d’échange de données . . . . . . . . . . . . . . . . 21

3.3 Fonctionnement avant mise en place . . . . . . . . . . . . . . . . . . . . . . . 23

3.3.1 Etat des lieux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.3.2 Analyse des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.3.2.1 Modification de l’organisation des magasins . . . . . . . . . 23

3.3.2.2 Développement d’un outil d’inventaire . . . . . . . . . . . . 24

3.3.2.3 Améliorations fonctionnelles de la plannification des besoins 25

3.4 Modélisation UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.4.1 L’entité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.4.2 L’attribut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.4.3 L’association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.5 Génération de code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.5.1 les générateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.5.2 Organisation des fichiers générés . . . . . . . . . . . . . . . . . . . . . 30

3.5.3 Rôle des fichiers générés . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.5.3.1 Interface graphique . . . . . . . . . . . . . . . . . . . . . . 32

3.5.3.2 Définition des tables de la base de données . . . . . . . . . . 32

3.5.3.3 Classes java . . . . . . . . . . . . . . . . . . . . . . . . . . 32

1http ://www.eclipse.org/2http ://www.gentleware.com/3http ://ant.apache.org/4http ://maven.apache.org/5Concurent Versions System, https ://www.cvshome.org/

iii

TABLE DES MATIÈRES

3.5.3.4 Contrôles et Services . . . . . . . . . . . . . . . . . . . . . 33

3.5.4 Intégration des fichiers générés au composant . . . . . . . . . . . . . . 33

3.6 Programmation du code métier . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.6.1 L’interface Graphique . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.6.2 Les services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.6.3 Les classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.6.4 Les Scripts BeanShell . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.6.5 Les requêtes sur l’Entity Engine . . . . . . . . . . . . . . . . . . . . . 34

3.6.6 Architecture des magasins . . . . . . . . . . . . . . . . . . . . . . . . 35

3.6.7 Inventaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.6.8 Centralisation des événements planifiés . . . . . . . . . . . . . . . . . 35

3.7 Fonctionnement actuel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.7.1 Modification de l’organisation des magasins . . . . . . . . . . . . . . . 36

3.7.1.1 Ajout d’une ligne de stock . . . . . . . . . . . . . . . . . . . 36

3.7.1.2 Transfert de Stock . . . . . . . . . . . . . . . . . . . . . . . 38

3.7.2 Outil d’inventaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.7.3 Améliorations fonctionnelles de la plannification des besoins . . . . . . 46

3.7.3.1 Plannification d’une commande . . . . . . . . . . . . . . . . 46

3.8 Aménagement en cours et Améliorations . . . . . . . . . . . . . . . . . . . . . 48

Conclusion 49Bilan du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Bilan personnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

Annexes 51

A Diagrammes UML 51

B Exemple de code 57B.1 Défintion de table NFacility pour l’entity Engine : entitymodel.xml . . . . . . 57

B.2 Définition d’un contrôle : controle.xml . . . . . . . . . . . . . . . . . . . . . . 58

B.3 Définition d’un service : services.xml . . . . . . . . . . . . . . . . . . . . . . 58

B.4 Exemple de getteur et de setteur implémenté dans les classes de base : NFacili-tyBase.java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

iv

TABLE DES MATIÈRES

B.5 Exemple de code développé dans une classe : NFacility.java . . . . . . . . . . 59

B.6 Exemple de méthode statique d’intérogation de la base de données via l’EntityEngine : StockEventPlannedQuerry.java . . . . . . . . . . . . . . . . . . . . . 60

B.7 Définition d’une page : EditAssocInventory.xml . . . . . . . . . . . . . . . . . 61

B.8 Définition d’une vue utilisant l’affichage conditionnel (use-when) : NInvento-ryItem.xml . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

B.9 Définition des labes utilisés dans l’interface graphique : FacilityUiLabels.properties 64

C Vue standard vs vue modifée 65

v

Liste des tableaux

1.1 Les principaux ERP Open Source du marché 6 . . . . . . . . . . . . . . . . . . 4

2.1 Moteurs de rendu du ControlServlet . . . . . . . . . . . . . . . . . . . . . . . 11

3.1 Tags utilisés pour le paramétrage des entités . . . . . . . . . . . . . . . . . . . 27

3.2 Tags utilisés pour le paramétrage des attributs . . . . . . . . . . . . . . . . . . 28

6sources :JDN 23/07/2004

vi

Table des figures

1.1 Organisation d’un ERP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2 Répartition des parts de marché en 2002 . . . . . . . . . . . . . . . . . . . . . 3

2.1 Architecture d’Ofbiz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2 Organisation du projet Neogia . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.3 Organisation d’un composant Neogia . . . . . . . . . . . . . . . . . . . . . . . 16

3.1 Exemple d’organisation de la hiérarchie des emplacements de stockage . . . . 24

3.2 Diagramme de classe représentant l’architecture du facility . . . . . . . . . . . 26

3.3 Organisation du code généré . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.4 Liste de tous les magasins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.5 Ajout d’une ligne de stock depuis un magasin . . . . . . . . . . . . . . . . . . 37

3.6 Liste de toutes les lignes de stock . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.7 Enregistrement d’un transfert de stock . . . . . . . . . . . . . . . . . . . . . . 38

3.8 Liste des transferts de stock plannifiés . . . . . . . . . . . . . . . . . . . . . . 38

3.9 Liste de toutes les lignes de stock . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.10 Vue de la liste des Inventaires . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.11 Vue d’édition d’un inventaire . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3.12 Ajout d’un magasin à un inventaire . . . . . . . . . . . . . . . . . . . . . . . . 41

3.13 Vue de la liste des lignes d’inventaire suite à l’ajout d’un magasin . . . . . . . 41

3.14 Ajout d’un produit dans un inventaire . . . . . . . . . . . . . . . . . . . . . . 42

3.15 Vue de la liste des lignes d’inventaire suite à l’ajout d’un produit à un inventaire 42

3.16 Vue d’édition d’un inventaire : réalisation de l’inventaire . . . . . . . . . . . . 43

3.17 Ajout d’une ligne d’inventaire en cours de comptage . . . . . . . . . . . . . . 44

3.18 Vue de la liste des lignes d’inventaire après ajout d’une ligne d’inventaire . . . 44

vii

TABLE DES FIGURES

3.19 Vue de la liste des lignes d’inventaire en cours de saisie . . . . . . . . . . . . . 45

3.20 Vue de la ligne d’inventaire après validation d’une ligne . . . . . . . . . . . . . 45

3.21 Vue d’édition d’un inventaire après clôture d’un inventaire . . . . . . . . . . . 46

3.22 Vue de la liste des inventaires après clôture . . . . . . . . . . . . . . . . . . . 46

3.23 Vue d’une commande depuis le composant Order d’Ofbiz . . . . . . . . . . . . 47

3.24 Liste des mouvements plannifiés de stock . . . . . . . . . . . . . . . . . . . . 47

A.1 Organisation des magasins . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

A.2 Organisation de l’inventaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

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

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

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

C.1 vue standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

C.2 vue modifiée en fonction du status des lignes d’inventaire . . . . . . . . . . . . 66

viii

Chapitre 1

Présentation Générale

1.1 Problématiques

1.1.1 Les ERP

1.1.1.1 Définition d’un ERP

L’ERP1 est un progiciel présentant les principales fonctions nécessaires à la gestion des fluxet 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 ressourcescommunes stockées sur une base de données.

1Enterprise Resources Planning

1

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 deproduction, suivi des processus). Ainsi il permet d’automatiser et d’intégrer les processus, departager les données, de produire et d’accéder à l’information en temps réel.

1.1.1.2 Les différents acteurs du marché

Quelques puissants fournisseurs privés dominent le marché des ERP qui reste relativementconcentré. Ainsi, les trois plus gros fournisseurs, mentionnés ci-après se partageaient presque50% des parts de marché en 20022 :

2source IDC

2


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 solutionsinformatiques.

1.1.1.3 La nouvelle donne des ERP libres

Le marché des ERP devient progressivement un marché de "commodité". En effet, la lutteconcurrentielle ne porte plus sur le produit qui est banalisé mais sur les services qui répondentaux « 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écente3 a montré que 53% des personnes sont prêts à étudier l’utilisation d’unERP libre en alternative à leur ERP existant. L’intérêt des ERP libres devient donc réel, alorsque 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 unedizaine de projets aboutis et utilisés en entreprise.

3ERP 2004 INFOWORLD

3


Nom Origine Licence Environnement FonctionnalitésAria Nola GPL PHP, MySQL Comptabilité, inventaire, paie.Compiere Jorg

JankeMozillaPublicLicence

J2EE, JBoss Gestion des ventes, gestion des cata-logues, des tarifs, suivi des commandes,gestion des achats, des stocks, de la logis-tique, 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 GNOME2developmentplatform, Post-greSQL

Gestion d’entrepôts, des stocks, de tréso-rerie, facturation.

OFBiz(OpenFor Bu-siness)

DavidE. Jones+ AndyZeneski

MIT XML, J2EE Gestion clients, fournisseurs, employés,gestion des articles, des stocks, des com-mandes, gestion de projet, e-commerce

PGISuite

Taïka GPL Linux, Apache,MySQL, PHP

Gestion financière, des achats, gestioncommerciale, des ventes et des stocks.

ValueEnter-prise

Emryn GPL Delphi/Kylix,Java

Comptabilité, gestion de production,CRM .

TAB. 1.1 – Les principaux ERP Open Source du marché 4

1.1.2 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 complexesdu 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 lesproblématiques actuelles de conception de logiciels libres sont en totale opposition. En effet, dufait 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 ditd’architecture, est un enjeu important pour les sociétés de services dans le logiciel libre. Eneffet, cela permet à la société de concentrer ses efforts non sur le codage d’architecture qui nesera 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


Toutefois, pour que l’utilisation de cette génération de code soit optimale, il est essentiel derespecter 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 ducode conçu manuellement.

– La Cohérence : le code doit utiliser des noms de classe et de méthode qui soient cohérentsentre eux.

– La Productivité : un générateur de code doit être plus productif qu’un code rédigé à lamain. Cela se mesure surtout lors d’une régénération afin de généraliser certaines fonc-tionnalités.

– L’Abstraction : elle doit permettre l’évolution du code généré notamment lors du change-ment de technologie de la plateforme.

5

1.2. CADRE DU STAGE

1.2 Cadre du stage

1.2.1 La société Code Lutin

Code lutin est une jeune Société de Services Nantaise spécialisée dans l’environnementlibre (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 enutilisant notamment Java et XML.

– Le déploiement et la maintenance de systèmes « clefs en main » basés sur des solutionslibres : accès à l’Internet sécurisé, services de mail, de partage de fichiers, d’impressionet de sauvegarde.

– Le conseil et la veille technologique sur le monde des logiciels libres et sur les technolo-gies java et xml.

1.2.2 Le réseau Libre Entreprise

La société Code Lutin fait partie du réseau « Libre -entreprise ». Il s’agit d’un regrou-pement de sociétés de services en informatique spécialiste des logiciels libres et du systèmeGNU/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 com-plète possible de l’environnement libre.

Par ailleurs il existe un « laboratoire » dénommé labs.libre-entreprise.org qui met à la dis-position de la communauté du logiciel libre un ensemble de ressources sous licences libres (ou-tils 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 actuelle-ment 55 projets.

1.2.3 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’ERPlibre OFBiz. Elle propose également tous les services de post-implémentation d’un ERP. Lasociété Néréide fait également partie du réseau libre-entreprise.

6

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 LutinGeneratorsdans le cadre de son projet Neogia qui a pour but le développement de nouvelles fonctionnalitésdu logiciel Ofbiz.

Dans ce cadre, la société Code Lutin souhaite participer au projet Neogia en développant uncomposant 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 lagé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é aucomposant

3. Codage de la partie métier et intégration dans Ofbiz

7

Chapitre 2

Présentation du logiciel Ofbiz et du projetNeogia

2.1 l’ERP Ofbiz

2.1.1 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 decré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 logicielslibres. 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 utiliseret même de les vendre. La seule contrainte de cette licence est de respecter le copyright dessources.

Aujourd’hui, le projet rassemble une quinzaine de développeurs dans le monde. Ofbiz estfortement orienté vers le e-commerce mais son architecture modulaire a permis d’intégrer descomposants dédiés à l’ensemble des fonctions que l’on retrouve dans différents types d’entre-prise (service, industrie, commerce...).

2.1.2 Architecture

Ofbiz est une application java client-serveur compatible avec la spécification J2EE définis-sant une architecture logicielle standard. On retrouve ainsi les trois éléments caractéristiques

8

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 chaquecomposant représente une brique logicielle pouvant être réutilisée pour construire des applica-tions diverses. Ce framework repose sur trois composants essentiels sans lesquels une applica-tion standard ne pourrait pas fonctionner : l’Entity Engine, le Service Engine et le ControlServ-let.

2.1.2.1 L’Entity Engine

L’Entity Engine est un composant Ofbiz qui se charge de gérer les transactions avec labase de données. Il est constitué d’une collection d’API qui implémente des objets java quivont accéder aux données de la table via des méthodes. Ainsi le développeur n’accède pas aux

9

2.1. L’ERP OFBIZ

données directement mais via une couche abstraite qui se charge d’accéder aux données et desé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é « EECA1 » même si le SGBD sous-jacent

n’implémente pas cette fonctionnalité.

2.1.2.2 Le Service Engine

Le Service Engine est l’équivalent de l’Entity Engine pour tous les traitements des com-posants Ofbiz. Les traitements sont appelés Services et peuvent être exécutés localement ou àdistance. Le principal intérêt de ce composant est qu’il permet de lancer des services sans avoirbesoin de connaître leur localisation et leur implémentation. C’est le ServiceDispatcher qui secharge alors de trouver l’implémentation du service et de son exécution. Un autre intérêt estla possibilité de rendre disponible tout service Ofbiz vers l’extérieur. Ainsi un composant peutappeler un service d’un autre composant. Ils sont codés soit en XML Mini-Language qui est unoutil 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 garantirune uniformité dans la manipulation des données et d’engendrer des contrôles tel que le loginou la gestion des erreurs.

2.1.2.3 Le ControlServlet

Le ControlServlet est l’élément clé de la communication entre les utilisateurs et les appli-cations web d’Ofbiz. Implémenté selon le modèle MVC (Modèle-Vue-Controleur), il gère laboucle d’évènements de l’interface graphique et les différents moteurs de rendu de l’applica-tion. Les réponses aux interactions de l’utilisateur s’effectuent par l’intermédiaire d’évènementsqui peuvent être implémentés sous la forme de services, de méthodes java, de scripts Beanshellou Minilang.

Un moteur de rendu se charge de renvoyer à l’utilisateur une vue d’un document généré à partirdes évènements précédents et/ou de données. Les moteurs de rendu dont dispose Ofbiz :

1Entity Event-Condition-Action

10

2.1. L’ERP OFBIZ

Moteur DescriptionJSP Les Java Server Pages permettent de générer des pages HTML

dynamiquement.JPublish + FreeMarker JPublish permet de construire une page HTML à partir de plu-

sieurs fichiers traités par FreeMarker et d’appeler pour chacund’entre-eux des scripts BeanShell à différents moments de laconstruction. FreeMarker est un moteur de template qui permetde générer des documents dynamiquement.

FOP + FreeMarker FOP est un processeur XSL qui transforme un document XMLtraité avec FreeMarker en un document HTML ou PDF.

JasperReport JasperReport permet de réaliser très facilement des rapports à par-tir 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 luiafficher une page à l’aide de JPusblish et FreeMarker :

1. L’utilisateur « clique » sur un lien hypertexte ou valide un formulaire. Le navigateur en-voie alors une requête HTTP au serveur Ofbiz qui est interceptée par Tomcat et transmiseau ControlServlet de l’application web correspondante.ex : https://127.0.0.1:8443/ordermgr/control/orderview?order_id=WS10000

2. Le ControlServlet vérifie si l’URI demandée est définie par l’application. Le cas échéant,il appelle le ou les événements associés à cette URI. Dans le cas contraire, il renvoie uneerreur 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êtecorrespondent aux attributs du service.

4. Si l’évènement généré doit appeler un service, il convertit les paramètres de la requêtesous 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èlede 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 etappelle 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

2.1. L’ERP OFBIZ

12. Pour chaque sous-élément, il peut appeler des scripts BeanShell qui récupèrent et mettenten forme les données à afficher.

13. Pour chaque sous-élément, il appelle le moteur de template qui se charge de générer lecode HTML correspondant.

14. Le moteur de rendu assemble les différents sous-éléments pour former une page webcomplète.

15. Le controlServlet transmet la page générée au navigateur web de l’utilisateur.

12

2.2. LE PROJET NEOGIA

2.2 le projet Neogia

2.2.1 Présentation Générale

Le projet Neogia initié par la société Néréide a pour objectif de compléter ou de modifierles 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 afind’accroître la productivité de développement et de limiter l’effort à fournir pour maintenir lecode.

A contrario d’Ofbiz, ce projet est sous licence GPL.

2.2.2 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 nouveauxsoit ils remplacent un composant d’Ofbiz.

– Manufacturing : Il remplace le composant OFBiz existant. Il est remodélisé en UML etapporte les fonctions telles que le MRP2

– 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 denouvelles fonctionnalités liées à la gestion de stocks (inventaire, plannification de mou-vements, hiérachisation des emplacements)

– Accounting : Il remplace le sous-composant OFBiz existant. Il est re-modélisé en UMLet apporte les fonctions de comptabilité analytique.

– Servicemgnt : C’est un nouveau composant. Il est modélisé en UML et apporte de nou-velles 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 ». Eneffet, ils nécessitent d’accéder aux entités de composants Ofbiz. Il faut alors créer la coucheobjet 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.

2Manufacturing Resource Planning

13


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 3.5.

2.2.3 Organisation

L’organisation du projet Neogia a évolué tout au long de son avancement afin de séparer trèsdistinctement 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 2.2.2. Il existe en plus deux dossiers compor-tant 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 ducomposant 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 desbibliothè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 descomposants Neogia.

Le dossier « neogia » contient, à sa racine, un ensemble de fichiers utilisés par les utilitairesMaven et Ant afin de générer l’ensemble des composants ou d’intégrer les composants dansOfbiz (cf section 2.2.4)

14


FIG. 2.2 – Organisation du projet Neogia

Tous les composants du projet possèdent la même organisation. Elle permet de séparer lecode généré du code finalisé.

Le dossier « dist » contient la version « stable » du composant. Lors de l’intégration ducomposant dans Ofbiz ce sont ces fichiers qui sont utilisés. Dans ce dossier il n’y a donc quedes 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 à lamodélistation UML du composant. Ce fichier est utilisé par les générateurs de code (cf section3.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 undossier « src Build » qui est le dossier de travail des générateurs.

15


Le dossier contient, à sa racine, un ensemble de fichiers utilisés par l’utilitaire Maven afinde générer le composant.

FIG. 2.3 – Organisation d’un composant Neogia

2.2.4 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. OrNéogia possède son propre enviromnement. Il est donc nécessaire d’intégrer les nouveaux com-posants dans l’architecture d’Ofbiz. Pour ce faire, une procédure a été mise au point afin de

16


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

Chapitre 3

Développement du composant « gestiondes 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 dansofbiz

18

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 laréalisation du projet Neogia.

Ces outils peuvent être présentés selon quatre catégories :– les EDI1 : 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

3.2.1 Eclipse2 : Un EDI

Eclipse a été créée par la société IBM, laquelle a, part la suite, cédée le code à la commu-nauté afin qu’elle poursuive son développement.

Son but est de fournir une plate-forme modulaire pour permettre des développements infor-matiques, 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 langageJava, d’autres modules pour les langages comme C++, Cobol, mais aussi pour d’autres aspectsdu développement (base de données, conception avec UML . . .) sont en cours de développe-ment.

Dans le cadre du projet Neogia, Eclipse est utilisé comme EDI afin de développer l’ensembledes composants intégrés à cet EDI.

3.2.2 Poseidon3 : 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 « Edi-tion Community » peut générer des diagrammes UML respectant les standards UML 1.4. Ellea 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’unepalette 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 celogiciel 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

1Integrated Development Environment2http ://www.eclipse.org/3http ://www.gentleware.com/4XML Metadata Interchange

19


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 etde générer des fichiers de type XMI qui seront interprétés par les générateurs de code.

3.2.3 Les logiciels de constructions de projets

La communauté libre a développé plusieurs outils facilitant la construction d’applicationsjava parmi lesquels figurent Ant et Maven.

3.2.3.1 Ant5

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 permetrela construction d’applications sans dépendance vis- à-vis de la plateforme. Il trouve toute sonutilité pour des projets développés sur différents systèmes d’exploitation ou devant fonction-ner sur plusieurs systèmes d’exploitation. Il est également utilisé pour migrer des projets d’unsystème à un autre.

Il repose sur un fichier de configuration XML dénommé « build.xml » qui contient un en-semble 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 pro-jet : ant , la suppression du contenu des tables de la base de données : ant clean-data, lechargement 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 undes composants ou l’ensemble des composants : ant.

3.2.3.2 Maven6

Maven est développé par le groupe Apache-Jakarta. Cet outil permet également d’automa-tiser la gestion de projets Java. Il offre les fonctionnalités de compilation et de déploiement

5http ://ant.apache.org/6http ://maven.apache.org/

20


des applications Java, de gestion des librairies requises par l’application, d’exécution des testsunitaires 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 deMaven est plus simple que le fichier de configuration nécessaire à Ant. De plus, il offre desfonctionnalités que Ant ne possède pas et reste plus flexible car il permet aux utilisateurs lacré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 defournir 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 à lagénération de code puis afin de générer le code.

3.2.4 CVS7 : un logiciel d’échange de données

CVS est un outil de suivi de version. Il permet de conserver une trace de l’historique desmodifications d’un fichier, ou d’un ensemble de fichiers, et de revenir simplement à n’importequel état antérieur. Pour garder cet historique, CVS stocke uniquement les différences entredeux 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 stockagecentralisé du code source sur un serveur et gère les accès concurrents sur les fichiers de dévelop-pement. De plus, il offre la possibilité aux développeurs d’accéder en même temps à un mêmefichier afin de le modifier. CVS assure la prise en charge des modifications lorsque celles-ci negénèrent pas de conflits.

En voici quelques lignes de commande :

7Concurent Versions System, https ://www.cvshome.org/

21


cvs checkout rapatrie l’ensemble des fichiers d’un module contenu sur leserveur vers l’ordinateur local

cvs update mise à jour des fichiers locaux à partir de versions situéessur le serveur

cvs commit intègre les modifications d’un fichier en local sur le serveuravec vérification préalable des conflits et attribution d’unnuméro de version

cvs add ajoute un fichier en local. Il est nécessaire de mettre à jourle serveur en utilisant la commande cvs commit

cvs remove supprime le fichier sur le serveur. L’historique du fichier estconservé

Le projet Neogia est contenu sur un serveur CVS. L’ensemble des développeurs utilise CVSpour intégrer leurs modifications effectuées en local et pour récupérer les mises à jour des autresdéveloppeurs.

Le projet Ofbiz était initialement sous CVS. Au cours de l’été, il a migré pour être contenusur un serveur Subversion. Développé par la même équipe, Subversion correspond à l’opti-misation de CVS. Il apporte notament une gestion en version des répertoires, la possibilité derenommer un fichier dans le référentiel ou de le déplacer et la gestion atomique des transactions.

22

3.3. FONCTIONNEMENT AVANT MISE EN PLACE

3.3 Fonctionnement avant mise en place

3.3.1 Etat des lieux

L’application Ofbiz intègre un module de gestion des stocks dénommés « facility ». Cecomposant permet de définir l’ensemble des emplacements physiques d’une société tels que lesstocks, 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 fairepartie d’autres groupes de même type.

Pour chaque élément, il est possible d’associer des personnes ou groupes de personnes afinde 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 destock (inventoryItem). Pour chaque ligne de stock, un ensemble de paramètres est défini telque les quantités en stock, les quantités disponibles, l’emplacement dans le lieu de stockage, lenumé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 per-mettant 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 chaqueligne de stock via une interface graphique.

Les mouvements de stock (transfert, commande, réapprovisionnement,... ) sont réalisés sansaucune centralisation. Les notions de quantité en stock et de quantité disponible sont prisesen compte dans Ofbiz. Toutefois la quantité de produit disponible est calculée uniquement enfonction de prévisions et sans tenir compte de la date de réalisation de l’événement.

3.3.2 Analyse des besoins

L’étude de l’architecture du composant montre certaines insuffisances et amène à envisagerune réécriture totale du composant. Seront présentés ci-après les principaux axes de réorganisa-tion du composant.

3.3.2.1 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 stockagecomprenne d’autres zones de stockage constituant alors une hiérarchie. Il apparaît donc néces-saire de mettre en place la notion de sous-magasin, chaque sous-magasin ayant une référenceau magasin qui le contient.

23


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é sepropagera à tous les sous-niveaux afin d’interdire tous mouvements de stock sur l’ensemble deces sous-niveaux.

3.3.2.2 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éalisationet 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 desaisie en indiquant les produits et les emplacements à compter. Une fois l’inventaire en coursde réalisation, chaque ligne de stock inventorié doit être bloquée afin d’éviter tout mouvementde produit sur cette ligne. Enfin il est nécessaire d’affecter à chaque comptage un groupe depersonne.

24


L’enregistrement est la dernière partie d’un inventaire. Chaque comptage est saisi et com-paré 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 estvalidée et lorsqu’il existe un écart entre le stock théorique et la quantité réelle, un mouvementde stock est engendré et archivé.

Lorsque l’inventaire est clos tous les emplacements sont débloqués. Cet inventaire et l’en-semble des lignes de comptage sont alors archivés.

3.3.2.3 Améliorations fonctionnelles de la plannification des besoins

Ofbiz ne permet pas de centraliser les mouvements de stocks planifiés, de telle sorte quel’état du stock à une date donnée ne peut être déterminé de manière précise. L’ensemble desmouvements (transfert, commande, réapprovisionnemt, production . . .) doit être centralisé afinde pouvoir calculer à tout moment et pour une date donnée les quantités disponibles d’un pro-duit. Cela permet d’améliorer à la fois la planification des besoins en produit et la planificationde la disponibilité des produits.

25

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 dansl’annexe A.

Voici un exemple représentant l’architecture du nFacility. Ce diagramme illustre notammentl’organisation hiérarchique des magasins.

FIG. 3.2 – Diagramme de classe représentant l’architecture du facility

3.4.1 L’entité

Dans Ofbiz, la notion d’entité correspond aux tables d’une base de données. Les entités sontrepré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 sontinterprétés lors de la générération de code et permettent de modifier les fichiers et le code généré.

26


Tag Valeur SignificationshortName "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 sontprésents.

listAll la transaction permettant d’afficher l’ensemble des donnéesd’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é derecherche selon les attributs ayant le tag indexed.

edit génère la transaction Edit qui permet de modifier un enre-gistrement d’une entité.

show génère la transaction Show qui permet depuis une transac-tion List d’afficher les données du champ associé.

showList génère la transaction ShowList qui permet depuis une tran-saction List d’afficher les données du champ associé.

lookup génère la transaction Lookup qui permet d’afficher dans unepo-up les enregistrements de l’entité afin de faciliter la sai-sie de données.

drop-down indique que l’entité apparaît dans un drop-down pour les as-sociations. Ceci est utilisé notamment pour l’affichage desstatuts ou des énumérations

dd-descriptionOnly indique que dans les drop-down, seule la description est af-fichée

defaultValue affiche pour les énumérations et les statusitem ou toute autreassociation une valeur par défaut dans le drop-down. Ce tagest utilisé lorsque un tag identique n’est pas défini sur l’as-sociation.

TAB. 3.1 – Tags utilisés pour le paramétrage des entités

3.4.2 L’attribut

Les attributs correspondent aux champs de la table, chaque entité en possèdant. Le nomdes attributs doit respecter la syntaxe java. Leurs types sont ceux utilisables dans java et leurvisibilité est « protected ». Comme pour les entités, il existe une série de tags propres au projet

27


Neogia qui sont interprétés par les générateurs afin de modifier le code généré.

Tag Valeur Significationreadonly spécifie que la valeur de cet attribut ne sera pas modifiableprimaryKey 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-downvalue paramètre la manière dont sera créée la valeur de l’attribut. Ce tag utilise des

sous-TagsnextSeqId la valeur de cet attribut est générée automatiquement par

Ofbiz l’utilisateur ne poura pas générer ou modifier cettevaleur.

userOrSeq la valeur de cet attribut est générée par l’utilisateur. S’il nele compléte pas, ceci est fait automatiquement.

i18n insère une valeur en différents langages. Ceci génère uneicô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-Tagsindexed Indique qu’un attribut est présent dans la vue de recherche

et que l’utilisateur poura donc faire une recherche avec cetattribut

calculated booleen to say the attribute must be in display in the editForm.

hidden Précise que l’attribut ne sera visible sur aucune forme.listLookup Indique que l’attribut est présent dans le listLookup.list indique que l’attribut est présent dans le list.idName indique que cet attribut est l’ID de l’entité. Il est utilisé lors

de l’affichage des valeurs d’une association. «[idName] des-cription»

description indique que cet attribut est la description de l’entité. Ilest utilisé lors de l’affichage des valeurs d’une association.«[idName] description»

TAB. 3.2 – Tags utilisés pour le paramétrage des attributs

3.4.3 L’association

Les associations représentent les liaisons qui existent entre les différentes tables. Tous lestypes disponibles dans UML sont utilisables. La cardinalité doit être indiquée à chaque extré-mité.

28


associations relation entre deux entitésclasse d’association lorsque la cardinalité est * , * une classe est créée

agrégation montre l’appartenance, la destruction du tout se propage a ces partiescomposition 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 globalede l’architecture du composant et d’autre part, le fichier généré dans Poséïdon sera utilisé parles générateurs de code.

29

3.5. GÉNÉRATION DE CODE

3.5 Génération de code

3.5.1 les générateurs

Les générateurs sont utilisés afin de créer toute la couche java de persistance entre les objetsissus de la modélisation et les entités gérées par Ofbiz, ainsi que l’interface graphique standardet 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 étapeconsiste à transformer les fichiers XMI en fichiers XML appelés « objectmodel ». Ces fichiersreprennent 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èleobjet 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éepar 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 lagé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 permetde créer n’importe quel type de fichier.

3.5.2 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 automati-

quement 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


FIG. 3.3 – Organisation du code généré

3.5.3 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 re-grouper selon leur fonction :

31


3.5.3.1 Interface graphique

La gestion des écrans standards est définie dans les fichiers freemarker (ftl) (cf chapitre2.1.2.3). Il existe 4 types prédéfinis : « edit », « list », « editassoc » et « show » ; ils sont générésen fonction des tags utilisés dans le modèle UML.

edit<Entity>.ftl écran d’édition d’un enregistrement d’une entitélist<Entity>.ftl écran d’affichage sous forme de liste du contenu d’une en-

titéeditAssoc<Entiy>.ftl écran de visualisation des entités associées à une ligne d’en-

registrementshow<Entity>.ftl écran de show

Pour chaque entité, l’organisation des champs dans un écran standard est définie dans unfichier 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 script de récupération des données pour l’affichage d’uneinterface graphique de type edit

find<Entity>.bsh script de récupération des données pour l’affichage d’uneinterface graphique de type liste suite à une recherche

editAssoc<Entity>.bsh script de récupération des données d’entités associées pourl’affichage d’une interface graphique de type editAssoc

3.5.3.2 Définition des tables de la base de données

entitymodel.xml définition des entités pour l’entity engineentitygroup.xml définition des entités pour l’entity engine

(exemple de fichier cf annexe B.1)

3.5.3.3 Classes java

<entity>Base.java implémentation des objets de base et des méthodes de base(setteur et getteur) permettant d’accéder au champ d’unetable

<entity>G.java classe héritant d’un <entity>Baseet implémentant lesconstructeurs de l’objet. C’est à partir de ces fichiers qu’estdéveloppée une partie de la couche métier

(exemple de fichier cf annexe B.4)

32


3.5.3.4 Contrôles et Services

controlerG.xml définition des contrôles de base qui sont appelés lors duControlServlet. Les définitions de ce fichier sont recopiéesdans le fichier controler.xml

servicedefG.xml définitions des services de base. Les définitions de ce fichiersont recopiées dans le fichier service.xml

<entity>Service.java implémentation des services de base de contrôle de transac-tion depuis une interface visuelle

(exemple de fichier cf annexe B.2 et B.3)

3.5.4 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 fonc-tions 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 unephase 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’optimiserl’architecture générale du projet Neogia ce qui a entrainé de nombreuses refontes totalesde l’organisation du composant.

– bien que le composant soit opérationnel quant aux fonctions de base, on peut considérerqu’il reste encore 30% du code à créer par le développeur. En effet, il faut adapter unepartie du code généré mais aussi coder l’ensemble des couches métiers.

33

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 à modifiercertains 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.

3.6.1 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.

3.6.2 Les services– modification de la définition de services afin d’intégrer des nouvelles variables à un ser-

vice standard.– ajout de nouveaux services java permettant un traitement non standard des données, ap-

pelés via une interface graphique modifiée (cf annexe B.3).

3.6.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).

3.6.4 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.

3.6.5 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 com-posant de gestion de stock.

34

3.6. PROGRAMMATION DU CODE MÉTIER

3.6.6 Architecture des magasins

La modélisation UML du composant et la génération de code ont suffi à obtenir une ges-tion 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 dessous-magasins d’un magasin et d’appliquer à cette sous-hiérarchie une modification. Les ser-vices permettant les transferts planifiés de stock ont également été développés. Enfin, certainesinterfaces ont été modifiées afin de sécuriser ou de faciliter la saisie des données.

3.6.7 Inventaire

La modélisation UML de l’inventaire et la génération de code ont permis de mettre en placeles tables de la base de données. Par contre, l’ensemble des interfaces graphiques a dû être modi-fié. En effet, l’affichage et les fonctions disponibles doivent êtres modifiées en fonction de l’étatd’avancement de l’inventaire. Des nouveaux services ont été développés afin de déclencher, devalider ou de clore un inventaire. Ces services font appel à des méthodes, qui elles aussi, ont étédéveloppées.

3.6.8 Centralisation des événements planifiés

La mise en place de la centralisation des événements planifiés n’a pas nécessité de modifi-cation de l’interface graphique. Le principal travail a consisté à créer de nouveaux services afinde faire communiquer le composant de gestion des stocks avec d’autres composants. Ainsi, desservices ont été développés pour enregistrer une commande dans les événements planifiés etpour 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 codegénéré au début de l’utilisation des générateurs était de qualité très inférieur à celui obtenuactuellement. En effet, de nombreuses modifications qui étaient apportées manuellement auxfichiers ont été intégrées aux générateurs. Ainsi, le travail fourni au début de l’utilisation desgénérateurs n’est plus visible.

Enfin Ofbiz est un framework relativement complexe et aucun diagramme UML n’a été uti-lisé afin de décrire le fonctionnement des différents composants. Ainsi, l’intégration des compo-sants Neogia dans Ofbiz est une étape très complexe qui nécessite un important travail préalablepour déterminer les services d’Ofbiz utilisés et accéder au nouveau composant.

35

3.7. FONCTIONNEMENT ACTUEL

3.7 Fonctionnement actuel

3.7.1 Modification de l’organisation des magasins

Les magasins ont une organisation hiérarchique. Ils contiennent une référence au magasinparent (cadre rouge) qui peut être précisée à la création de celui-ci ou lors de son édition. Lavue ci-dessous liste l’ensemble des magasins de l’environnement de test.

FIG. 3.4 – Liste de tous les magasins

3.7.1.1 Ajout d’une ligne de stock

Depuis chaque magasin, une ligne de stock peut être ajoutée. Pour cela, il faut éditer lemagasin, "cliquer" sur le bouton "Stock" puis sur "Add StockItem". Une fois les champs ren-seignés, l’ajout de la ligne de stock se fait en cliquant sur "Ajouter".

36


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


3.7.1.2 Transfert de Stock

Le transfert de stock se fait depuis la vue d’édition d’une ligne de stock. Il faut ensuitecliquer sur "Transfert". La vue suivante est alors automatiquement renseignée. Il ne reste plusqu’à indiquer la destination, les quantités à transférer ainsi que la date du transfert. Il est éga-lement possible d’effectuer un transfert directement en cliquant sur l’onglet transfert. Dans cecas, 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 transfertest effectué instantanément sinon, il est enregistré comme transfert plannifié dans la table desmouvements 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


de stock. Par ailleurs, le stock d’origine est décrémenté et une nouvelle ligne de stock est crééedans le magasin de destination.

FIG. 3.9 – Liste de toutes les lignes de stock

3.7.2 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. 3.10 – Vue de la liste des Inventaires

Pour ajouter des lignes d’inventaire, trois choix sont possibles : soit les lignes sont saisiesune à une depuis la vue d’édition des lignes d’inventaire, soit se sont les magasins qui sont

39


ajoutés à l’inventaire (inventaire par emplacement), ou soit se sont les produits qui sont ajoutés(inventaire par produit).

FIG. 3.11 – Vue d’édition d’un inventaire

40


Si l’inventaire est par emplacement, chaque élément est ajouté à partir de la vue NInvento-ryItemFacility. Tous les emplacements contenus dans celui-ci sont ajoutés automatiquement.

FIG. 3.12 – Ajout d’un magasin à un inventaire

Une ligne d’inventaire est créée pour chaque ligne de stock.

FIG. 3.13 – Vue de la liste des lignes d’inventaire suite à l’ajout d’un magasin

41


Si l’inventaire est par produit, chaque produit nécéssitant un inventaire est ajouté manuelle-ment à partir de la vue ci-dessous.

FIG. 3.14 – Ajout d’un produit dans un inventaire

Pour chaque produit, une recherche est effectuée sur l’ensemble des magasins afin de trouverles lignes de stock correspondant à ce produit. Une ligne d’inventaire est créée pour chaque lignede stock.

FIG. 3.15 – Vue de la liste des lignes d’inventaire suite à l’ajout d’un produit à un inventaire

42


Une fois l’ensemble des lignes de stock créé, l’inventaire doit étre réalisé. Ceci est faitdepuis la vue d’édition de l’inventaire en cliquant sur "réaliser". Le statut de l’inventaire de-vient 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 coursd’inventaire devient également "Inventory locked".

FIG. 3.16 – Vue d’édition d’un inventaire : réalisation de l’inventaire

43


Au cours du comptage, une nouvelle ligne d’inventaire peut être ajoutée. Ceci est utilisélorsqu’un stock non inventorié est trouvé.

FIG. 3.17 – 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. 3.18 – Vue de la liste des lignes d’inventaire après ajout d’une ligne d’inventaire

44


Pour chaque ligne de stock, les quantités trouvées sont saisies en cliquant sur "saisir". Plu-sieurs comptages sur une même ligne peuvent être saisis.

FIG. 3.19 – 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 lestock théorique au stock réel. Si un écart apparait, le stock théorique est ajusté et un mouvementde stock est enregistré.

FIG. 3.20 – Vue de la ligne d’inventaire après validation d’une ligne

45


Lorsque toutes les lignes d’inventaire sont validées, l’inventaire est clos en cliquant sur"clôturer" depuis la vue d’édition.

FIG. 3.21 – Vue d’édition d’un inventaire après clôture d’un inventaire

Seule les opérations de consulations sont alors disponibles

FIG. 3.22 – Vue de la liste des inventaires après clôture

3.7.3 Améliorations fonctionnelles de la plannification des besoins

3.7.3.1 Plannification d’une commande

Cet exemple montre l’intéraction entre le composant Order de Ofbiz et le composant Facilityde Neogia. Il illustre également le regroupement dans une seule table de tous les mouvementsplannifiés de stock. Pour cet exemple, deux produits sont commandés.

46


FIG. 3.23 – Vue d’une commande depuis le composant Order d’Ofbiz

Suite à l’enregistrement de la commande, une réservation des deux produits est enregistréedans la table des mouvements plannifiés.

FIG. 3.24 – Liste des mouvements plannifiés de stock

47

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 en-visagée pour le moment, trois points restant à travailler. En premier lieu, il reste à finaliser lesinteractions du composant de gestion de stock avec le composant Expédition d’Ofbiz. Actuel-lement, un diagramme UML et un diagramme fonctionnel ont été élaborés mais le code doitencore être généré et les services et méthodes nécessaires à cette communication doivent êtrecréés.

De même, le fonctionnement général du composant doit être encore travaillé. En effet, bienqu’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 unniveau fonctionnel inférieur à celui d’Ofbiz et il apparaît nécessaire de finaliser un ensembled’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 soientconstamment 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’affichageest 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 laplanification des événements ;

– le développement de nouvelles vues améliorant l’érgonomie de l’IHM (vue hiérarchiquedes 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

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, SeviceEngine, Control Servlet . . .). Toutefois, cette richesse s’accompagne d’une complexité architec-turale difficile à appréhender dans sa totalité. La création d’un composant constitue alors unetâ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’ilsoit 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 êtreparamétrés, facilitant ainsi une partie du travail du développeur. Enfin, elle oblige à réaliser undiagramme de classes qui donne une vision globale du composant.

Cependant, ces remarques peuvent être nuancées. En effet, le temps de mise au point desgé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 adès lors été fortement réduit. Ainsi on peut considérer que pour le projet Neogia, le temps dedéveloppement d’un composant via les générateurs de code a été au moins égal au temps qu’ilaurait é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 pourmaintenir le code à jour notamment après une évolution du framework ou lors de l’intégrationde 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 etlong terme. Ainsi, ils peuvent répondre à la problématique des entreprises du logiciel libre quidoivent consacrer le moins de temps possible à la partie basse du code au profit du code métier.

49

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 deuxentreprises travaillant dans le logiciel libre dont les orientations technologiques m’ont donné lapossibilité de travailler sous le système gnu/linux et plus généralement d’utiliser des logicielsLibres 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 logicielsde 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 certainesconnaissances acquises lors de mon expérience professionnelle précédente dans le secteur del’industrie agroalimentaire et des connaissances en informatique.

50

Annexe A

Diagrammes UML

51

FIG. A.1 – Organisation des magasins

52

FIG. A.2 – Organisation de l’inventaire

53

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

54

FIG. A.4 – Relation entre les composants Facility et Manufacturing

55

FIG. A.5 – Relation entre les composants Facility et Order

56

Annexe B

Exemple de code

B.1 Défintion de table NFacility pour l’entity Engine : enti-tymodel.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

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" type="view" value="EditNFacility"/>

</request-map>...

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

B.4. EXEMPLE DE GETTEUR ET DE SETTEUR IMPLÉMENTÉ DANS LES CLASSESDE BASE : NFACILITYBASE.JAVA

B.4 Exemple de getteur et de setteur implémenté dans lesclasses 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* @param 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* @return List of all sub-child NFacility*/public List FindAllChild(){

this.FindChild(this);return this.childList;

}...

59

B.6. EXEMPLE DE MÉTHODE STATIQUE D’INTÉROGATION DE LA BASE DEDONNÉES VIA L’ENTITY ENGINE : STOCKEVENTPLANNEDQUERRY.JAVA

B.6 Exemple de méthode statique d’intérogation de la basede 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

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"/>

</page>...

61

B.7. DÉFINITION D’UNE PAGE : EDITASSOCINVENTORY.XML

62

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 (use-when) : 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")"><hiddenvalue="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

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 TitleFacilityFacility=FacilityFacilityStock=StockFacilityShipment=ShipmentFacilityTransfert=TransfertFacilityReceipt= ReceiptFacilityReturn=ReturnFacilityPhysicalInventory=Physical InventoryFacilityCalendar=CalendarFacilityAllMovement=All Movement...

64

Annexe C

Vue standard vs vue modifée

65

FIG. C.1 – vue standard

FIG. C.2 – vue modifiée en fonction du status des lignes d’inventaire

66

rapport code lut in

Documents