2011-01-13 5 views
0

Ich habe einen Workflow gestartet, der mit Messaging-Aktivitäten gestartet wurde und beibehalten wurde. Die Korrelation zwischen dem Startbefehl Initial und dem Befehl Stop final funktioniert gut, wenn sie innerhalb weniger Sekunden gesendet werden. Probleme beginnen, wenn der Workflow entladen wird, weil die folgende Stop-Meldung die folgende FaultException wirft:Fehler beim Laden eines persistenten Arbeitsablaufs

Wenn LoadWorkflowByInstanceKeyCommand.AssociateLookupKeyToInstanceId nicht angegeben ist, muss die LookupInstanceKey bereits zu einer Instanz in Verbindung gebracht werden, oder die LoadWorkflowByInstanceKeyCommand fehl. Aus diesem Grund ist es ungültig, auch den LookupInstanceKey in der Auflistung InstanceKeysToAssociate anzugeben, wenn AssociateLookupKeyToInstanceId nicht festgelegt ist

Kann mir jemand helfen? Die Variablen im Workflow sind vom Typ int und XDocument. Dies ist der Code den Workflow zu initialisieren:

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(); 

in der Datenbank sucht, so scheint es, dass der Workflow nie ausgesetzt.

Jede Hilfe dankbar, danke

Antwort

0

nicht wirklich sicher, was hier vor sich geht, aber es klingt wie es Arten im Workflow verwendet werden, die nicht serialisiert werden kann und den Workflow verhindern, auf der Festplatte gespeichert werden. Wenn Sie sagen: "Wenn Sie die Datenbank betrachten, scheint der Workflow nie ausgesetzt zu sein." meinst du wirklich suspendiert? Und warum erwarten Sie, dass der Workflow ausgesetzt wird?

Was passiert, wenn Sie nur die Startnachricht an den Workflow senden und 2 Sekunden warten? Erhalten Sie einen neuen Datensatz in der Persistenzdatenbank?

+0

Für suspendiert, ich meine, dass es in der Tabelle RunnableInstancesTable geht, und der Wert IsSuspended wird auf 1 in der Tabelle InstancesTable festgelegt. Der Workflow kann serialisiert werden, denn wenn ich eine Verzögerung hinzufüge, wird sie korrekt aufgehoben. Das Problem besteht darin, dass der Workflow nach dem Ablauf von WorkflowIdleBehavior.TimeToUnload nicht angehalten wurde und ein Aufruf der Stop-Operation den genannten Fehler auslöst. Der Fehler wird nicht ausgelöst, wenn ich den Stop-Vorgang vor dem TimeToUnload-Zeitlimit sende. Es ist ein langer Arbeitsablauf. – fra

+0

Ich erkannte, dass ich einen Fehler in der Workflow-Definition gemacht habe, die Initialisierung der Korrelation in der Stop receive-Aktivität zu wiederholen. Wie auch immer, ich würde mich über eine Erklärung des Grundes freuen, warum der Leerlauf-Arbeitsablauf nicht in der runnable Instancestable ist ... ist es sowieso serialisiert in die Datenbank und aus dem Speicher entladen? Welche Politik wird verwendet? – fra

+0

Ein persistenter Workflow wird in der Tabelle "InstancesTable" gespeichert. Die RunnableInstancesTable wird bei der Wiederherstellung von Workflows verwendet, wenn nicht alles ordnungsgemäß funktioniert. Wenn ein Workflow beibehalten wird, wird er normalerweise nicht ausgesetzt. Das Aussetzen ist das Ergebnis eines Fehlers, wenn die Richtlinie auf AbandonAndSuspend festgelegt ist. Dies bedeutet, dass der Workflow nicht automatisch fortgesetzt wird, sondern manuell fortgesetzt werden muss. – Maurice