Erweiterte RetryActivity

Dabei werden zwischen zwei Intervall Modi unterschieden:

• Linear (IntervalExponential = false)
  Die Zeitabstände zwischen den einzelnen Intervallen sind gleichmässig, zB. immer 1 Minute.
• Exponentiell (IntervalExponential = true)
  Die Zeitabstände zwischen den einzelnen Intervallen wird immer verdoppelt bis alle Versuche ausgeschöpft sind. Also wird zB. mit einer Sekunde begonnen, und das nächste Intervall dauert zwei Sekunden. Nach 10 Intervall Schritten wird bereits 512 Sekunden gewartet, also etwa achteinhalb Minuten.

Dies kann nützlich sein, wenn zB. ein Aufruf an ein externes System fehlerhaft sein kann, man aber bei vielen parallelen Workflows das externe System nicht durch zahlreiche gleichzeitige Aufrufe belasten will.

Hier ist der der Source Code der erweiterten RetryActivity: RetryActivityEx.zip

Folgende 3 Custom Activities haben sich als unentbehrlich erwiesen und gehören fest in mein WF Toolkit:

CallWorkflow

Die InvokeWorkflowActivity der WF kann zwar auch andere Workflows ausführen, sie macht dies jedoch asynchron. Das bedeutet, sofort nach dem Aufruf kehrt die Ausführung in den aufrufenden  Workflow zurück. Die CallWorkflowActivity mit dazugehörigem Runtime Service des WF Spezialisten Jon Flanders bietet die synchrone Variante an. Die Ausführung im aufrufenden Workflow wartet solange, bis die aufgerufene Workflow Instanz beendet ist.

Retry

Die RetryActivity von Matt Milner kann immer dann verwendet werden, wenn der Aufruf einer Activity fehlschlagen kann (werfen einer Exception), und man dann das ganze noch einmal ausführen lassen will. Es kann eine Anzahl der Wiederholungsversuche und ein Intervall zwischen den Versuchen angegeben werden.

RetryActivity

PersistencePoint

Die letzte Activity ist eine wirklich simple, aber sehr nützliche. Sie kann im Workflow eingesetzt werden, um einen Speicherpunkt im WF Store zu erzwingen auch wenn die WF dies an dieser Stelle nicht von sich aus tun würde. Wenn im Ablauf ein wichtiger Punkt erreicht wurde, kann dies in die Persitenz DB gespeichert werden, und falls der WF unterbrochen wird, fährt die Ausführung beim letzten Speicherpunkt weiter.

Jede Activity, welche mit dem Attribut [PersistOnClose] ausgezeichnet wird, erreicht dieses Verhalten. Die PersistencePointActivity wird somit trivial:

[PersistOnClose]
public partial class PersistencePointActivity : Activity
{
    public PersistencePointActivity()
    {
        InitializeComponent();
    }
}

Wie man es auch versucht, man erhält keine gültige Referenz auf den Persistenz Service.

Also was tun? Reflector zeigt uns die Interna von WorkflowService.ApplyDispatchBehavior():

static class WorkflowExtensions
...
WorkflowPersistenceService service = item.WorkflowRuntime.GetService<WorkflowPersistenceService>();
if (service != null)
{
    bool isStarted = item.WorkflowRuntime.IsStarted;
    if (isStarted)
    {
        item.WorkflowRuntime.StopRuntime();
    }
    item.WorkflowRuntime.RemoveService(service);
    item.WorkflowRuntime.AddService(new SkipUnloadOnFirstIdleWorkflowPersistenceService(service));
    if (isStarted)
    {
        item.WorkflowRuntime.StartRuntime();
    }
}
...

Was geschieht hier genau?
Wenn via Config oder Code ein Persistenz Service hinzugefügt wurde, wird die Runtime gestoppt. Der Standard Persistenz Service wird entfernt, und ein neuer Service mit dem handlichen Namen SkipUnloadOnFirstIdleWorkflowPersistenceService wird hinzugefügt. Danach wird die Runtime wieder gestartet.
Die Workflow Runtime eines Workflow Services verwendet also intern nicht den SqlWorkflowPersistenceService, sondern einen speziellen, öffentlich nicht zugänglichen und gekapselten Dienst.

