Que pensez vous de cette architecture de workflow customisée ?
A votre avis, est il viable dans le contexte d'un petit service (2 devs 1 cp), de vouloir développer sois même une plateforme custom de gestion de workflows ? Les demandes que l'on nous fait contiennent pas mal de règles de gestions inattendues.
Pour des raisons diverses, dont une tentative infructueuse sur MS WF, nous avons mis en œuvre une telle solution dans mon service.
L'archi est à peu près la suivante :
Tous les wkf, (aussi appelés composants) et le wkf principale lui même héritent d'une classe abstraite qui gère différentes choses dont : les erreurs, les logs et le passage de paramètres de composant à composant lorsqu'ils sont imbriqués.
Chaque composant hérite d'un membre de type
Code:
Dictionary<string, T>
qui sert à stocker ses propres paramètres mais aussi à recevoir les valeurs issues du wkf parent (issues du Dictionnary<> du wkf parent).
Chaque composant est accompagné d'un fichier de configuration XML contenant la définition des paramètres.
Chaque composant n'expose qu'une seule méthode, , (le point d'entrée du composant).
Lors de l'exécution du wkf principal, le Dictionnary du wkf principal s'enrichit des valeurs retrournés par les wkf enfants.
Nous codons pas mal en copié collé ( ... ), il n'y a pas d'interface graphique comme dans un produit type WF ou jBPM. Entre deux composant on s'interdit donc l'appel de méthodes autres que Execute(){...} et la seule manière de transmettre la valeur des paramètre se fait via le membre Dictionnary<>. A dire vrai on est à des lieux de nos bons vieux concepts de POO.
Hormis les aspects graphiques et des choses poussés comme l'arret et la reprise d'un traitement sur des longues durées. Que pensez vous de cette archi ? Diffère t elle pas, peu ou beaucoup d'une archi WF ou jBPM ?
Merci beaucoup pour vos lumières.
Antoine.
