Kolumne: SharePoint ganz praktisch

Workflow-Ablaufumgebung in SharePoint
Kommentare

In der vorherigen Ausgabe dieser Kolumne wurde gezeigt, wie die Ausführungsumgebung für SharePoint 2013 Workflows eingerichtet werden muss. Dieser Teil erläutert die Workflow-Ablaufumgebung und geht darauf ein, wie ein erster einfacher SharePoint 2013 Workflow mit SharePoint Designer deklarativ erstellt werden kann.

Für die Umsetzung eigener SharePoint 2013 Workflows können derzeit zwei Entwicklungsumgebungen verwendet werden. Zum einen kann der SharePoint Designer 2013 verwendet werden und zum anderen Visual Studio 2013.

Da SharePoint 2013 Workflows nur deklarativ, also ohne eigenen serverseitigen SharePoint Code realisiert werden können, spielt die verwendete Entwicklungsumgebung zunächst auch keine Rolle. Tendenziell bietet sich aber die Verwendung von Visual Studio an, da oft auch noch ein spezieller Code über eigene Aktivitäten bereitgestellt werden muss. Bevor nun die ersten eigenen Workflows realisiert werden, lohnt sich ein Blick auf die Workflow-Anatomie.

Struktureller Aufbau von SharePoint Workflows

Wie bereits oben angedeutet wurde, ist kein direkter eigener SharePoint-Code innerhalb eines eigenen Workflows möglich. SharePoint 2013 Workflows basieren auf der neuen Windows Workflow Foundation (WF) 4, werden vollständig deklarativ umgesetzt und bestehen im Grunde aus einer Aneinanderreihung einzelner Workflow-Aktivitäten. Jede Workflow-Aktivität kapselt dabei einen funktionalen Aspekt eines (Geschäfts-)Prozesses.

Neben den Workflow-Aktivitäten existieren noch Workflow-Aktionen. Die zu Anfang genannten Workflow-Aktivitäten enthalten die verwalteten Objekte, die die konkrete Ausführung steuern. Die Workflow-Aktionen hingegen kapseln die Workflow-Aktivitäten, um diese vereinfacht innerhalb des SharePoint Designers verwenden zu können. Das heißt, Workflow-Ersteller verwenden Workflow-Aktionen, wohingegen die Workflow-Ausführungsumgebung die zugehörigen Aktivitäten zur Ausführung bringt. Die Aktivitäten selbst stellen eine Implementierung der Aktivitätsklasse dar und werden deklarativ über XAML beschrieben.

Die Workflow-Ausführungsumgebung basiert auf einer nachrichtenorientierten Architektur, die die Windows Communication Foundation (WCF) verwendet. Die einzelnen Workflow-Aktivitäten werden hierbei über Webdienste aufgerufen. Innerhalb einer SharePoint-Farm werden die beiden Workflow-Hauptakteure, also die zu Beginn genannte Windows Workflow Foundation (WF) und der Nachrichtendienst WCF, in Workflow Manager Client 1.0 betrieben (gehostet).

SharePoint und der Workflow-Host

Die gravierendste Änderung gegenüber vorherigen SharePoint-Workflow-Ausführungsumgebungen stellt die Auslagerung der Workflow-Verarbeitung in einen vollständig separaten Prozess (Host) dar. In der letzten Ausgabe der Kolumne wurde die Plattformarchitektur erläutert, dabei war zu erkennen, dass der Workflow-Manager außerhalb von SharePoint ausgeführt wird. Auch wenn in diesem Zusammenhang oft der Begriff Azure fällt, können alle Workflow-Komponenten lokal betrieben werden. Da nun die eigentliche Workflow-Ausführung in einem separaten Prozessraum stattfindet, kommuniziert SharePoint über Nachrichten mit dem Workflow-Manager. Hierbei müssen aber Nachrichten beidseitig ausgetauscht werden können. Das heißt, auch der Workflow-Manager muss in der Lage sein, Nachrichten an SharePoint zu senden.

Neben dem reinen Nachrichtenaustausch müssen auch Informationen über Workflow-Bindungen, zum Beispiel an welche Liste welcher Workflow gebunden ist, verwaltet werden. Die Workflow-Architektur setzt dazu auf den Publication-/Subscribe-Dienst (kurz PubSub). PubSub ist ein asynchrones Nachrichtenframework, das über den Azure Service Bus bereitgestellt wird. Hierbei erstellt der „Publisher“ Nachrichtenobjekte und sendet diese typischerweise an eine Nachrichtenwarteschlange. Der Publisher selbst ist mit keinem bestimmten Empfänger direkt verbunden, auch das Nachrichtenformat hat kein bestimmtes Format für einen bestimmten Empfänger. Auf der anderen Seite konsumieren Subscriber die Nachrichten aus einer Nachrichtenwarteschlange und entscheiden selbst darüber, ob die Nachricht für sie relevant ist oder nicht.

