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);
}
}
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
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 ...) –