Integration avec plusieurs autres logiciels

Bonjour,

Je ne sais pas si je suis au bon endroit pour poster, mais j'ai un probleme d'architecture qui me turlupine.
Je travaille sur un logiciel de ressource humaine qui peut etre couple ou non a un logiciel de paie. Le logiciel est un projet JEE.
Le couplage avec le logiciel de paie s'est fait via web service, cependant le code a ete pas mal impacte etant donnee que certaines donnees peuvent etre obligatoire pour un logiciel et pas l'autre.
Donc desormais dans le code il y a des if(payroll active) do this else do that.
De plus la base de donnees a ete impacte certaine table ont ete cree specialement pour l'autre logicielle, voir meme dans certains juste un ajout de column dans les tables existantes.
Tout ca pour dire que deja la ca commence a etre une usine a gaz, mais desormais on souhaite integrer une 10aine de nouveau payroll engine. Donc il ne va pas etre possible de continuer avec des if else un peu partout, ils nous est necessaire de decouper notre projet differemment, mais personne n'a d'experience la dessus.
J'ai regarde un peu du cote des soa, ou alors du decoupage de notre projet en different jar, mais ceci reste toujours tres flou.
Voila si quelqu'un pourrait m'eclairer un peu sur les differentes architectures possible ca serait sympa.

Salut,

De toutes façons, la gestion des ressources humaines [=G] et la paie[=P] sont des fonctions liées mais différentes: sauf à avoir déployé une solution intégrée qui bornerait l'univers des possible pour que cela reste cohérent, çà va diverger tôt ou tard.

Techniquement, on peut dire que vous avez deux applications G et P qui ont des vies indépendantes l'une de l'autre mais qui doivent être alimentées de façon régulière certaines données produites par l'autre.

Intellectuellement, vous pouvez créer une zone "commune"=ZC comprenant des objets crées par G et lus par P et réciproquement.

Sous la forme de tables d'une base de donnée par exemple.
Le ZC va permettre de construire un couplage "souple" entre les deux (ou plusieurs) applications.

Souple?
Les objets crées par G dans ZC pourront être différents de ceux utilisés par G et évoluer indépendamment. En fait tant que le schéma des informations qu'utilise P n'a pas à être modifié, on peut faire évoluer G indépendamment.

On peut généraliser la chose en disant qu'un objet X est produit par l'application G et que n'importe quel "client" peut les récupérer sous telle forme avec telle modalités.

Une fois que vous avez compris le "principe", la question est "quelles sont les technologies qui peuvent répondre aux besoins et qui seront évolutives pour supporter les autres applications qui viendront se greffer dessus".
Là, je ne peux pas répondre:

• très simple: les applications partagent un même serveur de base de données et ZC peut être réalisé avec quelques tables et des triggers.
• compliqué: une solution de master data management avec des ETL pour extraire, transformer et charger les données entre les différents systèmes.

- W

Bonjour,

petite question technique: comment intégrez-vous vos applications?
est-ce 2 WARs ( RH et paie ) au sein du même EAR?
est-ce un seul WAR dans lequel sont intégré les deux ensembles?

Pourquoi est-ce que j'ai l'impression que le code "if payroll active" est exécuté dans le module RH? est-ce bien le cas? si oui, pourquoi?

Est-ce que les données d'adaptation au module Paye n'auraient-elle pas pu être maintenue dans une base propre à ce module, qui aurait été consultée en complément du retour du service fourni par le module RH?

Sébastien

Citation:

---

Envoyé par Desboys

Bonjour,
petite question technique: comment intégrez-vous vos applications?
est-ce 2 WARs ( RH et paie ) au sein du même EAR?
est-ce un seul WAR dans lequel sont intégré les deux ensembles?

Pourquoi est-ce que j'ai l'impression que le code "if payroll active" est exécuté dans le module RH? est-ce bien le cas? si oui, pourquoi?

Est-ce que les données d'adaptation au module Paye n'auraient-elle pas pu être maintenue dans une base propre à ce module, qui aurait été consultée en complément du retour du service fourni par le module RH?