Workflow-Bindungen

Wie eben beschrieben wurde, findet die Kommunikation zwischen SharePoint und dem Workflow-Host über einen PubSub-Mechanismus statt. Weiterhin müssen aber noch Informationen hinterlegt werden, welche Workflows an welchen SharePoint Scope gebunden sind. Diese Informationen werden als Workflow Associations und als Association Scope bezeichnet. Die Workflow Associations speichern die Informationen darüber, welcher Workflow mit welchen Eigenschaften an einen SharePoint Scope gebunden ist. Aktuell werden die beiden Scopes SPList für Listen-Workflows und SPWeb für Site-Workflows unterstützt. Eine direkte Unterstützung, um Workflows an Inhaltstypen zu binden, ist nicht mehr vorhanden. Besteht hier Bedarf, muss die Plattform selbst entsprechend erweitert werden.

Abb. 1: Öffnen einer SharePoint-Website mit SharePoint Designer

Abb. 1: Öffnen einer SharePoint-Website mit SharePoint Designer

Abb. 2: Dialog für die Anlage wiederverwendbarer Workflows

Abb. 2: Dialog für die Anlage wiederverwendbarer Workflows

Abb. 3: Auswahl einer SharePoint-Liste für einen neuen Workflow

Abb. 3: Auswahl einer SharePoint-Liste für einen neuen Workflow

zhou_spkolumne_6-16_4

Abb. 4: Dialog für die Neuanlage eines gebundenen Workflows

Ein erster eigener Workflow

Nachdem nun im Vorfeld die SharePoint-Workflow-Ausführungsumgebung erläutert wurde, wird nun gezeigt, wie ein einfacher Workflow mit SharePoint Designer realisiert werden kann. Die Schritte können sehr einfach nachvollzogen werden. Der Einstieg beginnt mit dem Starten von SharePoint Designer 2013 und dem Öffnen einer beliebigen SharePoint-Website, wie es in Abbildung 1 dargestellt ist.

Nachdem die SharePoint-Designer-Oberfläche geladen wurde, kann ein neuer Workflow über die entsprechenden Menübandfunktionen List Workflow, Reusable Workflow und Site Workflow angelegt werden. Über den Menüeintrag Reusable Workflow ist die Anlage eines Workflows möglich, der zunächst an kein bestimmtes SharePoint-Element gebunden ist. Abbildung 2 zeigt den zugehörigen Dialog für die Neuanlage. Wird hier die neue SharePoint-2013-Workflow-Umgebung als Plattform ausgewählt, wird die Auswahlliste für Inhaltstypen (Content Type) deaktiviert. Dies ist auch nachvollziehbar, da SharePoint 2013 Workflows nicht an Inhaltstypen gebunden werden können. Der nun umzusetzende einfache Beispiel-Workflow soll aber direkt an eine bestimmte SharePoint-Bibliothek gebunden werden.

Um einen solchen Workflow umsetzen zu können, muss die Menübandfunktion List Workflow verwendet werden. Diese besitzt einen kleinen Pfeil, der alle im aktuellen Web verfügbaren Listen und Bibliotheken auflistet (Abb. 3). Der neue Workflow wird an die Dokumentenbibliothek gebunden, die über einen Klick ausgewählt wird. Anschließend erscheint ein weiteres Dialogfenster (Abb. 4), in dem der Workflow-Name sowie eine Beschreibung ausgewählt werden können. Im unteren Bereich wird die Workflow-Zielumgebung auf den Eintrag „SharePoint 2013 Workflow“ eingestellt. Nachdem der Dialog mit OK verlassen wurde, erscheint die Workflow-Designer-Oberfläche. Das Menüband enthält nun weitere spezifische Workflow-Menüelemente. Die einzelnen Menüelemente ermöglichen Folgendes:

  1. Conditions: Ermöglicht das Einfügen einer Bedingung (if-Konstrukt).
  2. Action: Erlaubt das Einfügen einer Methode, wie zum Beispiel das Setzen einer Variablen oder das Schreiben in das Workflow-Protokoll.
  3. Stage: Hierüber kann ein neuer Abschnitt hinzugefügt werden.
  4. Step: Fügt zusätzliche Schritte in einen bestehenden Abschnitt ein.
  5. Loop: Definition einer Schleife.
  6. Parallel Block: Einfügung eines neuen Bereiches, der eine zeitgleiche Ausführung mehrerer Aktionen ermöglicht.

In weiteren Ausgaben der Kolumne werden diese Elemente im Einzelnen genauer erläutert. Der Beispiel Workflow soll folgenden Ablauf umsetzen:

  1. Beim Starten des Workflows soll der Name des Erstellers ausgegeben werden.
  2. Danach soll für den Ersteller eine Aufgabe erstellt werden.
  3. Sobald die Aufgabe bearbeitet wurde, soll das Ergebnis ausgegeben werden.
Abb. 5: Der vollständige SharePoint Workflow

