16. Februar 2018

Optimierung & Vereinfachung der SharePoint Workflows mit NINTEX


In dieser Blog-Reihe befassen wir uns mit einem mächtigen Drittanbieter-Tool, „NINTEX Workflows“ für den SharePoint, welches das Arbeiten optisch ansprechend, und im Gegensatz zu den integrierten SharePoint Workflows, vereinfacht darstellt. Schauen wir uns diese beiden Wörter einmal genauer an:

Workflows 

Workflows im SharePoint können die tägliche Arbeit um einiges erleichtern, indem sie Prozesse automatisieren und im Hintergrund Arbeit verrichten, die sonst von einer einzelnen Person ausgeübt werden würde. Sprich, E-Mails verschicken, Personen informieren, Inhalte einpflegen, Elemente anlegen, Seiten einrichten, Berechtigungen setzen, Genehmigungen einholen – Der Fantasie sind hier nur wenige Grenzen gesetzt.

NINTEX 

NINTEX ist laut Herstellerseite "ein einfacher Point-and-Click Workflow", wodurch er im Vergleich zu den SharePoint Boardmitteln intuitiv zu bedienen ist. Durch die grafische Aufbereitung lassen sich Prozesse außerdem leicht strukturiert darstellen. (Das Lizenzmodell und weitere Informationen finden Sie auf www.nintex.de)

Verdeutlichen wir die Funktionalität am besten mit einem konkreten Beispiel:


Ein Kunde wünscht sich die Möglichkeit, auf seinem SharePoint Projektseiten anhand weniger Angaben in einer Liste automatisch anlegen zu lassen. Dabei soll es eine "externe Projektseite" geben, auf die alle Mitarbeiter Zugriff haben und eine "interne" auf der nur die Projektmitglieder arbeiten dürfen. Projektseiten bedeuten in diesem Fall, dass wir SharePoint Seiten mit Listen und Bibliotheken, die für die tägliche Arbeit im Projekt interessant sind, zusammengestellt und diese als Vorlagen gespeichert haben.


Für die Integration dieser Anwendung, legen wir eine Unterseite mit dem Namen „Projekte“ an und hierauf eine Liste mit der Bezeichnung "Übersicht Projekte".



Wenn der Nutzer ein neues Element anlegen will, wird ihm folgende Eingabemaske angezeigt:


Hier kann der User den Titel des Projekts angeben, eine Projektnummer, eine Beschreibung und falls bereits bekannt, auch Projektteilnehmer. Das Feld für Tags ermöglicht außerdem die Eingabe von Projektthemen und der Status des Projekts ist interessant für die mögliche Archivierung von inaktiven Projekten.

Sobald der Nutzer auf "Save" klickt, beginnt der dahinterliegende NINTEX Workflow zu arbeiten und erstellt die Projektseiten.

Der NINTEX Workflow 

Über "Create a Workflow in Nintex Workflows" oder "Manage Workflows with Nintex Workflows", können neue Prozesse angelegt oder vorhandene verwaltet werden. Wir öffnen nun den bestehenden Workflow:




NINTEX ist in der grafischen Darstellung ein Flussdiagramm. Der Prozess startet im oberen Teil unter dem grünen Pfeil und läuft in der Regel bis zur letzten "Aktion" nach unten bis zum roten Stopp-Zeichen. Alle möglichen Aktionen werden bei Nintex auf der linken Seite der Oberfläche angezeigt:


Die Aktionen können nach Kategorien gefiltert, und sobald eine Entscheidung für eine Funktion gefallen ist, per Drag & Drop auf die rechte Seite in das "Flussdiagramm" gezogen werden. Die Benutzeroberfläche ist übersichtlich gestaltet und bietet dadurch auch für Workflow Einsteiger die Möglichkeit, schnell einfache Prozesse abzubilden.

In unserem Beispiel sehen die Prozessschritte wie folgt aus:


Im ersten Schritt prüfen wir, ob die Projektnummer ein Leerzeichen enthält und entfernen dieses gegebenenfalls mit der Nutzung von "Regulären Ausdrücken" (Action: Regular expression), da sie anschließend für die URL der neuen Seite eingesetzt wird und hier Leerzeichen zu einem Fehler führen würden.
Danach nutzen wir die Nintex Action "Create Site" um die eigentliche Seite anzulegen. Wir übernehmen hier die Parameter aus der Liste. Also den Titel, die Projektbeschreibung, den Seitenbesitzer und den URL Namen, der in unserem Fall der Projektnummer entspricht.