---

Les deux applications sont faite par deux companies differentes mais tres proche l'un de l'autre. L'application de paie est faite en .NET base de donnees SQL Server, l'application RH est faite en JAVA base de donnees Postgres. Deploye sur des serveurs differents.
Le module RH est le plus impacte car l'application RH a ete developpe apres, et l'application de paie fonctionne bien, a deja beaucoup de client, donc le choix a ete de ne pas trop modifier quelque chose qui marche bien.

Citation:

---

Envoyé par wiztricks

Salut,
Souple?
Les objets crées par G dans ZC pourront être différents de ceux utilisés par G et évoluer indépendamment. En fait tant que le schéma des informations qu'utilise P n'a pas à être modifié, on peut faire évoluer G indépendamment.

On peut généraliser la chose en disant qu'un objet X est produit par l'application G et que n'importe quel "client" peut les récupérer sous telle forme avec telle modalités.

Une fois que vous avez compris le "principe", la question est "quelles sont les technologies qui peuvent répondre aux besoins et qui seront évolutives pour supporter les autres applications qui viendront se greffer dessus".
Là, je ne peux pas répondre:

• très simple: les applications partagent un même serveur de base de données et ZC peut être réalisé avec quelques tables et des triggers.
• compliqué: une solution de master data management avec des ETL pour extraire, transformer et charger les données entre les différents systèmes.

- W

---

Si Je comprend bien, et c'est un peu ce que dit Desboys egalement, le principe aurait ete de ne pas toucher au base de donnees des applications existantes, et de creer un base de donnees dans laquelle les deux applications viendront lire et ecrire les donnees qui seront utiles pour les deux applications.
Avec un exemple concret: disons que du cote RH j'ai une table employee avec First Name, Last Name, DOB obligatoire et dans l'autre j'ai juste First Name, Last Name obligatoire, je cree donc un table dans ZC avec First Name, Last Name, DOB, aucune contrainte, les deux applications viennent ecrire dedans.
Mais apres comment je fait pour afficher mon employee dans ma premiere application vu que la DOB n'est pas renseigne? J'averti l'utilisateur et c'est lui qui s'en occupe?

Citation:

---

Envoyé par wiztricks

Une fois que vous avez compris le "principe", la question est "quelles sont les technologies qui peuvent répondre aux besoins et qui seront évolutives pour supporter les autres applications qui viendront se greffer dessus".
Là, je ne peux pas répondre:

• très simple: les applications partagent un même serveur de base de données et ZC peut être réalisé avec quelques tables et des triggers.
• compliqué: une solution de master data management avec des ETL pour extraire, transformer et charger les données entre les différents systèmes.

- W

---

Nous ca sera la partie complique, mais une fois l'architecture bien defini on devrait trouver les informations pour mettre en place ceci.

Merci

Citation:

---

Si Je comprend bien, et c'est un peu ce que dit Desboys egalement, le principe aurait ete de ne pas toucher au base de donnees des applications existantes, et de creer un base de donnees dans laquelle les deux applications viendront lire et ecrire les donnees qui seront utiles pour les deux applications.

---

Je n'aime pas mélanger "principes" et un exemple de...
Ici, le principe dit que seul P écrira les informations que RH lit.
C'est asymétrique.

Citation:

---

Avec un exemple concret: disons que du cote RH j'ai une table employee avec First Name, Last Name, DOB obligatoire et dans l'autre j'ai juste First Name, Last Name obligatoire, je cree donc un table dans ZC avec First Name, Last Name, DOB, aucune contrainte, les deux applications viennent ecrire dedans.

---

La question est "Ou est crée/détruit un nouvel employé (informatiquement parlant;))? Apriori côté RH puisqu'on ne paiera pas sinon.
Dans ce cas, P n'a besoin que d'une copie (first, last) names. P pourra y accrocher d'autres informations.

La seule chose que nous avons fait jusqu'ici est de dire:
P et RH vivraient très bien si un agent ZC s'occupait de mettre à jour les employés connus par la paie en fonction des entrées/départs de la société.
[ et comment réaliser cela techniquement est une autre histoire ].

