Heimkehr des verlorenen Sohns

Zustandsautomaten in Workflow Foundation 4.1
Kommentare

Nach der Neuimplementierung der Workflow Foundation mit .NET 4 wurde eine Funktionalität, die es in der Vorgängerversion bereits gegeben hat, schmerzlich vermisst: Zustandsautomaten. Glücklicherweise steht diese Funktionalität seit dem Update 1 von Version 4 wieder zur Verfügung.

Bis dato musste man in .NET-4-Zustandsautomaten (State Machines) mit den Möglichkeiten der Aktionen Pick und PickBranch simulieren, obwohl diese Form der Modellierung bereits in Version 3 zur Verfügung stand. Dieser Umstand war der Tatsache geschuldet, dass die Workflow Foundation mit .NET 4 aufgrund von Designschwächen seines Vorgängers neu implementiert wurde. Nun ist es aber endlich so weit: ab .NET 4 Update 1 bietet die Workflow Foundation wieder Zustandsautomaten an. Damit man in den Genuss dieser Möglichkeit kommt, muss nach der Installation von Update 1 in den Projekteigenschaften das Target Framework mit dem Namen .NET 4 Plattform Update 1 (KB2478063) festgelegt werden (Abb. 1).

Abb. 1: Target Framework auf .NET 4 Update 1 festlegen
Abb. 1: Target Framework auf .NET 4 Update 1 festlegen

Modellieren von Zustandsautomaten

Ein Zustandsautomat zeigt die einzelnen Zustände, die ein System oder Systembestandteil einnehmen kann, und unter welchen Umständen zwischen den einzelnen Zuständen gewechselt wird. WF-Zustandsautomaten werden innerhalb von Statemachine-Aktivitäten modelliert und können somit mit anderen Workflowarten kombiniert werden. Abbildung 2 zeigt als Beispiel einen Zustandsautomaten, der die einzelnen Zustände einer Bestellung beinhaltet. Der Startzustand verweist auf den ersten Zustand, den eine Bestellung einnimmt. Pro Automat muss es genau einen Startzustand geben und dieser darf lediglich einen einzigen Übergang aufweisen. Bei Storniert und Ausgeliefert handelt es sich um Endzustände, die mit der Aktivität FinalState modelliert werden. Dies erkennt man am Logo, das links oben aufscheint und etwas von den Logos der anderen Zustände abweicht. Endzustände führen zur Beendung der Statemachine-Aktivität und dürfen somit keine Nachfolger haben. Bei Betrachtung dieses Beispiels fällt auch auf, dass nur vom Zustand Bestellt nach Storniert gewechselt werden kann. Sobald sich die Bestellung im Zustand InBearbeitung befindet, ist dies nicht mehr möglich. Außerdem verweist der Zustand Bestellt auch auf sich selbst. Damit wird eine mögliche Abänderung der Bestellung, die ebenfalls nur in diesem Zustand erlaubt ist, modelliert.

Abb. 2: Beispiel eines Zustandsautomaten
Abb. 2: Beispiel eines Zustandsautomaten

Nach Doppelklick auf einen Zustandsübergang kann man dessen Eigenschaften festlegen. Beim Trigger handelt es sich um ein Ereignis, bei dessen Eintreten der Zustandswechsel durchzuführen ist. Trigger werden durch herkömmliche Aktionen repräsentiert. Diese müssen jedoch per Definition blockieren bis das damit assoziierte Ereignis eingetreten ist, und sich anschließend beenden. Während sie blockieren, dürfen Sie den Prozessor nicht an sich reißen. Im betrachteten Beispiel kommt lediglich ein Delay als Trigger zum Einsatz. Stattdessen könnte jedoch auch gewartet werden, bis eine bestimmte Serviceoperation aufgerufen wird. Wird auch eine Condition definiert, findet der Zustandsübergang beim Eintreten des Triggers nur dann statt, wenn diese zusätzlich auf true ausgewertet werden kann. Eine Aktion, die unter Action festgelegt wird, kommt im Zuge des jeweiligen Zustandswechsels zu Ausführung. Per Doppelklick auf eine Aktion werden deren Eigenschaften angezeigt. Hier kann jene Aktion festgelegt werden, die beim Betreten des Zustands aufzuführen ist. Daneben kann auch eine weitere Aktion angegeben werden, die beim Verlassen des Zustands zur Ausführung gebracht werden soll.

Fazit und Ausblick

Nachdem man die Zustandsautomaten für Version 4 schon längere Zeit in Form einer CTP begutachten konnte, sind sie nun endlich offiziell verfügbar. Besonders geeignet scheinen sie für langlaufende Workflows und somit im Zusammenspiel mit Workflowservice zu sein. In diesem Fall könnten Zustandswechsel in Folge eines Methodenaufrufs, der auch Informationen für den weiteren Verlauf des Workflows liefert, erfolgen. Neben Zustandsautomaten hat das Produktteam bei Microsoft auch noch weitere Neuerungen in der Pipeline. Darunter befinden sich einige kleinere Features, wie vorgefertigte Aktionen für alltägliche Aufgaben, zum Beispiel der Versand von E-Mails, aber auch größere und langersehnte Neuerungen, wie zum Beispiel die Unterstützung von Workflows, die in verschiedenen Versionen vorliegen, oder das Aktualisieren von laufenden Workflows auf eine neue Version.

Manfred Steyer (http://www.softwarearchitekt.at) ist freiberuflicher Trainer und Berater bei IT-Visions (http://www.IT-Visions.de) sowie verantwortlich für den Fachbereich „Software Engineering“ der Studienrichtung „IT und Wirtschaftsinformatik“ an der FH CAMPUS 02 (campus02.at) in Graz. In seinem aktuellen Buch „Verteilte Systeme und Services mit .NET 4.0: Konzepte und Lösungen mit WCF 4.0“ beschreibt er gemeinsam mit Holger Schwichtenberg den Einsatz von WCF für Unternehmensanwendungen.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -