Kolumne: SharePoint ganz praktisch

Workflows in SharePoint realisieren
Kommentare

Der Einsatz und die Verwendung von Workflows werden von SharePoint schon seit der ersten Version 2001 unterstützt. Die Art und Weise der Workflowumsetzung hat sich jedoch seitdem erheblich gewandelt. Die heutige sowie die nächsten Ausgaben der SharePoint-Kolumne widmen sich der Realisierung von Workflow in SharePoint 2013/2016.

Jedes Unternehmen besitzt mehr oder weniger strukturierte Arbeitsabläufe, die nachfolgend unter den Begriff „Geschäftsprozesse“ subsumiert und zunächst in interne und externe Geschäftsprozesse unterteilt werden können.

Interne Geschäftsprozesse zeichnen sich dadurch aus, dass man nur Prozesse betrachtet, die firmenintern abgehandelt werden. Technisch gesehen handelt es sich dabei um Prozesse, die mit Daten auskommen, die im Intranet verfügbar sind. Externe Geschäftsprozesse benötigen in der Regel Daten bzw. Informationen externer Partner – z. B. von Lieferanten. Der SharePoint Server und die integrierte Workflowumgebung bieten eine ideale Plattform, um beide Ausprägungen auf elektronische Weise zu unterstützen. Die Unterstützung interner Abläufe ist meist problemlos möglich.

Inwieweit externe Geschäftsprozesse unterstützt werden, hängt von der SharePoint-Installation ab. Handelt es sich bei der SharePoint-Bereitstellung um eine reine Intranetinfrastruktur, ist die nahtlose Einbeziehung externer Partner schwieriger. In diesem Fall müssen erst Kommunikationswege geschaffen werden, die einen externen Zugriff ermöglichen. Da die Öffnung externer Zugriffe auf die eigene Infrastruktur immer Risiken mit sich bringt, ist in Kombination mit Office 365 eine hybride Lösung möglich. Anstatt Workflows nur intern zur Verfügung zu stellen, können diese auch über SharePoint online verfügbar gemacht werden. Innerhalb von SharePoint Online können so genannte externe Benutzer, die nicht zur eigenen Organisation gehören, ebenfalls an einem Workflowprozess teilnehmen.

Die Workflowumgebung

Die Umsetzung und Ausführung von Workflows sind mit SharePoint schon lange möglich. SharePoint beinhaltet auch selbst einige Standardworkflows, wie zum Beispiel den Freigabeprozessworkflow, der direkt verwendet werden kann. Die Art und Weise der konkreten Workflowimplementierung hat sich allerdings in den Versionsverläufen von SharePoint oft geändert. Die letzte signifikante Änderung gab es mit SharePoint 2013. Vor SharePoint 2013 basierten Workflows technisch auf der Windows Workflow Foundation 3.5. Ausgeführt werden die Workflows hier direkt auf einen SharePoint Server. Der Workflowcode hat über das serverseitige SharePoint-API direkten Zugriff auf SharePoint-Daten. Dieses Modell ermöglicht eine relativ einfache Umsetzung von Workflows.

Da jedoch bei diesem Modell der gesamte Workflowcode auf dem SharePoint Server ausgeführt wird, können sich Fehler im Code auf die gesamte SharePoint-Farm auswirken. Sind zudem sehr viele Workflows gleichzeitig aktiv, werden viele Hardwareressourcen an Workflowinstanzen gebunden. Dieses wirkt sich dann negativ auf die Performance der SharePoint-Farm aus. Zudem kann es zu Deadlock-Problemen auf Datenbankebene kommen, und die Ausführung langwieriger Operationen (Delay-Aktivität) verlief auch nicht immer fehlerfrei. Aus diesen und anderen Gründen hat sich Microsoft dazu entschieden, die Windows Workflow Foundation 3.5 nicht weiterzuentwickeln. Stattdessen stellt die Windows Workflow Foundation 4 (WF) eine vollständige Neuimplementierung gegenüber der vorherigen Version dar.

Workflows in SharePoint 2013

In SharePoint 2013 basieren daher Workflows auf der neuen Windows Workflow Foundation 4, die selbst wiederum auf der von Windows Communication Foundation (WCF) bereitgestellten Messaging-Funktion aufsetzt. Neben dieser Neuerung hat sich auch das Ausführungsmodell von Workflows erheblich verändert. Workflows können nun auf einem entfernten Server ohne jegliche SharePoint-Server-Abhängigkeiten ausgeführt werden. Somit werden keine großen Hardwareressourcen des SharePoint Servers an Workflowinstanzen verschwendet. Zusätzlich sorgt die entfernte Ausführung für eine vollständige Prozessisolation. Fehler im Workflowcode wirken sich somit nicht mehr auf den SharePoint Server direkt aus.

Abbildung 1 zeigt dazu die Architektur der Workflowinfrastruktur in SharePoint 2013. Wie anhand der Grafik erkennbar ist, beinhaltet SharePoint 2013 einen „SharePoint-2010-Workflowhost“. Dieser ermöglicht die Ausführung von Workflows, die noch auf der alten Windows Workflow Foundation 3.5 beruhen. Das ist notwendig, da eine direkte Migration/Aktualisierung von alten Workflows nicht möglich ist. Besteht die Anforderung, bestehende Workflows auf die neue Workflowumgebung zu aktualisieren, ist eine Neuimplementierung notwendig.

Die neuen SharePoint-2013-Workflows werden innerhalb eines eigenen Prozessraums ausgeführt, der in der Grafik auf der rechten Seite zu sehen ist. Die konkrete Ausführung übernimmt hier der Workflow Manager. Die Kommunikation zwischen SharePoint und dem Workflow Manager erfolgt REST-basiert. Die Kommunikation ist bidirektional, d. h., der Workflow Manager kann bei bestimmten Ereignissen Nachrichten an SharePoint senden. In vielen Fällen sind die Bezeichner wie „Windows Azure Service Bus“ etwas verwirrend und führen zu dem Schluss, dass die Ausführung in Azure erfolgt. Diese Annahme trifft allerdings bei einer lokalen Installation nicht zu, alle Ausführungskomponenten werden lokal installiert und ausgeführt. Bevor auf weitere Details der neuen Workflowumgebung eingegangen wird, erläutert der nächste Abschnitt zunächst die Installation, um die neue Workflowumgebung verwenden zu können.

Abb. 1: Die Workflowarchitektur in SharePoint 2013

Abb. 1: Die Workflowarchitektur in SharePoint 2013

Einrichten der SharePoint-2013-Workflowumgebung

Bevor die neue Workflowausführungsumgebung verwendet werden kann, muss sie installiert und konfiguriert werden. Das ist notwendig, da die eigentliche Workflowausführung isoliert von SharePoint stattfindet. Die Installation kann daher wahlweise auf einem separaten Server oder auch auf dem SharePoint Server selbst ausgeführt werden. Für eine produktive Bereitstellung ist die erstgenannte Installationsvariante vorzuziehen, für Test- und Entwicklungsumgebungen ist auch die letztgenannte Variante möglich.

Die nachfolgende Installationsbeschreibung gilt für Entwicklermaschinen und berücksichtigt keine speziellen Sicherheitsaspekte. Auf einer Entwicklungsmaschine stellt der Web Platform Installer den einfachsten Einstiegspunkt für die Installation dar. Dieser kann hier aufgerufen werden. Wird nach dem Öffnen des Installer-Links nicht direkt der Workflow Manager in der Liste aufgeführt, muss zunächst über das rechte obere Suchfeld danach gesucht werden (Abb. 2). Alternativ können auch die Installationsdateien für eine Offlineinstallation heruntergeladen werden. Das ist immer dann nützlich, wenn der Server selbst keine Verbindung zum Internet aufbauen darf. Die folgenden Codezeilen zeigen das dazu notwendige PowerShell-Kommando:

webpicmd /offline /Products:WorkflowManagerRefresh
/Path:C:\InstallFiles\WorkflowManager

Wurden die Dateien erfolgreich geladen, kann die Installation über das nachfolgende Kommando gestartet werden:

webpicmd /Install /Products:WorkflowManagerRefresh /XML:C:\ InstallFiles\WorkflowManager\feeds\latest\webproductlist.xml

Wie auch immer die Installation gestartet wurde, wird man anschließend von einem Einrichtungsassistenten begrüßt. Für eine einfache und schnelle Bereitstellung auf einer Entwicklermaschine ist die erste Option „Configure Workflow Manager with Default Settings“ völlig ausreichend. Auf der folgenden Einstellungsseite müssen lediglich eine Datenbankverbindung, ein Dienstbenutzer sowie ein Passwort für das Zertifikat angegeben werden. Als Dienstbenutzer sollte ein separater neuer AD-Benutzer angelegt und verwendet werden. Um Probleme mit SSL-Zertifikaten zu umgehen, kann auf einer Entwicklermaschine die Option „Allow Workflow management over http on this computer“ ausgewählt werden. Nachdem alle Angaben getätigt wurden, erfolgt auf der nächsten Seite des Installationsassistenten eine Zusammenfassung der Einstellungen. Ist alles in Ordnung, kann die Installation gestartet werden. Nach erfolgreicher Ausführung erfolgt eine kurze Übersicht über den Installationsverlauf.

Abb. 2: Installation über den Platform Installer starten

Abb. 2: Installation über den Platform Installer starten

Registrieren und Test der Workflowumgebung

Nach der Installation des Workflow Managers unterstützt der SharePoint Server 2013 jedoch noch nicht sofort die neuen Workflows. SharePoint muss zunächst mit der neuen Workflowausführungsumgebung verbunden werden. Dafür ist das nachfolgende SharePoint-PowerShell-Kommando verantwortlich:

Register-SPWorkflowService -SPSite "http://sp2013dev/de" -WorkflowHostUr
i "http://sp2013dev:12291" -AllowOAuthHttp -force

Das Kommando erwartet den URL der SharePoint-Site sowie den URL des Workflow Managers. Um eine Kommunikation ohne SSL zu erlauben, kann noch zusätzlich der Parameter AllowOAuthHttp mitgegeben werden. Das Kommando endet in der Regel ohne eine Rückmeldung, außer natürlich im Fehlerfall. Um nun zu überprüfen, ob die Installation auch wirklich erfolgreich war, kann testweise ein neuer Workflow für die 2013-Umgebung angelegt werden. Am einfachsten kann das über den SharePoint Designer erfolgen. Dazu den SharePoint Designer und die SharePoint-Site öffnen, die für die Workflowregistrierung verwendet wurde. Anschließend im linken Bereich Workflow auswählen und aus dem oberen Menüband die Aktion Site Workflow auswählen, wie es auch Abbildung 3 verdeutlicht. Im nun geöffneten Dialog „Create Site Workflow“ befindet sich im unteren Bereich eine Auswahl der möglichen Workflowplattform. Ist in der Auswahlliste der Eintrag „SharePoint 2013 Workflow“ vorhanden, waren die Installation und die Registrierung erfolgreich.

Abb. 3: Anlage eines neuen Workflows

Abb. 3: Anlage eines neuen Workflows

Zusammenfassung

Die Bereitstellung der Workflowausführungsumgebung ist unter SharePoint 2013 komplexer geworden. Reichte in der Vergangenheit die Installation des SharePoint Servers aus, um Workflows verwenden zu können, muss nun eine separate Umgebung eingerichtet und konfiguriert werden. Dadurch wird aber eine verbesserte Prozessisolation erreicht, die sich wiederum positiv auf die Stabilität der SharePoint-Farm auswirkt. Durch die Möglichkeit der entfernten Ausführung werden zudem eine bessere Skalierbarkeit und Lastverteilung erreicht. In der nächsten Ausgabe der SharePoint-Kolumne wird dann gezeigt, wie eigene Workflows umgesetzt werden können.

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 -