2011-01-13 4 views
0

J'ai un workflow démarré et persistant à l'aide des activités de messagerie. La corrélation entre la commande Start start et la commande Stop final fonctionne bien si elles sont envoyées en quelques secondes. Les problèmes commencent lorsque le flux de travail est déchargé, car le message suivant arrêt lance la FaultException suivante:Erreur lors du chargement d'un flux de travail persistant

Si LoadWorkflowByInstanceKeyCommand.AssociateLookupKeyToInstanceId n'est pas spécifié, le LookupInstanceKey doit déjà être associé à une instance, ou LoadWorkflowByInstanceKeyCommand échouera. Pour cette raison, il est invalide de spécifier également LookupInstanceKey dans la collection InstanceKeysToAssociate si AssociateLookupKeyToInstanceId n'est pas défini

Quelqu'un peut-il m'aider? Les variables à l'intérieur du workflow sont de type int et XDocument. Ceci est le code pour initialiser le WorkflowServiceHost:

WorkflowServiceHost serviceHost = new WorkflowServiceHost(myWorkflow, new Uri(serviceUri)); 
      ServiceDebugBehavior debug = serviceHost.Description.Behaviors.Find<ServiceDebugBehavior>(); 
      if (debug == null) 
      { 
       debug = new ServiceDebugBehavior(); 
       serviceHost.Description.Behaviors.Add(debug); 
      } 

      debug.IncludeExceptionDetailInFaults = true; 
      WorkflowIdleBehavior idle = serviceHost.Description.Behaviors.Find<WorkflowIdleBehavior>(); 
      if (idle == null) 
      { 
       idle = new WorkflowIdleBehavior(); 
       serviceHost.Description.Behaviors.Add(idle); 
      } 

      idle.TimeToPersist = TimeSpan.FromSeconds(2); 
      idle.TimeToUnload = TimeSpan.FromSeconds(10); 
      var behavior = new SqlWorkflowInstanceStoreBehavior 
      { 
       ConnectionString = ConfigurationManager.ConnectionStrings["WorkflowPersistence"].ConnectionString, 
       InstanceEncodingOption = InstanceEncodingOption.None, 
       InstanceCompletionAction = InstanceCompletionAction.DeleteAll, 
       InstanceLockedExceptionAction = InstanceLockedExceptionAction.BasicRetry, 
       HostLockRenewalPeriod = new TimeSpan(00, 00, 30), 
       RunnableInstancesDetectionPeriod = new TimeSpan(00, 00, 05) 
      }; 
      serviceHost.Description.Behaviors.Add(behavior); 
      serviceHost.Open(); 

regardant la base de données, il semble que le flux de travail est jamais suspendu.

Toute aide appréciée, merci

Répondre

0

Pas vraiment sûr de ce qui se passe ici, mais ça sonne comme il y a des types utilisés dans le flux de travail qui ne peut pas être sérialisés et empêcher le flux de travail d'être stockés sur le disque. Lorsque vous dites "En regardant la base de données, il semble que le flux de travail n'est jamais suspendu." Voulez-vous vraiment dire suspendu? Et pourquoi vous attendez-vous à ce que le workflow soit suspendu?

Que se passe si vous envoyez simplement le message de démarrage du flux de travail et attendre 2 secondes? Avez-vous un nouvel enregistrement dans la base de données de persistance?

+0

Pour suspendu, je veux dire qu'il va à la table RunnableInstancesTable et la valeur IsSuspended est réglée sur 1 dans le tableau InstancesTable. Le workflow peut être sérialisé car si j'ajoute un délai, il est correctement suspendu. Le problème est qu'après le WorkflowIdleBehavior.TimeToUnload écoulé, le flux de travail n'est pas suspendu et un appel à l'opération Stop renvoie l'erreur mentionnée. L'erreur n'est pas levée si j'envoie l'opération Stop avant le délai TimeToUnload. C'est un workflow de longue durée. – fra

+0

J'ai réalisé que j'ai fait une erreur dans la définition du flux de travail, en répétant l'initialisation de la corrélation dans l'activité Arrêter la réception. De toute façon, j'apprécierais une explication de la raison pour laquelle le workflow inactif n'est pas dans le runnableinstancestable ... est-il quand même sérialisé dans la base de données et déchargé de la mémoire? Quelle politique est utilisée? – fra

+0

Un workflow persistant est stocké dans la table InstancesTable, RunnableInstancesTable est utilisé dans la récupération des workflows et non lorsque tout fonctionne correctement. Normalement, lorsqu'un flux de travail est conservé, il n'est pas suspendu, la suspension est le résultat d'une erreur lorsque la stratégie est définie sur AbandonAndSuspend. Cela signifie que le flux de travail ne reprendra pas automatiquement mais doit être repris manuellement. – Maurice

Questions connexes