Discussion :

[ganga]

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.

[wiztricks]

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

[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?

Sébastien

[ganga]

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.

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?

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

[wiztricks]

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.

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

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

[Desboys]

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