Multi-delegator
Contents |
Objectif
Le but de ce document est de décrire Comment configurer une instance d'Ofbiz pour utiliser plusière bases de données dans un seul environnement d'execution. Cela veut dire qu'on veut obtenir une une application ofbiz qui permet à l'utilisateur de choisir une base de données sur laquelle il veut travailler. Une telle cofiguration est utiles dans le cas où plusiere filiales utilisent chacune son propre système d'information et un organimse centrale qui à une vision générale sur tous les SI. L'importance de telle configuration vient du faite qu'elle reduit le temps necessaire pour configurer et maintenir tel système (sans parler coût evidement).
Introduction
l'accès à la base de données, dans le framwork Ofbiz est rendu totalement transparent pour le développeur par l'introduction du DELEGATOR. Le Delegator peut être défini comme un agent intermediaire entre les éléments de traitement: services et script bsh d'un côté, et de la base de données. Lors du définition du delegator, on lui attribue un source de données qui décrit la BDD ses carateristique est les moyens d'y acceder. Deux composants majeurs d'Ofbiz s'interagissent avec le delegator:
- Dispatcher: le coeur du moteur de srvice;
- JobManager: un composant qui permet d'automatisation l'execution de services.
Une application Ofbiz est composé d'un ensemble de modules telque Accounting, Party, Order etc.. Ces modules maintiennet chacun un contrôlleur de servlet qui lui permet de recevoir le actions d'un utilisateur selon lesquels il réagit. Ce contrôlleur de srevlet detient un ensemble de paramètre dans ce qu'on appèlle un context, parmis ses parametères on peut citer: l'identité de l'utilisateur connecté(session); le delegator (base de données); dipatcher (un moteur de service); etc..
Téléchergement
Vous pouvez trouver le patch qui date du 25-10-2008 sur le issue tracker d'ofbiz. Pour plus de discussion sur le sujet [1] n'oubliez pas de votez pour le jira. Pour télécharger le fichier [2]
Configuration
Pour configurer un Ofbiz avec multi delegator vous devez appliquer ce patch( patch fait à partir de la release 705872 truk du projet Ofbiz).
Ce patch affecte les fichier suivant:
- WebappUiLabels.xml,CommonUiLabels.xml: label et message pour le nouveau champ (société) dans le fromualire de connexion;
- Security.properties:ajouter un parametre pour savoir est qu'on utilise plusieurs delegator ou non(ex: pour savoir ce que on affiche dans loginform);
- login.ftl: ajouter un champ dans le formualaire de connecion;
- entitymodel.xml: prévoi un champs pour stocké le nom de la base auquelle l'utilisateur est connecté;
- entityengine.xml: il faut créer autant de delegator que vous voulez avec chcun son datasource;
- JobManager.java: créer une méthode qui change ( set ) delegator utiliser par le job manager;
- LocalDispatcher.java, ServiceDispatcher.java: prévoir la modification du delegator utiliser par le dispatcher;
- GenericAbstractDispatcher.java: créer une méthode qui change ( set ) le delegator à utiliser par ce dispatcher;
- ServiceDispatcher.java: créer une méthode qui change ( set ) le delegator à utiliser par ce dispatcher;
- LoginServices.java:après la validation du login+password on stocke le nom de la BDD( à laquelle l'utilisateur a demander une connection) dans sa la genericvalue.
- header.ftl: pour des besoins de testes afficher la BDD actuelle dans l'ecran ofbiz;
- LoginWorker.java: c'est la que tout q'on a la partie la plus importante du travail. Le modification sont décrite selon l'ordre d'apparition dans le fichier:
- la méthode setLoggedOut : pour marker que un utilisateur est déconnecté:
- A la deconnexion d'un utilisateur suppriumer le nom de la base stocker,lors de la connexion, dans sa GenericValue(UserLogin);
- la méthode checkLogin: pour si un utilisateur est déja connecté ou non:
- A la connexion essayer de récuperer le nom de labse dans la requête http, sinon dans la session(comme pour le login et le password);
- la méthode login: qui vérifie l'existance d'un utilisateur et la validité de son compte(password, NbrEssai etc..):
- A la connexion essayer de récuperer le nom de labse dans la requête http (comme pour le login et le password);
- Si le système est configuré pour plusière base l'utilisateur doit saisir le nom de la BDD avec le login et le mot de passe;
- juste avant de appeler le service qui va chercher dans la base, il faut indiquer qu'on veut vérifier aythentification de cet utilisateur contre la BDD qu'il fournit;
- stock le nom de la BDD dans la GenericValue à la réussite de l'authentification;
- la méthode doMainLogin :
- Appeller le service changeDelegator qui modifie la BDD utilisée par le dispatcher et le jobmanger et met le nom de cette base dans la session acxtuelle;
- la méthode setLoggedOut: pour notifier que l'utilisateur est deonncté:
- changer la BDD pour utiliser celle definie par default dans entityengine.xml;
- la méthode checkExternalLoginKey: elle utiliser pour authentifier un utilisateur connecté à un module qui demande un autre module:
- On verifie la présence de sa GenricValue dans le context actuel du nouveau module:
- Si c'est present avec la même BDD la connexion réussi,
- Sinon appeler le service qui change la BDD utiliser pendant la session actuelle;
13. CoreEvents.java:
- on va juste modifier la méthode changeDelegator dans cette class:
- Il faut modifier la BDD avant le check de permission pour le changement de Base;