Wie also kann nun in einem solchen Kontext die Service ID gesetzt werden?

Die gestern gezeigte Erweiterungsmethode kann wie folgt ergänzt werden:

static class WorkflowExtensions
{
    public static void SetServiceInstanceId(this WorkflowPersistenceService workflowPersistenceService, Guid serviceId)
    {
        Type persistenceServiceType = workflowPersistenceService.GetType();
        FieldInfo instanceIdField = persistenceServiceType.GetField("_serviceInstanceId", BindingFlags.NonPublic | BindingFlags.Instance);
        instanceIdField.SetValue(workflowPersistenceService, serviceId);
    }

    public static WorkflowRuntime GetRuntime(this WorkflowServiceHost host)
    {
        return host.Description.Behaviors.Find<WorkflowRuntimeBehavior>().WorkflowRuntime;
    }

    public static T GetWFService<T>(this WorkflowRuntime runtime) where T : class
    {
        if (typeof(T) != typeof(SqlWorkflowPersistenceService))
        {
            return runtime.GetService<T>();
        }
        else
        {
            WorkflowPersistenceService service = runtime.GetService<WorkflowPersistenceService>();
            Type sqps = service.GetType();

            FieldInfo field = (from fieldinfo in sqps.GetFields(BindingFlags.NonPublic | BindingFlags.Instance)
                               where fieldinfo.FieldType == typeof (WorkflowPersistenceService)
                               select fieldinfo).First();
            return field.GetValue(service) as T;
        }
    }
}

Mit der Erweiterungsmethode GetRuntime() erhält man die WF Runtime vom WorkflowServiceHost.
Mittels wfRuntime.GetWFService<SqlWorkflowPersistenceService>() kann danach durch den Zugriff via Reflection auf den intern als Feld gekapselten Persistenzdienst zugegriffen werden.

Eine Applikation, die beispielsweise auf mehreren Servern gleichzeitig läuft, kann auf dieselbe WF Persistenz Datenbank zugreifen. Dazu wurde das relativ einfache Konzept der Workflow Ownership geschaffen. Dies ist eigentlich nichts anderes als ein einfacher Lock mit einem Timeout.

In der WF Persistenz Datenbank dienen dazu die beiden Felder ownerId und ownedUntil der Tabelle InstanceState:

Aufbau der Tabelle InstanceState

Im Feld ownerId wird die GUID des Persistenz Services der jeweiligen WF Runtime eingetragen, und in ownedUntil steht (im UTC Format!), wie lange die Instanz gesperrt ist.
Wenn diese beiden Felder nicht null sind, wird die entsprechende WF Instanz also gerade von einem Host bearbeitet.
So wird sichergestellt, dass eine Workflow Instanz immer nur von einem Host gleichzeitig ausgeführt wird.

Dies funktioniert grundsätzlich auch prima, der Persistenz Service hat allerdings einige Unschönheiten.

Bei jedem Neustart der WorkflowRuntime wird der Persistenz Service neu initialisiert. Dabei erhält er auch immer eine neu GUID, mit welcher dann die WF Instanzen in der WF DB gelockt werden.
Wenn nun zum Beispiel die Ausführung einer Workflow Instanz abgebrochen wird, bleibt der Lock bestehen.

Nun würde man erwarten, dass die Instanz nach dem Ablaufen des Lock Timeouts von einem anderen Host geladen und weiterbearbeitet werden kann. Leider ist dies nicht der Fall. Der Persistenz Service lädt beim Pollen nach freien Workflow Instanzen nur solche mit abgelaufenem Timer. Diejenigen mit abgelaufenem Lock werden nur beim Start des Services geladen. Solange also der Service nicht neu gestartet wird, kann die Workflow Instanz nicht mehr geladen werden.

Es wäre doch schön, wenn man dem Persistenz Service eine ID zuweisen könnte, damit wäre nämlich das Problem gelöst. In einer Umgebung mit mehreren Hosts, könnte jeder Service seine eigene ID erhalten.
Leider ist dies nicht vorgesehen.

Dem kann man aber abhelfen. Nach einem kurzen Blick auf die Implementation des SqlWorkflowPersistenceService im Reflector kann man dank der in C# 3.0 eingeführten Extension Methods den Service wie folgt erweitern:

static class WorkflowExtensions
{
    public static void SetServiceInstanceId(this WorkflowPersistenceService workflowPersistenceService, Guid serviceId)
    {
        Type persistenceServiceType = workflowPersistenceService.GetType();
        FieldInfo instanceIdField = persistenceServiceType.GetField("_serviceInstanceId",
                                                                    BindingFlags.NonPublic |
                                                                    BindingFlags.Instance);
        instanceIdField.SetValue(workflowPersistenceService, serviceId);
    }
}

Die Service ID wird einfach via Reflection gesetzt. Verwendung auf eigene Gefahr, bei mir hat’s jedenfalls hervorragend funktioniert.

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

So hat die am 1. Oktober von Microsoft veröffentlichte Meldung “Overview of WF 4.0, WCF 4.0, and Windows Server “Dublin” mein Interesse geweckt:

…Microsoft is enhancing both the .NET Framework and Windows Server. The company is adding significant functionality to the new version of Windows Communication Foundation (WCF) and Windows Workflow Foundation (WF) as part of the .NET Framework 4.0 release, including new messaging and REST capabilities in WCF, new workflow models, seamless integration between WF and WCF to support stateful and conversational services, and a new visual designer. The company is also introducing a set of enhanced Windows Server capabilities codenamed “Dublin” that will offer greater scalability and easier manageability, while extending Internet Information Services (IIS) to provide a standard host for applications that use workflow or communications.

Im Dokument, welches als Download zur Verfügung steht, fällt mir vor allem die Erwähnung der Dublin genannten Windows Server Technologie auf, welche den IIS erweitern wird. Ein Standard Host für WCF und WF Applikationen wäre eine feine Sache.
Natürlich kann man bereits jetzt mit überschaubarem Aufwand in IIS 6 + 7 die Workflow Services als zustandsorientierte, “durable” Dienste anbieten. Funktionen zur Versionierung, Überwachung und Monitoring und zum Deployment von Workflows oder WCF Diensten müssen jedoch noch selber implementiert werden.
Mit Dublin könnte sich der IIS langsam zum Ernst zu nehmenden Applikationsserver mausern. Dies werde ich mal im Auge behalten, mein persönliches Technologie Backlog wird also noch länger…

An der PDC2008, die Ende dieses Monats in Los Angeles stattfindet, wird eine CTP Version der drei Technologien abgegeben. Vielleicht mache ich ja da wieder einmal eine Ausnahme und installiere sie.

Ich bin ebenfalls gespannt, ob die für WF 4.0 angekündigten Erweiterungen die Workfow Foundation von einem reinen Toolset für Entwickler zu einer Technologie wandeln wird, die sich vermehrt in Produkten für Endanwender wieder findet.

XOML Workflow Aktivierung mit der WorkflowRuntime

Je nachdem, ob die Workflow Definitionen in einem Assembly oder in XOML vorhanden sind, wählt man den entsprechenden Overload aus.

Für Workflow Definitionen, welche sich in einem Assembly befinden, stehen drei Methoden Overloads zur Verfügung, welche einen Typ als Parameter erwarten:

public WorkflowInstance CreateWorkflow(Type workflowType)

public WorkflowInstance CreateWorkflow(Type workflowType,
                                       Dictionary<string, Object> namedArgumentValues)

public WorkflowInstance CreateWorkflow(Type workflowType,
                                       Dictionary<string, Object> namedArgumentValues,
                                       Guid instanceId)

Wenn die Workflow Definitionen in XOML definiert sind, wählt man einen der anderen drei Overloads aus, welche einen XmlReader als Parameter erwarten. Der zweite XmlReader Parameter nimmt den Inhalt eines .rules files entgegen:

public WorkflowInstance CreateWorkflow(XmlReader workflowDefinitionReader)

public WorkflowInstance CreateWorkflow(XmlReader workflowDefinitionReader,
                                                 XmlReader rulesReader,
                                                 Dictionary<string, Object> namedArgumentValues)

public WorkflowInstance CreateWorkflow(XmlReader workflowDefinitionReader,
                                                 XmlReader rulesReader,
                                                 Dictionary<string, Object> namedArgumentValues,
                                                 Guid instanceId)

XOML basierte Workflows haben einige Vorteile, aber auch konzeptbedingt ein paar Einschränkungen:

• Vorteil: Ein Workflow kann einfacher geändert werden. Dazu muss lediglich die XOML Datei oder wenn die Definition in einer Datenbank gehalten wird, der entsprechende Eintrag angepasst werden.
• Vorteil: Die Regeln eines Workflows werden abenfalls in einer Datei (.rules) oder einem Record gehalten und können unabhängig vom Workflow aktualisiert werden. In Code basierten Workflows erfordert dies ein erneutes Kompilieren.
• Vorteil: Die Workflow Definitionen müssen nicht kompiliert werden. Dies erleichtert das Management und die Verwaltung der Workflow Definitionen.
• Nachteil: In den Workflow Definitionen können keine Properties definiert und keine Event Handler genutzt werden. Dies ist nur mit Code basierten Workflows möglich.

Nicht nur die XOML basierten Workflows enthalten meistens auch eigene Aktivitäten, welche in einem anderen Assembly bereitgestellt sind. Während der Entwicklung der Workflows wird lediglich ein Verweis auf diese Assemblies gesetzt, danach können die dort definierten Aktivitäten im Designer genutzt werden.
Wenn dieses Assembly nicht schon in der AppDomain der Workflow Runtime geladen ist, muss dies der WorkflowRuntime mitgeteilt werden. Dies erfolgt über einen TypeProvider, welcher der WorkflowRuntime als Service hinzugefügt wird:

WorkflowRuntime workflowRuntime = new WorkflowRuntime();

// Create a type provider for types referenced in the XOML
// which are not referenced by this project
TypeProvider typeProvider = new TypeProvider(workflowRuntime);

// Load referenced assemblies into the type provider
Assembly assembly = Assembly.Load("assemblyname");
typeProvider.AddAssembly(assembly);

// OR
// typeProvider.AddAssemblyReference(@"path to the assembly")

workflowRuntime.AddService(typeProvider);

Wenn dann eine Workflow Instanz mit einem der CreateWorkflow() Overloads erzeugt wird, wird die XOML basierte Workflow Definition validiert. Sollte dabei ein Problem auftreten, wird eine WorkflowValidationFailedException geworfen. Dies ist in der Dokumentation nur unter den Bemerkungen zu finden, die Exception wird nicht in der Liste der anderen Ausnahmen aufgeführt.
Die WorkflowValidationException besitzt ein Property Errors (Collection von ValidationError), welches genau Auskunft über die Probleme bei der Validierung der Workflow Definition gibt:

XmlReader workflowReader = XmlReader.Create("Workflow1.xoml");
WorkflowInstance workflowInstance = null;
try
{
    workflowInstance = workflowRuntime.CreateWorkflow(workflowReader);
    workflowInstance.Start();
}
catch (WorkflowValidationFailedException ex)
{
    foreach (ValidationError error in ex.Errors)
    {
        if (string.IsNullOrEmpty(error.PropertyName))
            Console.WriteLine("Validation error: {0}-{1}", error.ErrorNumber, error.ErrorText);
        else
            Console.WriteLine("Validation error for property \"{2}\": {0}-{1}", error.ErrorNumber, error.ErrorText, error.PropertyName);
    }
}

XOML Workflow Aktivierung mit Workflow Services

Wie funktioniert dies nun, wenn man Workflow Services einsetzt, und ebenfalls XOML basierte Workflows aktivieren möchte? Hier stellt sich auf den ersten Blick eine Art “Huhn-Ei Problem“. Der TypeProvider soll der WorkflowRuntime als Service hinzugefügt werden, diese existiert aber erst nach dem Erstellen des WorkflowServiceHosts. Man hat auch nicht direkten Zugriff auf die WorkflowRuntime, so dass nicht ohne weiteres ein Service hinzugefügt werden könnte.
Der Weg führt hier über die Verwendung einer eigenen WorkflowServiceHostFactory, welche einen eigenen WorkflowServiceHost erzeugt. Der Konstruktor dieses WorkflowServiceHosts ist sieben Mal überladen (plus einmal protected), dabei gibt es einen Konstruktor, welcher nebst dem Stream mit der Workflow Definition einen TypeProvider aufnimmt:

public WorkflowServiceHost(Stream workflowDefinition,
                           Stream ruleDefinition,
                           ITypeProvider typeProvider,
                           params Uri[] baseAddress)

Dieser TypeProvider kann nun wie folgt dem Konstruktor übergeben werden:

TypeProvider typeProvider = new TypeProvider(null);

// Load referenced assemblies into the type provider
Assembly assembly = Assembly.Load("assemblyname");
typeProvider.AddAssembly(assembly);

// OR
// typeProvider.AddAssemblyReference(@"path to the assembly")

Stream stream = new MemoryStream(ASCIIEncoding.Default.GetBytes("<MyXOML...>"));;
Uri uri = new Uri("myuri");

WorkflowServiceHost wfsh = new WorkflowServiceHost(stream, null, typeProvider, uri);

Der Konstruktor wirft nun bei Validierungsproblemen entgegen der Dokumentation ebenfalls eine WorkflowValidationFailedException, was so nicht in der Dokumentation steht, so dass man die Fehler entsprechend behandeln kann.

Wie vielerorts empfohlen, macht es bei Workflow Projekten meistens auch Sinn, die Runtime und die Workflow Definitionen in verschiedenen Assemblies abzulegen. Wenn man dann in einer Workflow Library eine neue Workflow Definition einfügen will, sind für die Items auch entsprechende Vorlagen verfügbar.

Wenn man aber mit einer normalen Class Library loslegt, und dann später gerne darin noch Workflow Definitionen oder eigene Activity Typen unterbringen möchte, funktioniert das nicht. Es reicht offenbar nicht aus, wenn man die entsprechenden Referenzen auf die WF Assemblies setzt.
Der Workflow Designer wirft einem eine nicht allzu aufschlussreiche Fehlermeldung “The service ‘System.Workflow.ComponentModel.Design.IIdentifierCreationService’ must be installed for this operation to succeed. Ensure that this service is available.” an den Kopf.

Weshalb? Eine Workflow Library ist doch nichts anderes als ein als DLL kompiliertes Assembly.
Man könnte nun ein neues Workflow Library Projekt anlegen, und alle vorhandenen Dateien hinüberziehen. Es gibt aber auch einen anderen Weg.

Beim Vergleich von zwei Projektfiles stellt man folgendes fest: Im ansonsten völlig identischen Projektfile (.csproj)  der Workflow Library findet man die folgenden zusätzlichen Einträge:

In der ersten PropertyGroup:
[Code language="XML"]{14822709-B5A1-4724-98CA-57A101D1B079};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}[/Code]

Zuunterst im Projektfile (Visual Studio 2008):

[Code language="XML"][/Code]

Für Visual Studio 2005 muss dieser Eintrag auf das .NET 3.0 Framework verweisen:

[Code language="XML"][/Code]

Man kann das Projektfile ausserhalb von Visual Studio bearbeiten, die IDE wird das Projekt automatisch aktualisieren. Danach stehen auch die WF Projektitems zur Verfügung.