Informationen zum Batchverarbeitungszustand in Workflows

Artikel
12/17/2007

Der Workflow speichert seinen Zustand regelmäßig an verschiedenen Prüfpunkten (so genannten Persistenzpunkten) im permanenten Speicher. Bei einem Fehler im Workflow muss das Laufzeitmodul ggf. diese beibehaltenen Informationen abrufen, um einen stabilen Zustand wiederherzustellen. Wenn mindestens zwei Komponenten kommunizieren, ist es häufig hilfreich, die Persistenz zu koordinieren, damit die Zustände der Komponenten konsistent sind. Arbeitsbatches werden von workflowexternen Diensten verwendet, um Zustandsinformationen beizubehalten. Diese Dienste stapeln ihre Arbeitsaufgaben und geben dieselbe Transaktion wie die des Workflows frei. Wird vom Workflow kein Commit der Transaktion durchgeführt, können die Dienste während der Persistenzpunkte noch einige Arbeitsaufgaben stapeln.

Windows Workflow Foundation stellt IWorkBatch und IPendingWork zur Verfügung, um Dienste und Workflowinstanzen bei der Beibehaltung von Zustandsinformationen zu unterstützen.

In allen Aufrufen an die vom Workflow initiierten Dienste stellt das Laufzeitmodul in seinem Threadaufrufkontext einen IWorkBatch bereit. Mit dem Dienst kann diesem Arbeitsbatch eine ausstehende Arbeitsaufgabe hinzugefügt werden, damit das Laufzeitmodul alle verwandten Arbeitsaufgaben in einer einzelnen Transaktion übertragen kann. Verwenden Sie folgende Anweisung, um dem Batch eine Arbeitsaufgabe hinzuzufügen oder diese im Batch zu registrieren:

WorkflowEnvironment.WorkBatch.Add(IPendingWork work, object workItem);

Außerdem können Sie dem Konstruktor IPendingWork für ExternalDataEventArgs übergeben.

Abfolge der Aktionen beim Aufruf einer Komponente

Während der Initialisierung erstellt der Workflow einen Arbeitsbatch.
Der Workflow fügt den Arbeitsbatch an den Aufruf einer Methode auf einer Komponente an. Dienste können mithilfe der WorkflowEnvironment-Klasse auf den Arbeitsbatch in einer beliebigen Methode zugreifen.

Handlungsabfolge am Commitpunkt

Der Workflow erstellt eine Transaktion.
Der Workflow durchläuft den Arbeitsbatch und listet unter Beibehaltung der Reihenfolge alle Arbeitsaufgaben für eine Komponente auf, um einen Arbeitsbatch zu erstellen. Der Workflow ruft die Commit-Methode auf der Komponente auf und übergibt die Transaktion und den Arbeitsbatch.
Die Komponente fügt die Arbeit im Arbeitsbatch der Transaktion hinzu.
Die Schritte 2 und 3 werden für alle Komponenten mit Arbeitsaufgaben in Arbeitsbatches wiederholt.
Wenn die Commit-Benachrichtigungen erfolgreich sind, führt der Workflow einen Commit der entsprechende Transaktion aus.
Bei einem erfolgreichen Commit einer Transaktion durchläuft der Workflow den Arbeitsbatch und listet alle Arbeitsaufgaben pro Komponente auf (siehe Schritt 2). Der Workflow ruft die Complete-Methode für jede Komponente auf und übergibt die entsprechende Transaktion und den Arbeitsbatch.

Handlungsabfolge bei einem Workflowfehler

Der Workflow identifiziert alle auf den fehlerhaften Bereich bezogenen Arbeitsaufgaben und erstellt einen Arbeitsbatch.
Der Workflow ruft die Complete-Methode jeder eindeutigen IPendingWork auf, wobei der Abschlussstatus für die gesamte Arbeit im Arbeitsbatch auf false gesetzt wird.
Der Workflow verwirft die gesamte Arbeit im Arbeitsbatch, sofern es sich dabei um einen Arbeitsbatch handelt, der zu einem untergeordneten Kontext einer TransactionScopeActivity-Aktivität oder einer CompensatingTransactionScopeActivity-Aktivität gehört.
Die Laufzeit behält nach der Wiederherstellung in Folge des Fehlers einen Verweis auf alle verbleibenden Arbeitsbatchaufgaben bei. Für diese Arbeit wird möglicherweise an einem zukünftigen Persistenzpunkt ein Commit ausgeführt.

Wiederholen von Arbeitsbatchtransaktionen

DefaultWorkflowCommitWorkBatchService, SharedConnectionWorkflowCommitWorkBatchService, SqlWorkflowPersistenceService und SqlTrackingService sind jeweils in der Lage, Arbeitsbatchcommits zu wiederholen. Diese mithilfe der EnableRetries-Eigenschaft aktivierte Funktion ermöglicht diesen Diensten bei Netzwerktimeouts, Neustarts des Computers, Zurücksetzen von SQL Server-Prozessen usw., weiterhin die Ausführung eines Commits für einen Arbeitsbatch zu versuchen.

Die Anzahl der Wiederholungen wird auf 20 festgelegt. Die ersten drei Wiederholungen werden unmittelbar nacheinander durchgeführt. Danach tritt zwischen jeder darauffolgenden Wiederholung eine Verzögerung auf. Anwendungen können das Verbindungstimeout in ihrer Verbindungszeichenfolge anpassen, um die Zeit zwischen Wiederholungen teilweise einzustellen.

Diese Eigenschaft kann programmgesteuert oder mithilfe einer Konfigurationsdatei festgelegt werden. Weitere Informationen zum programmgesteuerten Festlegen der Eigenschaft finden Sie in der EnableRetries-Eigenschaft jedes Diensts. Weitere Informationen zum Festlegen der Eigenschaft mithilfe einer Konfigurationsdatei finden Sie unter Workflow Configuration Files.