Windows Workflow Foundation Einführung

Da wir als Microsoft Schweiz Anfang nächsten Monat einen Hands-on-Lab über Windows Workflow Foundation machen werden (Infos unter https://www.microsoft.com/switzerland/msdn/de/events/hol/wf.mspx), habe ich mich entschieden eine kurze Einführung über das Thema zu posten. Als Images werden englische (sorry :)) Slides verwendet...

Wie Sie vielleicht schon wissen ist WF Teil des .NET Frameworks 3.0. Hierbei wichtig zu wissen ist, dass das .NET Framework 3.0 als Basis die .NET Framework Version 2.0 verwendet. Es gibt keine technischen Änderungen. Wenn Sie die Version 2 verwenden und dann Version 3 installieren, werden die DLLs von Version 2 nicht überschrieben. Wenn Sie noch keine Version 2.0 haben (diejenige Version, welche Sie auch mit der Installation von Visual Studio 2005 erhalten) und Version 3 installieren, werden Sie automatisch die Version 2.0 kriegen, plus 4 neue zusätzliche Stücke, 4 neue zusätzliche Technologien:

Windows Presentation Foundation : Eine neue Technologie, die eine neue graphische Darstellung (UI) bietet. Diese erlaubt uns eine sehr gehaltvolle Darstellung zu haben mit Video, Animationen, 3d Elementen und vektoriellen Elementen.

Windows Communication Foundation bietet uns einen ganz neuen Weg um verteilte Anwendungen mit Hilfe einer unifizierten API zu programmieren....und das in einem ziemlich einfachen Weg. Wenn Sie zum Beispiel WebServices oder Remoting verwenden, können Sie immer auf die gleiche Art codieren und das Dank der unifizierten API und dann später, sagen wir während Deployment Time unsere Anwendung konfigurieren und zum Beispiel sagen …ich möchte gern remoting statt WebServices verwenden.

Windows Workflow Foundation: Gibt uns die Möglichkeit Business Prozesse zu modellieren, wie der Name sagt Workflows kreierend.

Windows CardSpace: Bietet uns einen neuen Weg unsere Identität zu managen.

Also, wie Sie gesehen haben, .NET Framework Version 3 ist keine Modifikation der Version 2, sondern in Tat und Wahrheit nur Version 2 plus diese 4 neuen zusätzlichen Technologien: WPF, WCF, WF und WCS.

Und wie integriert sich WF in diesem Kontext?

WF ist ein Framework, eine Gruppe von Klassen die in einem spezifischen namespace organisiert sind. Klassen, die uns von Microsoft offeriert werden, um unsere eigenen Business Prozesse, unsere eigenen Workflows, innerhalb unseren eigenen Anwendungen zu implementieren. WF ist selber keine Anwendung, Sie werden immer noch Ihre eigene Anwendung brauchen, die Ihren Workflow integriert; eine Anwendung, die ihren Workflow hosten muss. Der Motor, der uns von Microsoft geliefert wird, ist kein WF Motor der für ein spezifisches Umfeld gedacht ist, sondern ein Framework um irgendeine Typologie von Workflow zu kreieren.

Dies bietet uns ein riesiges Potential, da wir nicht in der Wahl der möglichen Anwendungen limitiert sind. Was wir haben ist ein Motor um Workflow im Allgemeinen zu erstellen.

WF ist eine eigene Workflow Technologie für MS, bzw. die einzige Technologie für Microsoft. Wenn Sie die neuen bzw. zukünftigen Produkte von MS anschauen (Produkte die einen Workflow Motor brauchen), werden Sie die Präsenz von WF bemerken.

Zum Beispiel mit Office SharePoint Server 2007: Wenn Sie einen eigenen Workflow definieren möchten, werden Sie Workflow Foundation verwenden. Die zukünftige Version von BizTalk Server wird selber auch auf Workflow basieren.

WF verwendet ein Programmationsmodell das im Moment bei Microsoft Technologien ziemlich aktuell ist: Das deklarative Programmationsmodell. Dieses deklarative Programmationsmodell erlaubt uns Klassen in Form von XML Dokumenten zu definieren. Das gleiche Modell wird bei Windows Presentation Foundation verwendet und wird in diesem Fall vor allem benutzt um die graphische Darstellung als XML zu definieren.

Also, was brauchen Entwickler wenn sie einen Workflow erstellen möchten?

Eigentlich nichts Spezielles: Natürlich das .NET Framework Version 3. Entweder die Version 3 welche mit Windows Vista schon mitgeliefert wird, aber es kann auch auf WinXP SP 2 oder Windows Server 2003 SP1 deployed werden. Für Entwickler ist der SDK natürlich auch ein nützliches Mittel und natürlich Visual Studio 2005. Sie brauchen keine spezielle Version von Visual Studio 2005, Sie können benutzen was Sie schon Heute verwenden. Was Sie noch brauchen sind die WF Extensions für Visual Studio 2005 zu installieren (https://go.microsoft.com/?linkid=6405326), die innerhalb von Ihrem Visual Studio neue Projekt Typen erstellen werden, die spezifisch für Workflow sind. Diese neue Typologien von Projekten bieten einen neuen Designer; Designer den Sie verwenden können um Workflow zu erstellen oder auch zu debuggen (ja genau, das Paket beinhaltet einen Workflow Debugger).

Nun da wir gesehen haben welche die Tools wir brauchen, ist es Zeit zu definieren, was genau ein Workflow ist.

Ein Workflow kann als ein Programm deklariert werden, das aus einem Set von Aktivitäten definiert ist. Aktivitäten die eine Art von Business Logik oder Business Prozessen implementieren.

Diese Definition ist ziemlich vage; wieso das? Wie gesagt ist Workflow Foundation eine Plattform, um alle Typologien von Anwendungen zu entwickeln, die einem Workflow entsprechen.

Solch ein Workflow kann einer ziemlich breiten Typologie von Anwendungen entsprechen, Anwendungen in denen entweder Leute oder Software involviert sind, die Aufgaben ausführen müssen. Man spricht oft auch von menschlichen Workflows (human Workflow), wo die Interaktion mit einem Benutzer, einem Operator gefragt ist, oder dem so genannten System Workflow, welcher sich auf Business Prozesse zwischen Informationssystemen bezieht. Diese sind auch als „unattended“ Workflows bekannt (sie brauchen keinen menschlichen Eingriff). Dies sind die klassischen Batch Systeme, die vielleicht während der Nacht laufen wenn eine automatische Interaktion zwischen den Systemen passiert.

Menschliche Workflows sind Workflows, welche normalerweise eine längere Zeit benötigen, und nur weil der menschliche Eingriff gefragt ist. Wenn ich eine Ratifikation eines Dokumentes machen muss, muss ich zuerst das Dokument lesen, und vielleicht brauche ich dafür 2 oder 3 Tage.

Workflows können eine Art von Flussdiagramm beinhalten, wo wir einen Startpunkt und einen Ausgangspunkt haben. Wir starten von Oben nach Unten. Wir können auch einen Workflow in der Art eines State Diagramms definieren. Ein State, einen Status stellt die Situation eines Business Prozesses in einem spezifischen Moment dar. Wir gehen von einem Status zum andern, nachdem wir einen äusseren Event erhalten haben.

Wenn wir an die reale Welt denken, wo kann Workflow verwendet werden?

Denken Sie an eine Anwendung, wo Bestellungen innert 48 Stunden bestätigt und innerhalb von 30 Tagen ausgeliefert werden. In diesem Fall haben wir einen Long Running Prozess (in unserem Fall dauert er bis 30 Tage). Die hierfür typische Software mit Prozedural Code hat meist Probleme mit Long Running Prozessen, weil der Code die ganze Zeit unsere CPU belastet. Long Running müssen hingegen gestoppt werden und müssen den Status irgendwie persistent machen. Workflow kann in diesem Fall verwendet werden, weil es für Long Running Prozesse, für State Management konzipiert wurde. Tatsächlich kommt Workflow mit einem out-of-the-box persistent Dienst der auf SQL Server basiert ist.

Workflow ist auch hilfreich für die Transparenz der Business Logik. Sie können das Model sehen, Sie können überwachen was am Laufen ist und das dank Tracking Informationen die von den Workflow Runtimes erstellt werden.

Flexibilität und gleichzeitig Extensibilität sind auch zwei wichtige Faktoren in Workflow: Sie können beispielsweise das Modell ändern wenn Workflow am Laufen ist. Es gibt die Möglichkeit den Designer ausserhalb von Visual Studio zu hosten (also innerhalb Ihrer eigenen Anwendungen). Eine Person die nicht unbedingt technisch versiert ist, aber dafür verantwortlich den Fluss zu definieren, kann zum Beispiel die Reihenfolge unseres Workflows ändern.

WF ist wie gesagt ist nicht nur flexibel, es ist auch ausweitbar (Extensibility): Sie können Ihre eigenen Aktivitäten, die genau den Bedürfnissen Ihres Business Prozess entsprechen, selber definieren.

Um alle diese Probleme zu lösen bietet Workflow uns 2 Typologien von Projekten, 2 Typologien von Workflows:

• Wir haben die Sequentiellen Workflows, die eine Reihenfolge von Aktivitäten ausführen. Es gibt immer einen Eingangspunkt und einen Ausgangspunkt. In Sequentiellen Workflows kann man verschiedene Wege nehmen aber am Schluss kommen wir zum gleichen Ausgangspunkt. Normalerweise haben wir keine menschliche Interaktion, und Workflows werden in einer bestimmten Zeit ausgeführt. Die Sequentiellen sind ziemlich einfach zu erklären. Man kann im Prinzip ein Stück Papier nehmen, ein Flussdiagramm drauf zeichnen und grafisch 1:1 in unseren Visual Studio Workflow Designer übertragen.
• Dann kommen wir zur zweiten Familie: den sogenannten State Machine Workflows. Hier ist das Konzept ein bisschen komplexer. In diesem Fall spricht man von Zuständen, oder Stati. So ein State Machine Workflow ist ein zusammenspiel von Zuständen, und diese Zustände vertreten Situationen in welchen sich der Business Prozess befinden kann. Die Statusänderung passiert wenn ein externer Event ausgelöst wird. Sehr oft werden diese externen Events von menschlicher Interaktion ausgelöst. Als Beispiel nehmen wir ein BugFixing System, das von einem Tester und einem Entwickler verwendet wird. Ein Tester findet einen Bug. Er kann so den Bug im System eintragen und was passiert? Der Bug Status wird auf „ToBeAssigned“ gesetzt (Jemand muss sich darum kümmern). Und nun? Es gibt vielleicht eine dritte Person die verantwortlich ist um Bugs an Entwickler zuzuweisen. Der Bug wird also einem Entwickler zugewiesen. Er kann den Bug korrigieren und in diesem Fall wird der BugStatus zurück auf „ToBeTested“ gesetzt und geht somit an den Tester zurück. Es könnte aber auch sein dass der Entwickler den Bug an die Person zurückschickt, die ihm den Bug zugewiesen hat, weil er mit dem Bug überhaupt nichts zu tun hat.
  Also haben wir mehrere Zustände, und es gibt keine vorgegebene Reihenfolge: Erst Status1 dann Status2, und so weiter und so fort. State Machine Workflow sind also logisch wenn es Sinn macht, einzelne Situationen zu isolieren.

Wie können wir am Besten entscheiden ob wir einen Sequentiellen Workflow oder einen State Machine Workflow verwenden müssen? Da gibt es eine Liste von Richtlinien:

Sequentielle Workflows machen zum Beispiel Sinn, wenn es möglich ist einen Business Prozess als eine Reihenfolge von Aktivitäten in einer bestimmten Ordnung zu definieren, was mit State Machine nicht immer der Fall ist.

Für State Machine würde ich grundsätzlich sagen dass ein „State Workflow“ Sinn macht, wenn eine Definition von einem Business Prozess in Form eines Sequentiellen Workflows zu komplex ist, sich zu viel wiederholt oder zu variabel ist. Sie können das Image auf der linken Seite als Referenz verwenden.

Schauen wir jetzt mal die Architektur von WF an.

Die Architektur ist ziemlich einfach. Von der Definition her ist Workflow ein Zusammenspiel von Aktivitäten. Aktivitäten, die entweder vordefiniert sind (out-of-the box Aktivitäten) oder die gebaut sind um Ihre spezifischen Bedürfnisse zu erfüllen.

Alle diese Aktivitäten sind innerhalb eines Workflows ausgeführt. Workflow der innerhalb einen Hosting Umgebung gehostet wird. Diese Hosting Umgebung ist bei einem Business Prozess definiert und kann zum Beispiel eine Windows Form Anwendung, eine Web Anwendung, oder eine Konsole Anwendung sein. Und so weiter und so fort.

So können wir selber entscheiden wo wir unseren Workflow hosten möchten: Könnte auf Server Seite innerhalb einer Business Komponente, oder innerhalb unserer Web Seite sein.

Unser Host Prozess wird dem Workflow Engine (Den Runtime Engine) einen Platz geben (hosten). Dieser Motor seinerseits, wird die Instanzen von unserem Workflow ausführen. Instanzen, die die Möglichkeit haben, Runtime Dienste zu benutzen, welche Extensionen von den Runtime Engine sind. Beispielsweise bietet WF einen Persistent Dienst an, der die Möglichkeit gibt, einen Workflow Persistent zu machen wenn der Workflow inaktiv ist.

Wenn der Workflow inaktiv wird, möchten wir klar keine CPU und RAM verwenden. Das würde die Scalabilität von der Anzahl unserer Workflows, die gleichzeitig ausgeführt werden, limitieren. So ist unser Runtime fähig zu identifizieren, wenn eine Instanz von einem Workflow inaktiv ist und so kann es unsere Instanzen persistent machen. Nochmals wir haben einen out-of-the box Persistent Dienst der auf SQL Server basiert ist. Es existieren auch andere Dienste, wie der Tracking Dienst, wie bereits vorher erwähnt.

Jetzt ist es Zeit ein bisschen mehr technisch zu werden...

Workflow kann als eine .NET Klasse definiert werden, also eine C# oder VB.NET Klasse, aber er kann auch als XML Dokument, als XAML Dokument definiert werden (XML Dokument der eine XOML Extension hat). So können Sie zwei Varianten haben: Sie können Code erstellen oder sie können ein XAML Dokument definieren, das die serialisierte Version im XML Format der Workflow Klasse ist.

Mit diesem Mix von Technologie haben wir verschiedene Entwicklungsmöglichkeiten, verschiedene Möglichkeiten zum kompilieren. Wenn Sie Ihren Workflow mit XAML definieren, wird der Workflow Compiler die XML Datei in der entsprechenden .NET Klasse kompilieren und schlussendlich eine .NET Assembly produzieren, Assembly das verwendet wird um Workflow Instanzen zu generieren, die vom Runtime gemanagt werden.

Wir können auch die Mixe Form haben: Code mit XAML oder nur Code. Und am Schluss haben wir immer einen Assembly. Es gibt dann eine andere Möglichkeit: der Runtime kann eine Instanz generieren, indem er direkt das XML Dokument aufladet.

Aber wieso haben wir alle diese Möglichkeiten? Genau, Dank der Tatsache dass wir das Deklarative Programmationsmodel verwenden können, eröffnen sich neue Möglichkeiten. Ein Dritter könnte beispielsweise Tools produzieren, die Workflows generieren: Es wäre genug XML zu produzieren. Und das wäre ziemlich einfach im Vergleich zum C# Code oder VB.NET zu generieren.

Und das ist genau was Microsoft mit SharePoint 2007 gemacht hat. Im Sharepoint können Sie Ihre eigenen Workflows mit Regeln etc definieren, und am Schluss erhält man ein XAML Dokument, das von Workflow Runtime aufgeladen werden kann. Für die zukünftige Version von BizTalk Server wird Microsoft auch einen ganz neuen Designer haben.

Kurze Zusammenfassung: Workflow sind schlussendlich .NET Klassen, .NET Klassen die von Base Klassen von Runtime erbt. Wie wir ganz am Anfang gesehen haben, gibt es 2 Typologien von Workflow: wir haben die Sequentiellen Workflows die von der sequentialWorkflowActivity Base Klasse erbt, oder die State Machine Workflows die von der StateWorkflowActivity Base Klasse erbt.

Was bedeutet das? Dass Workflows Aktivitäten sind! ...und was können wir damit machen? Wir können Workflows innerhalb von anderen Workflows ausführen. Für das können Sie eine out-of-the box Aktivität benutzen: die InvokeWorkflow Aktivität.

Wir haben schon mehrmals gesagt, dass Aktivitäten die Bausteine sind die unseren Workflow zusammenstellen. Aktivitäten sind schlussendlich .NET Klassen, die von System.Workflow.ComponentModel.Activity erbt. Alle kleinen Bausteine vererben diese Klasse. Workflow selber auch, da wir gesagt haben dass Workflows Aktivitäten sind.

WF kommt mit einer ganzen Palette von out-of-the box Aktivitäten (Sie können Visual Studio öffnen und die Windows Workflow Toolbox anschauen). Es gibt viele interessanten Aktivitäten, wie zum Beispiel die InvokeWebService Aktivität, die uns die Möglichkeit gibt einen WebService aufzurufen oder die Parallel Aktivität die uns erlaubt, wie der Name sagt, Aktivitäten parallel auszuführen (nur eine kleine Bemerkung über die Parallel Aktivität: es ist kein Multithreading, es wird nur 1 Thread verwendet).

Wenn wir etwas spezifisch brauchen, können wir selber unsere Aktivitäten definieren. Diese Aktivitäten können auch von Dritten erstellt werden. Wir selber als MS haben im Office Bereich spezifische Aktivitäten entwickelt die genau gedacht sind um mit Office Dokumente zu arbeiten. Es wäre nicht sinnvoll gewesen diese Office Aktivitäten per Default in die Basic Activity Library zu integrieren, zum Beispiel wenn ich eine Lager-Applikation mit Workflow baue, möchte ich nicht unbedingt mit einem Word Dokument etwas machen. Wenn es nötig wäre kann ich immer auf die genaue Office Activity Library referenzieren und so auf die Office Aktivität zugreifen.

Aber was haben wir für Möglichkeiten wenn wir eine ganz neue Aktivität entwickeln möchten? Es gibt vorallem 3 Möglichkeiten:

• mit der Hilfe von Designer können wir Composite Activity bauen. Eine Aktivität die aus mehreren Aktivitäten zusammengesetzt ist.
• wir können von einer anderen Aktivität erben und so können wir das Verhältnis von der Ursprünglichen Aktivität neu definieren.
• wir können eine Aktivität ab NULL schreiben. Auf dem Web finden Sie eine Menge von Beispielen. Hier gebe ich Ihnen einen Link wo gezeigt wird, wie man eine Send Mail Aktivität erstellen kann (https://msdn2.microsoft.com/en-us/library/aa480214.aspx).

Es gibt noch ein letztes Konzept zu beschreiben, und zwar Workflow Hosting. Wie ich schon erwähnt habe, müssen die Workflows von jemandem gehosted werden. Sie können innerhalb einer Business Komponente gehosted werden, oder innerhalb von Anwendungen die die UI darstellen. Zum Beispiel WinForm Anwendungen, ASP.NET Anwendungen, im Prinzip überall wo man das .NET Framework hosten kann.

Aber was ist genau Hosting: Hosting ist der Prozess wo der WF Runtime instanziiert, konfiguriert und gestartet wird. Und wie sieht es aus im Code?

..
WorkflowRuntime runtime = new WorkflowRuntime();
runtime.AddService(...)
WorkflowInstance instance = runtime.CreateWorkflow(...);
Instance.Start();
Guid id = Instance.InstanceId;
...

Es wird zuerst eine Instanz vom Workflow Runtime gestartet, wenn man gewisse Runtime Dienste verwenden möchte (so zum Beispiel den Persistente Dienst, oder Trecking Dienst), kann ich runtime.AddService benutzen.

Man erstellt ein Objekt vom Typ WorfklowInstance mit runtime.CreateWorkflow, Wieso das? Weil es genau der Runtime ist der sich um meine Workflow Instanzen kümmert. Als Parameter von der Methode CreateWorkflow muss man den Typ von Workflow mitgeben.

Um die ganze Ausführung zu starten muss man die Methode „instance.Start“ aufrufen. Um die Instanzen von einem Workflow zu unterscheiden, hat man die Eigenschaft InstanceID zur Verfügung.

Wir haben von Host und Workflow gesprochen. Aber was noch nicht gesagt wurde ist dass auch die Kommunikation zwischen dem Host und dem Workflow möglich ist. Für das haben wir nochmals spezifische Aktivitäten zur Verfügung. Im Wesentlichen die CallExternalMethod Aktivität um einen Aufruf von einer Methode zu machen (von Workflow Richtung Host); oder eine HandleExternalEvent Aktivität um auf spezifische Externe Events zu reagieren, Events die im Host ausgelöst werden (Host Richtung Workflow).

Das war nur eine kurze Einführung zum Thema Workflow Foundation. Wenn Sie tiefergehendes Interesse haben, finden Sie auf MSDN viele Dokumentation. Es gibt auch die Community Web Site (https://wf.netfx3.com/), die empfehlenswert ist.

Falls Sie Interesse haben können Sie wie Anfangs erwähnt an unserem Workflow HOL Event am 7. September teilnehmen (Anmeldung unter https://www.microsoft.com/switzerland/msdn/de/events/hol/wf.mspx), wo sie selber versuchen werden ein richtiges Workflow Beispiel zu implementieren.