Citation:

---

Mais apres comment je fait pour afficher mon employee dans ma premiere application vu que la DOB n'est pas renseigne? J'averti l'utilisateur et c'est lui qui s'en occupe?

---

Dans le cas présent, il me semble illusoire de construire une seule application puisqu'il y en a déjà deux... Mais une des conséquence de ce qui précède est:
"les employés ne sont crées que par l'application qui sait créer le 'DOB'."
- W

Bonjour,

quelquechose me chiffonne sur ce qui est dit.
Pas que je revienne sur le principe d'une solution d'intégration, mais plutôt sur l'intégration faite des applications.

Corrige-moi en cas d'erreur d'appréciation:
L'application de paie expose des services par WebServices.
L'application RH consomme ces services.
De ce fait, si l'application RH est déployée avec le module de paie présent, elle va interroger ces services ( cf. code if (payroll active) ) pour récupérer des infos, voire potentiellement mettre à jour des infos dans l'application de paie. Seulement, si ce déploiement intégré est en place, il est nécessaire de maintenir un référentiel augmenté pour satisfaire cette intégration ( si j'ai compris, la date de naissance est requise pour un employé dans l'application paie, alors que ça n'est pas forcément nécessaire pour l'application RH initialement )

De plus, vous avez pleinement la main sur le module RH, qui peut avoir une configuration standalone, ou bien une configuration "intégré à un module de paie", et ton problème est cette gestion des impacts du mode "intégré".

Ai-je bien tout compris?

Sébastien

Citation:

---

Envoyé par Desboys

Corrige-moi en cas d'erreur d'appréciation:
L'application de paie expose des services par WebServices.
L'application RH consomme ces services.
De ce fait, si l'application RH est déployée avec le module de paie présent, elle va interroger ces services ( cf. code if (payroll active) ) pour récupérer des infos, voire potentiellement mettre à jour des infos dans l'application de paie. Seulement, si ce déploiement intégré est en place, il est nécessaire de maintenir un référentiel augmenté pour satisfaire cette intégration ( si j'ai compris, la date de naissance est requise pour un employé dans l'application paie, alors que ça n'est pas forcément nécessaire pour l'application RH initialement )

De plus, vous avez pleinement la main sur le module RH, qui peut avoir une configuration standalone, ou bien une configuration "intégré à un module de paie", et ton problème est cette gestion des impacts du mode "intégré".

Ai-je bien tout compris?

Sébastien

---

Oui exactement, pour l'instant nous avons deux applications qui fonctionnent tres bien en standalone, le probleme est lorsqu'elles fonctionnent ensemble.
L'application Paie fourni des services via webservices, CRUD pour ce qui semble commun aux deux applications genre employee, addresse, compte en banque... et seulement Read pour ce qui est vraiment specifique a la paie: genre fiche de paie.
L'idee a ete pour l'instant de dire: les deux applications sont totallement synchronisées donc si je crée un employée, un compte en banque... dans une des applications je veux le voir dans l'autre.
Peu importe dans quelle applications l'employé est crée, si je le crée dans le module paie je veux le voir dans le module RH, et si je le crée dans le module RH je veux le voir dans le module Paie.
Etant donné que les contraintes ne sont pas les meme dans les deux applications, genre en standalone dans le module RH la date de naissance est obligatoire mais pas le numéro de Paie, alors que dans le module Paie en standalone c'est l'inverse.
Ce qui a été decidé afin de ne pas toucher au module Paie est lorsque que nous sommes en mode integree dans le module RH j'ai :

Code:

---

1 2 3 4 5 6 7

if (payrollActive) { Validate.notNull(numeroDePaie); } else { Validate.notNull(dateDeNaissance); }

---

Ou encore pire: pour le compte en banque dans le module Paie il doit etre liée a une agence bancaire, alors que dans le module RH on a pas du tout de notion d'agence bancaire donc de nouvelles tables ont été crées pour pouvoir prendre en compte ceci étant donnée que si on crée un compte en banque cote RH on veut qu'il soit disponible coté Paie donc les champs doivent etre les meme.

Pout l'instant les deux applications liées fonctionnent bien ensemble meme si le code et la base de données du module RH commence a devenir brouillon.
Le probleme est que l'on souhaite integrée ce module RH avec un autre module de paie fait par une autre companie, aucune décision n'a encore été prise sur l'architecture a suive, mais il est clair qu'il ne va pas etre possible de faire comme avec le précédent module de Paie, sinon le module RH va devenir completement illisible.

Citation:

---

Envoyé par wiztricks

La question est "Ou est crée/détruit un nouvel employé (informatiquement parlant;))? Apriori côté RH puisqu'on ne paiera pas sinon.
Dans ce cas, P n'a besoin que d'une copie (first, last) names. P pourra y accrocher d'autres informations.

Dans le cas présent, il me semble illusoire de construire une seule application puisqu'il y en a déjà deux... Mais une des conséquence de ce qui précède est:
"les employés ne sont crées que par l'application qui sait créer le 'DOB'."
- W

---

Peut etre est-ce la que l'erreur a été faite des le départ, car l'employée peut etre crée dans les deux applications comme expliqué précedemment.
Il est difficile de savoir qui doit créer l'employé, car du cotée RH l'employee a besoin de la date de naissance, et du cote paie il a besoin du numéro de paie.
Mais je concoit bien qu'il semble plus logique que l'application RH crée l'employé.

Bonjour,

je pense que tu fais fasse à un souci d'extensibilité.
Je ne parlerai pas d'intégration UI pour l'instant ( par exemple présence de champs supplémentaires, panels supplémentaires, etc etc ).

Ce changement d'algorithme de validation en fonction de la présence ou non du module d'intégration m'a induit les mots suivants: design pattern strategie.
Au lieu de maintenir dans ton code ces if-else, tu définis une interface du style

Code:

---

1 2 3

public interface EmployeeValidator { void validateEmployee(Employee emp) throws Exception; }

---

Partant de ce point d'extension possible, tu aurais alors plusieurs implémentations:

• Standalone, qui traite des validations de l'objet dans ce cas de déploiement
  
  Code:

  ---

  1 2 3 4 5

  public class StandaloneEmployeeValidator implements EmployeeValidator { public void validateEmployee(Employee emp) throws Exception { Validate.notNull(emp.getDateDeNaissance()); } }

  ---

• Module Intégré Paie, où on prend en compte le modèle augmenté.
  
  
  Code:

  ---

  1 2 3 4 5

  public class IntegratedPayrollEmployeeValidator implements EmployeeValidator { public void validateEmployee(Employee emp) throws Exception { Validate.notNull(emp.getNumeroPaie()); } }

  ---

Bon, c'est une idée de mise en oeuvre. On pourrait mettre en place la sélection de ces implémentations par une Factory qui s'appuierait sur la présence ou non du module intégré.
On peut aussi faire en sorte de garder l'entité Employee propre à l'application standalone, et trouver un moyen de laisser le module d'intégration fournir une sous-classe d'Employee qui rajouterait ces champs d'intégration ( ou faire un mapping Employee <-> IntegratedPayrollEmployee ) qui serait utilisé par le Validator précédemment présenté.

Bref, il te faut prévoir des "points d'extensions", et c'est le module d'intégration qui viendrait se greffer là où il doit augmenter le système.

Qu'en penses-tu?

Sébastien

Salut,

Pour l'instant nous avons des évènements tels que création, suppression, changement d'état,... de par exemple un employé dans différents sous systèmes à propager dans un nombre indéfini d'autres sous-système.

Côté pattern de réalisation publish-suscribe ou Observer plus GoF sont très bien et des solutions générales à ces problèmes sont plutôt côté EAI, ESB ou MDM.
Peut-on faire plus simple? Oui mais pas sans avoir mis un peu à plat les évènements, les entités, les règles de gestion, l'évolutivité,....
- W