locked
Les Workflow Services RRS feed

  • Question

  • Bonjour à toutes et à tous,

    Le thème de mon stage de fin d'étude étant le WF, j'ai commencé il y a peu à me documenter sur le sujet.

    Après avoir lu "Essential Windows Workflow Foundation" et "Programming Windows Workflow Foundation", j'ai arpenté le web à la recherche d'articles, de webcast et de tutoriaux sur le sujet.

    Depuis lors, j'ai une bien meilleure connaissance de ce qu'est le WF, ce que fait le WorkflowRuntime, que sont les WorkflowInstances, ce qu'ils gèrent, etc...

    La seule grosse partie que je ne comprends pas trop actuellement concerne les Workflow Services.

    J'ai bien compris le roles des Services nécessaires aux Workflow (LoaderService, Scheduler, CommitBatch) , ainsi que ceux fournis par MS (notamment au niveau de la Persistence)

    Par contre, ce que je ne comprends pas trop, c'est :

    - Comment le WorkflowRuntime et les Services interagissent entre eux ?
    - Comment les Activity sont elles capables de accéder aux Services ?
    - Comment savent elles quel Service appeler ?

    Dans un des bouquins que j'ai lu, il était mis qu'un Service pouvait être "n'importe quel objet CLR" , comment ceci est il possible ?


    Par avance merci pour toutes les éclaircissements que vous pourriez m'apporter :-)

    Pierre Martin.
    Student at Level-it.
    www.level-it.be


    vendredi 14 mars 2008 15:02

Réponses

  • Hehe, j'avais postulé pour ce stage mais finalement j me trouve en Suisse, à faire des workflows également.

    Dans ta question, je suppose que tu parles des ExternalDataExchangeService ? Les activités doivent être indépendantes des autres services. Elles peuvent néanmoins utiliser le tracking.

    Les services d'échange de donnée intéragissent plutôt avec une instance de workflow qu'avec le workflow runtime.

    Tu enregistres tes services au près du workflow runtime et tu peux plus tard retrouver tes services à partir du workflowruntime (via la methode GetService()). Pour les ExternalDataExchangeService, tu ajoutes au runtime un ExternalDataExchangeService et ajoute à celui-ci les différents services d'échange de données que tu comptes utiliser.

    Pour communiquer avec les services d'échange de données, tu dois utiliser les activités CallExternalMethod (le workflow appelles une methode du service) et HandleExternalEventActivity (le workflow se met en attente d'un évenement qui sera déclanché par le service). Pour configurer ces activités, il faut leur préciser le service utilisé ainsi que la méthode ou évenement.

    Un service est défini grâce à une interface décorée de l'attribut [ExternalDataExchange]. Un service peut donc en effet être n'importe quel object CLR SI il implémente l'interface du service.


    lundi 17 mars 2008 10:42
  • Premièrement, merci à Benoît pour ses réponses et son aide plus que précieuse

    Après quelques échanges de courrier, j'ai enfin compris de quoi il en retournait, au niveau des Workflow Services.

    Première chose qui n'était pas clair à mes yeux, c'était la définition de ce qu'était un Workflow Service.

    Il faut savoir qu'il y a trois catégories de Workflow Services.

    - Ceux contenus dans le namespace System.Workflow.Runtime.Hosting.

    - WorkflowLoaderService
    - WorkflowSchedulerService
    - WorkflowCommitWorkBatchService
    - WorkflowPersistenceService

    - Ceux contenus dans le namespace System.Workflow.Runtime.Tracking. ( SqlTrackingservice, de base )
    - Et enfin, les Services d'échange de données externes (traduit littéralement de l'anglais), ceux que nous développerons.


    A savoir qu'en ce qui concerne le
    WorkflowRuntime, il est obligatoire qu'un et un seul service dérivant de ces trois classes abstraites ( WorkflowLoaderService, WorkflowSchedulerService et WorkflowCommitWorkBatchService ) soit présent, si non le  Workflow runtime ne peut fonctionner.

    Par contre, pour ce qui est du Service de Persistence, des Services de Tracking ou des Services d'échange de données externes, ils sont optionnels.


    Donc, ma première question était la suivante :

    - Comment le WorkflowRuntime et les Services interagissent entre eux ?


    Pour cette question, la réponse de Benoît convient parfaitement :

    " Tu enregistres tes services au près du workflow runtime et tu peux plus tard retrouver tes services à partir du workflowruntime (via la methode GetService()). Pour les ExternalDataExchangeService, tu ajoutes au runtime un ExternalDataExchangeService et ajoute à celui-ci les différents services d'échange de données que tu comptes utiliser. "

    Ce qui donne au niveau du code :

    protected override ActivityExecutionStatus Execute( ActivityExecutionContext context)
    {
    WriterService writer = context.GetService<WriterService>();
    writer.Write(Text);

    return ActivityExecutionStatus.Closed;
    }


    Extrait de code qui répond à ma deuxième question :

    - Comment les Activity sont elles capables de accéder aux Services ?

    Pour les Activity, l'accès aux workflow services se fait par le biais de l'ActivityExecutionContext, qui implémente l'interface IServiceProvider.

    Et enfin, ma dernière question :

    - Comment savent elles quel Service appeler ?

    Ce que je n'avais pas compris, c'était que pour devenir un service, il fallait qu'une classe implémente une interface taguée avec l'attribut [ExternalDataExchange], une fois cette précision faite, il est plus aisé de comprendre comment l'Activity sait quel Service appeler pour une méthode donnée.

    En fait, au niveau du Workflow Runtime, qui est un container à Services, on ne peut avoir qu'un seul
    Services d'échange de données externes pour un contrat donné. ( Si on tente d'ajouter deux services qui utilisent un même contrat, une exception "InvalidOperationException" sera levée lors de la tentative d'ajout du deuxième service )

    Lorsque l'Activity a besoin d'appeler une méthode d'un Service, il ne pourra donc pas y avoir d'ambiguité, vu qu'il n'y aura au niveau des Services enregistrés dans le Runtime, qu'un seul Service du type demandé.

    Ce que ça donne au niveau du code, pour ceux qui comprennent plus aisément de cette façon ;-)

    Le contrat (IGUI.cs) :

    [ExternalDataExchange]
    public interface IGUI
    {
        void ChargementEmploye(Fiche F);
        void ChargementChef(Fiche F);
    }


    Deux classes SIConsole et SIConsole2 qui implémentent l'interface IGUI.


    Et au niveau du code ou on lance le WorkflowRuntime :

    public static SIConsole consoleImpl = new SIConsole();
    public static SIConsole2 consoleImpl2 = new SIConsole2();

    ExternalDataExchangeService edes;
    edes = new ExternalDataExchangeService();
    workflowRuntime.AddService(edes);

    workflowRuntime.AddService(_console);

    edes.AddService(consoleImpl);
    //edes.AddService(consoleImpl2);

    Et lorsque l'on décommente la dernière ligne, au moment de la compilation, il n'y a pas de problème, par contre au moment ou l'on lance notre application et que l'on tente d'ajouter notre 2e service...


    (url) Une exception est levée...



    Voila, voila,

    J'espere que ce post aura pu aider d'autres néophytes dans l'utilisation du WF ;-)

    P. Martin

    mardi 18 mars 2008 14:31

Toutes les réponses

  • Hehe, j'avais postulé pour ce stage mais finalement j me trouve en Suisse, à faire des workflows également.

    Dans ta question, je suppose que tu parles des ExternalDataExchangeService ? Les activités doivent être indépendantes des autres services. Elles peuvent néanmoins utiliser le tracking.

    Les services d'échange de donnée intéragissent plutôt avec une instance de workflow qu'avec le workflow runtime.

    Tu enregistres tes services au près du workflow runtime et tu peux plus tard retrouver tes services à partir du workflowruntime (via la methode GetService()). Pour les ExternalDataExchangeService, tu ajoutes au runtime un ExternalDataExchangeService et ajoute à celui-ci les différents services d'échange de données que tu comptes utiliser.

    Pour communiquer avec les services d'échange de données, tu dois utiliser les activités CallExternalMethod (le workflow appelles une methode du service) et HandleExternalEventActivity (le workflow se met en attente d'un évenement qui sera déclanché par le service). Pour configurer ces activités, il faut leur préciser le service utilisé ainsi que la méthode ou évenement.

    Un service est défini grâce à une interface décorée de l'attribut [ExternalDataExchange]. Un service peut donc en effet être n'importe quel object CLR SI il implémente l'interface du service.


    lundi 17 mars 2008 10:42
  • Premièrement, merci à Benoît pour ses réponses et son aide plus que précieuse

    Après quelques échanges de courrier, j'ai enfin compris de quoi il en retournait, au niveau des Workflow Services.

    Première chose qui n'était pas clair à mes yeux, c'était la définition de ce qu'était un Workflow Service.

    Il faut savoir qu'il y a trois catégories de Workflow Services.

    - Ceux contenus dans le namespace System.Workflow.Runtime.Hosting.

    - WorkflowLoaderService
    - WorkflowSchedulerService
    - WorkflowCommitWorkBatchService
    - WorkflowPersistenceService

    - Ceux contenus dans le namespace System.Workflow.Runtime.Tracking. ( SqlTrackingservice, de base )
    - Et enfin, les Services d'échange de données externes (traduit littéralement de l'anglais), ceux que nous développerons.


    A savoir qu'en ce qui concerne le
    WorkflowRuntime, il est obligatoire qu'un et un seul service dérivant de ces trois classes abstraites ( WorkflowLoaderService, WorkflowSchedulerService et WorkflowCommitWorkBatchService ) soit présent, si non le  Workflow runtime ne peut fonctionner.

    Par contre, pour ce qui est du Service de Persistence, des Services de Tracking ou des Services d'échange de données externes, ils sont optionnels.


    Donc, ma première question était la suivante :

    - Comment le WorkflowRuntime et les Services interagissent entre eux ?


    Pour cette question, la réponse de Benoît convient parfaitement :

    " Tu enregistres tes services au près du workflow runtime et tu peux plus tard retrouver tes services à partir du workflowruntime (via la methode GetService()). Pour les ExternalDataExchangeService, tu ajoutes au runtime un ExternalDataExchangeService et ajoute à celui-ci les différents services d'échange de données que tu comptes utiliser. "

    Ce qui donne au niveau du code :

    protected override ActivityExecutionStatus Execute( ActivityExecutionContext context)
    {
    WriterService writer = context.GetService<WriterService>();
    writer.Write(Text);

    return ActivityExecutionStatus.Closed;
    }


    Extrait de code qui répond à ma deuxième question :

    - Comment les Activity sont elles capables de accéder aux Services ?

    Pour les Activity, l'accès aux workflow services se fait par le biais de l'ActivityExecutionContext, qui implémente l'interface IServiceProvider.

    Et enfin, ma dernière question :

    - Comment savent elles quel Service appeler ?

    Ce que je n'avais pas compris, c'était que pour devenir un service, il fallait qu'une classe implémente une interface taguée avec l'attribut [ExternalDataExchange], une fois cette précision faite, il est plus aisé de comprendre comment l'Activity sait quel Service appeler pour une méthode donnée.

    En fait, au niveau du Workflow Runtime, qui est un container à Services, on ne peut avoir qu'un seul
    Services d'échange de données externes pour un contrat donné. ( Si on tente d'ajouter deux services qui utilisent un même contrat, une exception "InvalidOperationException" sera levée lors de la tentative d'ajout du deuxième service )

    Lorsque l'Activity a besoin d'appeler une méthode d'un Service, il ne pourra donc pas y avoir d'ambiguité, vu qu'il n'y aura au niveau des Services enregistrés dans le Runtime, qu'un seul Service du type demandé.

    Ce que ça donne au niveau du code, pour ceux qui comprennent plus aisément de cette façon ;-)

    Le contrat (IGUI.cs) :

    [ExternalDataExchange]
    public interface IGUI
    {
        void ChargementEmploye(Fiche F);
        void ChargementChef(Fiche F);
    }


    Deux classes SIConsole et SIConsole2 qui implémentent l'interface IGUI.


    Et au niveau du code ou on lance le WorkflowRuntime :

    public static SIConsole consoleImpl = new SIConsole();
    public static SIConsole2 consoleImpl2 = new SIConsole2();

    ExternalDataExchangeService edes;
    edes = new ExternalDataExchangeService();
    workflowRuntime.AddService(edes);

    workflowRuntime.AddService(_console);

    edes.AddService(consoleImpl);
    //edes.AddService(consoleImpl2);

    Et lorsque l'on décommente la dernière ligne, au moment de la compilation, il n'y a pas de problème, par contre au moment ou l'on lance notre application et que l'on tente d'ajouter notre 2e service...


    (url) Une exception est levée...



    Voila, voila,

    J'espere que ce post aura pu aider d'autres néophytes dans l'utilisation du WF ;-)

    P. Martin

    mardi 18 mars 2008 14:31