Abb. 5: Der vollständige SharePoint Workflow

Abb. 6: Einfügen eines dynamischen Werts

Abb. 6: Einfügen eines dynamischen Werts

Abb. 7: Anlage einer Aufgabe

Abb. 7: Anlage einer Aufgabe

Abb. 8: Ausgeführter Workflow in SharePoint 2013

Abb. 8: Ausgeführter Workflow in SharePoint 2013

Dieser recht einfache Workflow verdeutlicht dabei die wesentlichen Vorgehensweisen und demonstriert, wie Daten aus Listen verwendet werden können. Für eine bessere Nachvollziehbarkeit zeigt die Abbildung 5 den gesamten Workflow. Als Erstes wird an die „Stage“ ein sprechender Namen vergeben. Dazu muss einfach neben dem Bezeichner „Stage“ geklickt werden, danach kann ein Text eingegeben werden. In diesem Fall trägt die erste Stage die Bezeichnung „Dokument prüfen“.

Als erste Aktion erfolgt ein Eintrag in das SharePoint-Workflow-Protokoll. Dazu muss dem Workflow die Aktion „Log to History List“ hinzugefügt werden. Anschließend kann sehr einfach der Text über den Link „message“, über den das in Abbildung 6 gezeigte Fenster geöffnet wird, erfasst werden. Der Protokolltext soll zusätzlich den Namen des Erstellers ausgeben. Dazu muss auf die Laufzeitdaten des Workflows zugegriffen werden. Dies erfolgt über die untere linke Schaltfläche Add Or Change Lookup.

Diese Funktion öffnet ein zweites Fenster, in dem ein Wert aus dem Kontext des Workflows ausgewählt werden kann (Abb. 6). In der ersten Auswahlliste „Data source“ ist die Quelle anzugeben. Der Eintrag „Current item“ steht hier stellvertretend für den aktuellen Listeneintrag, für den der Workflow gestartet wurde. Anschließend kann in der unteren Auswahlliste ein verfügbares Datenfeld ausgewählt werden. In diesem Fall soll der Ersteller abgerufen werden, daher ist hier die Spalte Created By zu wählen. Die letzte Auswahlliste ermöglicht die Auswahl einer Eigenschaft von dem oben selektierten Objekt. In diesem Fall wird der Anzeigename des Benutzers verwendet.

Nach der Protokollierung wird als Nächstes eine Aufgabe für den Ersteller des Dokuments angelegt. Hierfür wird die Aktion „Assign a Task“ ausgewählt. Um die Aufgabe zu konfigurieren, muss hier nur auf den Link „this user“ geklickt werden. Daraufhin öffnet sich ein weiteres Fenster (Abb. 7). Hier können nun die typischen Aufgabeneigenschaften festgelegt werden. Der Benutzer ist an dieser Stelle dynamisch und muss wieder über ein „Lookup“ ausgewählt werden. Das Vorgehen ist dabei mit der Ermittlung des aktuellen Benutzers für die Protokollausgabe zuvor vergleichbar.

Das Ergebnis der Aufgabe wird in der Variablen Outcome abgelegt. Der Wert der Variablen kann am Ende für die Protokollausgabe verwendet werden. Das Ende des Workflows bildet die letzte Übergangsstufe „Transition to stage“, die hier zum Ende des Workflows springt. Damit ist ein erster einfacher Workflow realisiert. Im oberen rechten Menübandbereich befindet sich noch die nützliche Funktion Check for Errors, die eine Überprüfung des Workflows ermöglicht. Ist alles in Ordnung, sollte der Workflow zunächst gespeichert und anschließend über Publish publiziert werden. Danach kann der Workflow in SharePoint verwendet werden. Abbildung 8 zeigt den gesamten Ablauf einer Ausführung. Wie definiert wurde, erfolgt als Erstes eine Protokollausgabe mit dem Namen des Erstellers des Dokuments. Anschließend wird eine Aufgabe generiert und dem Ersteller zugewiesen, siehe dazu die obere Aufgabenliste. Am Ende wird das Resultat der abgeschlossenen Aufgabe ausgegeben.

In der nächsten Ausgabe der Kolumne kommt dann endlich Visual Studio für die Realisierung deklarativer Workflows zum Einsatz.

Das Video zum Text

Als Ergänzung zum Artikel gibt es ein Video, das die vorgestellten Skripte und ihre Ergebnisse zeigt:

Windows Developer

Windows DeveloperDieser Artikel ist im Windows Developer erschienen. Windows Developer informiert umfassend und herstellerneutral über neue Trends und Möglichkeiten der Software- und Systementwicklung rund um Microsoft-Technologien.

Natürlich können Sie den Windows Developer über den entwickler.kiosk auch digital im Browser oder auf Ihren Android- und iOS-Devices lesen. In unserem Shop ist der Windows Developer ferner im Abonnement oder als Einzelheft erhältlich.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -