Discussion :

[TekP@f]

Salut,

J'ai besoin de mettre en place un moteur de workflow générique contenant des traitements différents selon nos clients. Le but est d'avoir une application générique avec le moins de mise à jour possible et de traiter le spécifique dans une application tierce. Ainsi, la maintenance s'occupera uniquement de l'application tierce et pas du tout du moteur de workflow.

Ma réflexion est la suivante :
1. création d'un moteur de workflow standard
2. dans la définition des cycles de vie, on place des actions spécifiques pour chaque client
3. le moteur de workflow transmet ces actions à un gestionnaire de tâches (c'est l'application tierce citée plus haut)
4. le gestionnaire de tâches lits l'action, l'interprète et l'exécute

Je pense que ce système est bon, j'ai juste un souci d'implémentation. J'ai mis en place le moteur de workflow avec les actions, je me pose des questions sur le gestionnaire de tâches : comment faire communiquer le gestionnaire avec le moteur ? comment passer les actions à traiter ? comment interpréter les actions ?

Mon idée :
- le gestionnaire de tâches contient 1 premier thread qui lit en boucle une file d'attente de traitements
- le gestionnaire ouvre ensuite un socket pour communiquer avec le moteur de workflow
- pour transmettre ses actions, le moteur ouvre une connexion au gestionnaire via la socket, transmet une String équivalent à l'action à traiter
- le gestionnaire récupère la connexion, lance un second socket qui se charge d'ajouter l'action dans la file d'attente
- le thread de file d'attente lit l'action, inteprète le String et l'exécute. Le String serait un truc du genre "com.client.EnvoiMail".

Ca fait pas trop usine à gaz mon truc ? Mais en même temps, je ne vois pas d'autres solutions.
Je peux avoir qq avis ?

Merci bien.

[CyberChouan]

Une question : pourquoi avoir réinventé la roue alors qu'il existe déjà des moteurs de workflow Java (dont certains sont gratuits), qui proposent une API d'utilisation (ce que tu veux redévelopper) ?

Pour n'en citer que deux :
- Intalio
- jBPM

[TekP@f]

Vu ta réponse, j'ai dû mal m'exprimer ...

Je ne veux pas réinventer la roue (surtout une roue aussi compliquée que le workflow avec jante alu et tout et tout ). Quand je disais "création d'un moteur de workflow", je voulais dire "installation de jBPM". Ce que j'ai d'ailleurs fait ce matin.

C'est la partie Gestionnaire de tâches qui me pose certains problèmes. Je souhaite la dissocier du moteur de workflow pour des raisons de maintenance. C'est un peu comme si je voulais extraire la couche métier du moteur de workflow.

Un exemple sera plus parlant :
- t'as un client 1 qui souhaite faire un envoi de mail lors de l'exécution d'une tâche.
- t'as un client 2 qui souhaite faire une génération de PDF lors de l'exécution d'une tâche
- tu sais que tu vas avoir des tonnes de clients avec chacun ses petites envies et son process particulier.

Plutôt que de tout faire dans un projet et de devoir le maintenir, je souhaite utiliser jBPM et externaliser les actions dans un Gestionnaire de tâches afin de maintenir uniquement le gestionnaire.
Dans mon exemple, tu aurais pour chaque client une définition de workflow. Et dans le gestionnaire de tâches, 2 tâches : envoi de mail, génération de pdf. Ensuite, il faut juste permettre au moteur de workflow de lancer la tâche définie dans le cycle de vie du client.

Je ne connais pas de gestionnaire de tâches. J'ai donné mon idée de conception d'un tel gestionnaire dans mon premier post.

C'est plus clair ?

[TekP@f]

En y repensant, ma conception est trop lourde et contient qq inconvénients.
En production, il m'arrivera de livrer un nouveau gestionnaire de tâches. Quid des tâches dans le pipe ?
Du coup, j'envisage plutôt de stocker les demandes de tâches en base. Comme ça, en cas de redémarrage du gestionnaire, j'ai encore une trace des demandes en cours. Et ça facilite également la communication avec le moteur de workflow. Plus besoin de sockets.