B-Orange ERP

Défi

Le produit du client était un système de planification des ressources d’entreprise (ERP) basé sur le projet open source Openbravo. Les experts en logiciels de Redwerk ont été chargés d’étendre les fonctionnalités de ce logiciel en ajoutant un écran supplémentaire à l’interface utilisateur. Pour ce faire, il était essentiel de prendre en compte le contexte de la solution existante et d’ajouter une logique métier personnalisée. Notre équipe a dû créer la couche métier de l’application et adapter la nouvelle interface utilisateur à celle du logiciel existant.

Openbravo est une solution ERP basée sur le web pour les petites et moyennes entreprises, publiée sous la licence Openbravo Public License. Le logiciel a été développé à partir du logiciel ERP Compiere, qui est également open source. En janvier 2008, ce programme figurait parmi les dix projets les plus actifs sur Sourceforge.

Les avantages d’Openbravo pour les entreprises et les organisations résident dans le fait qu’un certain nombre des processus commerciaux les plus courants peuvent être planifiés et organisés facilement. Openbravo prend en charge de nombreux aspects d’une entreprise tels que les ventes, les achats, la fabrication, la gestion de projet, etc. Le logiciel ERP Openbravo est facilement reconnaissable à son interface web verte, à travers laquelle les utilisateurs mettent à jour les enregistrements et les données d’une entreprise. Une fonction particulièrement utile d’Openbravo est qu’elle permet d’exporter des données au format PDF et dans des feuilles de calcul Microsoft Excel.

Redwerk a reçu beaucoup de matière pour travailler : un package contenant les fichiers sources, une structure de projet détaillée et un manuel d’installation. Ensuite, nos experts ont été laissés à eux-mêmes pour créer la couche métier et l’interface utilisateur pour les nouveaux éléments logiciels suivants :

• Onglet de recherche
• Onglet de modification de produit
• Onglet Mémo
• Onglet de création de détails
• Onglet d’informations sur les prix
• Onglet d’informations sur les achats
• Onglet d’informations sur le stock

Nous avons reçu une maquette sous la forme d’un projet web Eclipse. Celui-ci contenait toutes les bibliothèques requises à utiliser directement dans Eclipse avec une configuration de conteneur web Tomcat. Cette interface utilisateur contenait de nouveaux éléments, à savoir des onglets qui devaient être ajoutés au projet et personnalisés avec les opérations logiques appropriées.

Nous avons été invités par Business Momentum à suivre leurs règles de conception HQL/SQL internes, et il a été convenu que tout notre code serait révisé extérieurement par notre client.

Solution

Une fois que nous avons saisi les exigences, la myriade de tables de base de données et de contrôles, etc., nous avons commencé à faire ce que nous faisons de mieux : implémenter de nouvelles fonctionnalités étonnantes étape par étape, ou plutôt, onglet après onglet.

La structure très complexe de la couche métier était basée sur un projet JPA qui contenait toute la logique métier requise. Un grand nombre de classes y avaient déjà été ajoutées pour bien fonctionner avec la base de données Openbravo. Tout cet ensemble assez complexe se retrouve dans l’interface utilisateur avec un module qui avait déjà une structure à onglets, alors que le projet Openbravo lui-même n’est en réalité que le support de l’interface utilisateur.

L’interface utilisateur était basée sur le framework ZUL, ce qui a présenté notre premier obstacle sur la voie de la résolution de ce puzzle de développement logiciel particulier. Ici, la mise en page était décrite dans des fichiers spéciaux sur lesquels l’interface utilisateur était construite. Cependant, selon les directives de codage pour ces projets, nous devions écrire tout notre code en Java. Et devinez quoi ? Il n’y avait aucun manuel ou instruction disponible sur l’utilisation de Java dans ce contexte particulier. Ce qui a donné lieu à un long processus de travail et de discussions plutôt chronophages du genre « À quoi ressemblerait l’interface utilisateur si j’utilisais telle ou telle méthode ? », etc. Il n’y avait que quelques exemples disponibles, mais le reste devait être créé entièrement à partir de zéro selon nos exigences spécifiques. De plus, chaque modification de l’interface utilisateur nécessitait un redémarrage de Tomcat.

Enfin, une fonction de recherche devait également être implémentée, et pour que cela se fasse élégamment, le modèle économique devait être étendu avec de nouveaux objets pour l’affichage des résultats afin de permettre la recherche par paramètres définis par l’utilisateur.