SOMMAIRE  Introduction  BCO / Toolbox aujourd’hui  Recommandations pour BCO  CRP aujourd’hui  Recommandations pour CRP  La base de données  Recommandations pour la base de données  Les tests  Environnements de développement

BCO >.jar > FRW_ DMZ 2 : WAS 2 DMZ 1 : WAS 1 DCS >.jar > FRW_ > > FRW_ DMZ 2 : WAS 2 DMZ 1 : WAS 1 > SO >.jar > FRW_ > > FRW_ DMZ 2 : WAS 2 DMZ 1 : WAS 1 > Architecture des projets BCO Toolbox  BCO / Toolbox aujourd’hui  Recommandations pour BCO  CRP aujourd’hui  Recommandation pour CRP  La base de données  Recommandations pour la base  Les tests  Environnements de développement Légendes FRW_ : Framework ancêtre SweetDev Machine Fronts Machine Métiers Librairies communes à l’ensemble BCO / Toolbox Toolbox

> DMZ 2 : WAS 2. XML Décrit pojonput pojoOutput DMZ 3 PS Procédure stockée PS JDBCJDBC - Framwork ancetre de SweetDev -Dans la toolbox, le métier est exclusivement embarqué dans la base de données à travers des procédures stockées. -Les EJB n’ont aucune intelligence. Ils se contentent de faire appel à ces procédures stockées. Les résultats des appelles sont retournés et exploités à travers des pojos java. - Chaque EJB se base sur 2 fichiers XML. - Ces derniers décrivent la procédure stockée à appeler ainsi que le pojo en entré de la procédure stockée et le pojo matérialisant le retour après exécution.  BCO / Toolbox aujourd’hui  Recommandations pour BCO  CRP aujourd’hui  Recommandation pour CRP  La base de données  Recommandations pour la base  Les tests  Environnements de développement

 BCO / Toolbox aujourd’hui  Recommandations pour BCO  CRP aujourd’hui  Recommandation pour CRP  La base de données  Recommandations pour la base  Les tests  Environnements de développement EJBs Serveur. XML Procédures stockées POJOs Interfaces EJB PrésentationMétier BCO toolbox à plusieurs niveaux de complexité: -L’existence des EJB - Encapsulation des procédures stockées -La complexité des développements se trouve dans la mise en correspondance des interfaces EJB du module front avec les composants métier. Il faut générer une dizaine de fichier pour exploiter un unique EJB métier. Interfaces EJB EJBs Serveur

 BCO / Toolbox aujourd’hui  Recommandations pour BCO  CRP aujourd’hui  Recommandation pour CRP  La base de données  Recommandations pour la base  Les tests  Environnements de développement  Réorganiser les dépendances de librairies dans les différents projets. De plus, ajouter un outil de gestion de dépendance tel que Maven. Ceci permettra également une meilleure gestion des sources et automatisera les déploiements.  Reprendre les « copier/coller » du code de BCO (package com.bnpparibas.compben.*) fait dans les projets SO et DCS. Les remonter dans le projet commun >  Ecrire une documentation technique à destination des développeurs. Celle-ci sera un descriptif des étapes à accomplir (dans l’ordre) pour implémenter de nouveaux comportements dans les applications.  Fournir et installer un plugin (wizard) intégré à l’environnement de développement pour la génération automatique de code. Ce dernier prendra en charge la génération des différents fichiers de configuration pour l’implémentation d’un EJB métier. Recommandations pour BCO / Toolbox

 BCO / Toolbox aujourd’hui  Recommandations pour BCO  CRP aujourd’hui  Recommandation pour CRP  La base de données  Recommandations pour la base  Les tests  Environnements de développement.XLS Données GRH Monde retraitée.XLS Données de compensation post campagne Export BCO.XLS Export Métier Métier Retraitement.XLS Import Exploitation Vue macroscopique de CRP Import

CRP > DMZ B : WAS 2 DMZ A : WAS 1  BCO / Toolbox aujourd’hui  Recommandations pour BCO  CRP aujourd’hui  Recommandation pour CRP  La base de données  Recommandations pour la base  Les tests  Environnements de développement Architecture logiciel de CRP

 BCO / Toolbox aujourd’hui  Recommandations pour BCO  CRP aujourd’hui  Recommandation pour CRP  La base de données  Recommandations pour la base  Les tests  Environnements de développement  Imports non packagé / Mutualisé  Export non packagé / Mutualisé  Internationalisation partiel et lourde  Pas de module dédié à la juridiction  Code métier partagé entre le monde Java et les procédures stockées.  Les procédures stockées sont transactionnelle mais pas les requêtes JDBC dans le code Java  Impossible de connaitre le status d’une mise à jour de la base.

Refactoring De CRP -Migrer dans la version récente de SweetDev -Implémenter l’internationalisation grâce à SweetDev JSPMétier - Refactorer les jsp: Bean java pour les données -Refondre les EJB ( DAO simple + EJB Métier) -Mutualiser les export dans un service unique - Mutualiser les imports dans un service unique -Utiliser une API de génération Excel en streaming => Préservation de la RAM -Basculer le code métier dans les PS (comme BCO) ou dans le code java (Hibernate) -Se baser sur SweetDev pour avoir une gestion centralisé de la juridiction + Hibernate facilite la juridiction des données  BCO / Toolbox aujourd’hui  Recommandations pour BCO  CRP aujourd’hui  Recommandation pour CRP  La base de données  Recommandations pour la base  Les tests  Environnements de développement

 BCO / Toolbox aujourd’hui  Recommandations pour BCO  CRP aujourd’hui  Recommandation pour CRP  La base de données  Recommandations pour la base  Les tests  Environnements de développement DynDef Id nom_colone type_donnee DynVal Id Id_DynDef Id_ligne value