Publicité
+ Répondre à la discussion
Affichage des résultats 1 à 2 sur 2
  1. #1
    Nouveau Membre du Club
    Inscrit en
    février 2007
    Messages
    121
    Détails du profil
    Informations forums :
    Inscription : février 2007
    Messages : 121
    Points : 34
    Points
    34

    Par défaut 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 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.

  2. #2
    CUCARACHA
    Invité(e)

    Par défaut

    C'est quasiment l'archi que j'ai mis en place pour une grosse plateforme de gestion de contenus media.

    La différence est que j'utilisais K2 Comme moteur BPM et que ce que tu appelles des composants étaient des Webservice WCF ou SOAP.

    Le SI comptait un certain nombre d'outils qui avaient tous la même signature.

    appel
    string requestXML

    Bool result
    string resultsetXML
    string resultManifestXML

    Ca permet de désolidariser les flux des traitements.

    Par contre j'ai du créer une sorte d'ETL pour fabriquer les requestXML.

    J'ajoute que l'immense avantage de cette solution est la reprise sur incident puisqu'il suffit de stocker chaque fichier requestXML en base ou sur disque pour pouvoir reprendre un traitement à n'importe quelle étape.

    Donc (pour ma part) je valide

    ++

    Laurent
    P.S. le projet est maintenant en prod, il permet de gérer environ 100 Transcodeurs video pour diffuser la télévision sur les box, IPHone, Youtube etc. et permettre la vidéo on demand 2 à 3 heures après la diffusion mais mon client s'engage à la fournir en 5 H. Le transcodage d'un fichier vidéo au format pro, c'est 250 Go à transcoder.

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •