SharePoint Kompendium - Bd. 16

Von Gunnar Krause, Benjamin Lanzendörfer, Stefan Mumalo und 5 weiteren

Das SharePoint Kompendium ist ein Sammelband unterschiedlicher Artikel rund um das Thema SharePoint. Dieser Band zeigt, wie mithilfer eigener Aktivitäten eigener Code in SharePoint-Workflows verwendet werden kann. Des Weiteren wird gezeigt, wie mit der WEBCON BPS Geschäftsprozesse optimiert werden und warum SharePoint 2016 Unternehmen noch produktiver macht. Ein weiterer Beitrag widmet sich dem Thema Microsoft Graph und wie in dessen Kontext Xamarin-Apps entwickelt werden. Den Abschluss bilden das PnP-Provisioning-Framework, das beim Provisionieren von Artefakten in einer hybriden SharePoint-Umgebung helfen kann, sowie Event Receivers.

• Sprache: Deutsch
• Herausgeber: entwickler.press
• Erscheinungsdatum: 28. März 2017
• ISBN: 9783868027754

Buchvorschau

geschützt.

Workflows mit eigenem Code (6)

Kolumne: SharePoint ganz praktisch

Marc André Zhou

Mit der Einführung der neuen Workflow Foundation 4 in SharePoint 2013 hat sich die Erstellung von Workflows erheblich verändert: Sowohl im SharePoint Designer also auch in Visual Studio stehen nur noch deklarative Bausteine für die Prozessdefinition zur Verfügung. Eine CodeBehind-Ansicht oder eine Custom-Code-Aktivität sucht man vergebens.

Microsoft hat mit Workflow Foundation 4 eine vollständig neue Bibliothek für die Umsetzung von Workflows bereitgestellt. Auch wenn aus der Versionsnummer geschlossen werden könnte, dass es sich um eine Aktualisierung der Vorgängerversion – der Workflow Foundation 3.5 – handelt, ist diese Vermutung falsch. Das bedeutet auch, dass vorhandene Workflows nicht einfach auf die neue Workflow Foundation Version 4 aktualisiert werden können. Der einzig mögliche Ansatz besteht hier in der Neuumsetzung der vorhandenen Workflows. Da einige Unternehmen jedoch sehr viele spezielle und auch umfangreiche Workflows in vorherigen SharePoint-Versionen umgesetzt haben, unterstützt SharePoint weiterhin die Ausführung von Workflows, die auf der Workflow Foundation 3.5 beruhen. Um das zu verdeutlichen, zeigt Abbildung 1 die möglichen Ausführungsumgebungen für SharePoint-Workflows. Im Schaubild ist auf der rechten Seite die neue Workflow-Ausführungsumgebung zu sehen. Der Workflow-Manager und der Windows-Azure-Service-Bus sind durch den Azure-Access-Control-Block (OAuth) gesichert.

Abb. 1: Ausführungsumgebungen für SharePoint-Workflows [1]

Auch wenn hier alle Komponenten Azure im Namen tragen, werden sie nicht unbedingt innerhalb der Azure-Cloud ausgeführt. Diese Komponenten können alle lokal auf dem eigenen geschützten Unternehmensserver installiert und betrieben werden. Der Workflow-Manager übernimmt die Ausführung der neuen Workflows. Die Kommunikation mit SharePoint erfolgt ausschließlich über eine REST-basierte Schnittstelle. Der Windows-Azure-Service-Bus ist für die Kommunikationsrichtung von SharePoint zur Workflow-Ausführungsumgebung zuständig. Über diesen Weg wird zum Beispiel ein Workflow dahingehend informiert, dass eine Aufgabe (Task) als erledigt (completed) markiert wurde.

Um die Ausführung älterer Workflows, die noch auf der Workflow Foundation 3.5 beruhen, kümmert sich der SharePoint-2010-Workflow-Host. Wie anhand des Schaubilds deutlich wird, liegt der alte Workflow-Host direkt in SharePoint. Das kann dazu führen, dass sich Fehler innerhalb eines (benutzerdefinierten) Workflows auf die gesamte SharePoint-Farm negativ auswirken. Daher hat sich Microsoft, analog zum App-Modell, zu einer Prozessauslagerung entschieden. Fehler, die nun innerhalb des neuen Workflow-Hosts auftreten, wirken sich nicht mehr direkt auf die SharePoint-Farm aus, da hier die Prozesse isoliert ausgeführt werden. Aus diesem Grund sollte der Workflow-Manager auch auf einer separaten Servermaschine betrieben werden, um einen optimalen Schutz zu erzielen.

Prozessisolierung erfordert Mehraufwand

Die Entkopplung der Prozesse und die damit erhöhte Stabilität sind natürlich nicht umsonst, sondern erfordern mehr Implementierungsaufwand. Eine direkte Kommunikation mit SharePoint ist nicht möglich, und eigener Code kann nicht mehr einfach innerhalb einer CodeBehind-Datei hinterlegt werden. Solange sich Logik und Anforderungen eines Workflows im überschaubaren Rahmen halten, kommt man mit den deklarativen Workflows aus. Erhöht sich jedoch die Komplexität, wird es mit den reinen deklarativen Möglichkeiten schwierig.

Um umfangreiche geschäftsbasierte Prozesse abbilden zu können, ist in der Regel eigener Code unverzichtbar. Oft steht dieser auch schon in speziellen unternehmenseigenen Programmbibliotheken (Assemblies) zur Verfügung und muss nur aufgerufen werden. Eigener Code kann in SharePoint-2013-basierten Workflows auf zwei Arten integriert werden: Die einfachste und schnellste Variante besteht darin, eigenen Code über einen Webdienst (Web Service) aufrufbar zu machen. Das hört sich zunächst einfach an, jedoch sind hier natürlich auch Sicherheitskriterien zu beachten – also: Wer darf welche Methoden aufrufen? Die zweite Möglichkeit besteht in der Umsetzung eigener Workflow-Aktivitäten.

Workflow Actions und Activities

SharePoint-Workflows bestehen im Grund aus einer Zusammenstellung von Workflow Actions und Workflow Activities. Workflow-Aktivitäten enthalten Code und definieren somit das Ausführungsverhalten von Workflows. Workflow Actions hingegen sind Wrapper um die vorhandenen Workflow-Aktivitäten und