WF Essentials – Persistenz von Workflows – Teil 1
Dies ist der erste Teil eines mehrteiligen Artikels zu den Persistenz Mechanismen in der Windows Workflow Foundation.
Zu Beginn werden mal die Workflow Persistenz Grundlagen beleuchtet. Später geht’s dann um den Einsatz des Persistenz Services in Workflow Services und in einer Server Farm.
Die Windows Workflow Foundation stellt für die Persistenz von Workflow Instanzen den Core Dienst SqlWorkflowPersistenceService zur Verfügung. Dieser benötigt einen SQL Server, andere Datenbanken werden nicht unterstützt. Es ist allerdings möglich, einen eigenen Persistenz Dienst zu schreiben, dazu aber später mehr.
Wenn die WorkflowRuntime so konfiguriert wird, dass sie den SqlWorkflowPersistenceService verwenden soll, wird der aktuelle Status der Workflow Instanzen, welche sich gerade im Wartezustand befinden, in der Datenbank persistiert.
Wann genau wird nun eine Workflow Instanz persisitiert?
- Wenn sich eine Workflow Instanz sich im “Idle” Zustand befindet. Dies ist dann der Fall, wenn sie auf einen externen Event warten muss, oder eine DelayActivity ausgeführt wird.
- Wenn eine Workflow Instanz beendet oder terminiert wird.
- Wenn innerhalb des Ablaufs eine TransactionScopeActivity oder eine CompensatableTransactionScopeActivity beendet wird.
- Wenn eine benutzerdefinierte Aktivität beendet wird, die mit dem PersistOnClose Attribut dekoriert wird.
- oder natürlich wenn die Unload() Methode (oder auch TryUnload) der Workflow Instanz aufgerufen wird.
Die Persistierung kann nebst dem Umstand, dass die Workflow Instanzen einen Neustart des Workflow Hosts überleben, die Skalierbarkeit einer einzelnen WorkflowRuntime erhöhen, da nicht benötigte Workflow Instanzen aus dem Speicher entfernt werden.
Der SqlWorkflowPersistenceService kann via Applikations Konfigurationsfile oder via Code eingesetzt werden.
Im Konfigurationsfile
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<configSections>
<section name="WorkflowRuntimeConfiguration"
type="System.Workflow.Runtime.Configuration.WorkflowRuntimeSection, System.Workflow.Runtime, Version=3.0.00000.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
</configSections>
<WorkflowRuntimeConfiguration>
<CommonParameters>
<add name="ConnectionString"
value="Data Source=localhost;Initial Catalog=WFStore;User=wf;Password=wf;" />
</CommonParameters>
<Services>
<add type="System.Workflow.Runtime.Hosting.SqlWorkflowPersistenceService, System.Workflow.Runtime, Version=3.0.00000.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
UnloadOnIdle="true" />
</Services>
</WorkflowRuntimeConfiguration>
</configuration>
Im Code
// Adjust the connection string according to your environment.
var connectionString = "Data Source=localhost;Initial Catalog=WFStore;User=wf;Password=wf;";
// When true, the service will persist idle workflows. The service default value is false.
bool unloadOnIdle = true;
// Specifies for how long the service will lock the instance record in the database.
// The service default value is TimeSpan.MaxValue.
TimeSpan instanceOwnershipDuration = new TimeSpan(0, 2, 0);
// The service will check for expired timers in the database this often.
// The service default value is 2 minutes
TimeSpan loadingInterval = new TimeSpan(0, 0, 5);
var persistenceService = new SqlWorkflowPersistenceService(connectionString,
unloadOnIdle,
instanceOwnershipDuration,
loadingInterval);
workflowRuntime.AddService(persistenceService);
Das angehängte Beispiel Projekt für Visual Studio 2008 zeigt diese beiden Varianten. Sie benötigen zusätzlich zum Beispielprojekt eine SQL Server Datenbank. Eine SQL Server Express Installation auf dem Entwicklungsrechner reicht dabei völlig aus.
Die SQL Skripte für das Anlegen des DB Schemas und der benötigten Stored Procedures findet man unter
C:\Windows\Microsoft.NET\Framework\v3.0\Windows Workflow Foundation\SQL\EN
Beispiel Projekt: WorkflowPersistence.zip