Im Vorfeld haben wir für die externe und die interne Seite jeweils eine Vorlage erstellt, die hier jetzt entsprechend ausgewählt werden kann (Punkt "Template"). 

Im Anschluss speichern wir die URL in eine Variable (Action: Set Variable), und aktualisieren die Liste "Übersicht Projekte" mit dem Link zu der neuen Seite (Action: Update item).


Action: Update item

Durch die Syntax: "URL, Title", wird die URL in der Liste mit dem Titel der Seite und nicht mit der absoluten URL angezeigt.



Ergebnis:


Wenn die Seite angelegt wurde, werden die Berechtigungsgruppen für die neue Seite über den Workflow angelegt. 
Wir legen für jede Projektseite eine Reader-, eine Member- und eine Owner-Gruppe an.
 Dafür Speichern wir unsere Wunschnamen für die neuen Gruppen zunächst in Variablen:


Die eigentliche Gruppe wird anschließend über einen Web Service Aufruf (Action: Call web service) angelegt. Dafür muss die URL der Seite eingegeben und die Web Method "AddGroup" ausgewählt werden.
Die URL der Seite lesen wir mit der Variablen $URL aus, die wir zuvor gespeichert hatten. Für einen Web Service Call muss ein Administrator Account mit mindestens "Full Control" Rechten angegeben werden. 

Der "groupName" kommt aus unserer zuvor definierten Variable, der "ownerIdentifier" entspricht dem späteren Gruppenbesitzer und kann auch aus einer Variable ausgelesen werden, der "ownerType" ist group und der "defaultUserLoginName" ist die Person, die initial der Gruppe hinzugefügt werden soll. Die Beschreibung lesen wir auch aus einer Variable aus.

Wenn alle Gruppen angelegt wurden, werden Ihnen noch die entsprechenden Berechtigungen übertragen.


Auch dies wird über die Action "Call web service" realisiert.



Hier wird allerdings nun die Methode "AddPermission" aufgerufen. Übergeben werden muss der Titel der Seite, der "ObjectType", der "Web" entspricht und der Name der Gruppe, sowie den "permissionType", der "group" als Parameter benötigt und zuletzt die "permissionMask", die der sogenannten "Role Definition ID" entspricht. Mit dieser Zahlenkodierung sind die Standard Berechtigungsstufen im SharePoint festgelegt.

Beachten Sie: "Custom" Permission Level, also selbst angelegte Berechtigungsstufen, laufen derzeit im Web Service Aufruf, beim Setzen der Berechtigungen in einen Fehler. Der SharePoint Gruppe wird dann eine automatisch angelegte Ersatzberechtigung zugewiesen, mit dem Namen "Auto-generated Permission Level <GUID>", diese ist allerdings stark eingeschränkt.  Dies ist ein Microsoft SharePoint Fehler und kann derzeit nur durch das Schreiben eines eigenen Webservices behoben werden. (Quelle: https://community.nintex.com/thread/14807-auto-generated-permission-level)










Da in unserem Beispiel die "externe Seite" für alle Nutzer des Intranets sichtbar sein soll, sind die Gruppen der darüberliegenden Seite lesend und nur die Owner-Gruppe der Projektseite schreibend berechtigt. Auf der internen Projektseite sind nur die Projektgruppen berechtigt und die Projekt-Member haben schreibenden Zugriff.
Wenn alle Gruppen berechtigt wurden, wiederholen wir alle vorherigen Schritte für die Interne Projektseite. Jedoch wird diese unter der zuvor angelegten Seite erstellt und beruht auf einer anderen Projektseitenvorlage.


Wenn auch hier alle Gruppen berechtigt wurden, folgt nur noch ein letzter Schritt, bei dem wir die User, die beim ursprünglichen Listeneintrag als Projektmitglieder angegeben wurden noch der entsprechenden Gruppe hinzufügen.

Auch hierfür wird ein Web Service Call generiert. Den "userLoginName" lesen wir dabei aus dem Listeneintrag aus:





Das Ergebnis:


Link zur Seite, der nach ca. 30 Sekunden erscheint:


Externe Projektseite:


Berechtigungen externe Seite:


Interne Projektseite:



Berechtigungen interne Seite:


User werden per Workflow in die Gruppen gesetzt:


Nutzen Sie bereits NINTEX, aber benötigen noch Unterstützung bei der Einsatzweise? Sind oben genannte und gezeigte Anwendungen etwas, was Sie sich in Ihrem Unternehmen vorstellen können?
Dann kontaktieren Sie uns: wir stehen Ihnen gerne beratend zur Seite, um eine für Sie passende Lösung zu entwickeln.





0 Kommentare: