2009-06-11 7 views
2

J'ai un flux de travail qui va regarder certaines bases de données et lancer d'autres flux de travail lorsqu'il remarque un déclencheur. Je veux seulement qu'une instance de ce flux de travail "observateur" se déroule à n'importe quel moment; Dans le cas contraire, si deux ou plusieurs s'exécutaient, ils remarqueraient tous les deux le changement et tous deux déclencheraient le même flux de travail, ce qui ne fonctionnerait pas bien.Windows Workflow: flux de travail «singleton»?

Ce flux de travail "observateur" est conservé. Alors ... comment faire pour que si l'exécution n'a pas encore une instance de ce flux de travail persistante, elle en démarre une, mais si l'une d'entre elles est déjà là, utilisez simplement celle qui a persisté? On dirait presque que je pourrais créer une petite application de console qui lancerait le flux de travail que je voulais, puis le "vrai" runtime a juste tiré sur celui qui a persisté et n'essaye jamais d'en créer un nouveau, mais ça ne marche pas t son très élégant.

Répondre

1

Nous avons eu ce problème dans un projet il y a un certain temps. La solution que nous avons trouvée était d'héberger deux runtimes; un avec des services de persistance et un sans. Dans le runtime sans service de persistance, nous étions en train d'exécuter deux types de "workflows de surveillance" qui étaient automatiquement démarrés lorsque l'hôte était démarré.

Voici comment il a été mis en œuvre:

Tout d'abord, nous avons eu un fichier de configuration dans laquelle nous avons créé le service de persistance:

<configuration> 
    <configSections> 
     <section name="RuntimeWithPersistence" type="System.Workflow.Runtime.Configuration.WorkflowRuntimeSection, System.Workflow.Runtime, Version=3.0.00000.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/> 
    </configSections> 
    <RuntimeWithPersistence> 
     <CommonParameters/> 
     <Services> 
      <add type="System.Workflow.Runtime.Hosting.DefaultWorkflowSchedulerService, System.Workflow.Runtime, Version=3.0.00000.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/> 
      <add type="System.Workflow.Runtime.Hosting.SqlWorkflowPersistenceService, System.Workflow.Runtime, Version=3.0.00000.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" connectionString="[dbconnectionstring]" UnloadOnIdle="true"/> 
     </Services> 
    </RuntimeWithPersistence> 
</configuration>  

Et dans l'application hôte de workflow (coupé et édité, mais Je pense que je communique l'idée):

public class WorkflowHost 
{ 
    private WorkflowRuntime _runtime = null; 
    private WorkflowRuntime _nonPersistingRuntime = null; 

    private void SetupRuntime() 
    { 
     // create a new WorkflowRuntime that points out a config section 
     // defining a persistence service 
     _runtime = new WorkflowRuntime("RuntimeWithPersistence"); 
     // set up additional services to use 
     _runtime.StartRuntime() 

     // create a new WorkflowRuntime that does not point out a config section 
     _nonPersistingRuntime = new WorkflowRuntime(); 
     // set up additional services to use 
     _nonPersistingRuntime.StartRuntime() 
     // start monitoring workflows in the non persisting runtime 
     StartMonitoringWorkflows(_nonPersistingRuntime); 
    } 
} 
+0

Merci pour les commentaires! J'ai commencé à suivre cette approche, mais j'essaie de trouver une solution élégante à un autre problème: le monitoring doit savoir qui "déclenche" le tir avant, donc il ne le fera pas la prochaine fois il le voit. C'est pourquoi je pensais utiliser la persistance avec la surveillance, donc il peut stocker une liste de déclencheurs pour ignorer que cela a déjà été fait. J'aime bien l'idée et je l'étudierai plus en détail. – Chris

+0

Nous étions dans le même genre de réflexion, mais nous avons trouvé une manière simple et fiable de déterminer si le runtime avait déjà une instance persistante du workflow ou non (il se peut qu'il y ait, nous étions relativement débutants dans le monde du workflow, et Je n'ai pas enquêté plus loin depuis lors ...) –

2

J'envisage ce problème aussi bien pour un projet sur lequel je travaille actuellement. Cependant, il me semble que la fonction de surveillance de la base de données n'est pas la responsabilité du flux de travail.

Nous allons créer un service à ajouter à l'exécution. Ce service déclenche les événements que le flux de travail écoute dans HandleEventActivity. De cette façon, le flux de travail devient inactif, persiste et reste ainsi jusqu'à ce qu'un vrai travail ait réellement besoin d'être fait.

Questions connexes