Nintex – Vorgesetzte per LDAP-Abfrage ermitteln

Meine Sekretärin erledigt das für mich

Es ist der Klassiker der Workflows: Die Genehmigung.

Von der Freigabe von Dateien bis zum Urlaubsantrag – in vielen Workflows werden Genehmigungen eingeholt. Und wer genehmigt unsere Dokumente und Urlaubsanträge? Genau, der Vorgesetzte. Wie schön, dass Nintex uns die Möglichkeit bietet, den Vorgesetzten des Initiators direkt aus dem Workflow-Kontext zu beziehen – ein gepflegtes AD vorausgesetzt. Doch was tun, wenn der Antragsteller nicht der Initiator ist…?

Das Szenario

Den Vorgesetzten über den Benutzerkontext zu holen, ist ja schon fast ein alter Hut und wird auch häufig und gerne genutzt. Je nach Hierarchie im Unternehmen kann es aber vorkommen, dass der Antragsteller den Antrag gar nicht selbst initiiert, sondern von einer Schreibkraft oder einem Mitarbeiter stellen lässt; oder der Workflow muss noch zu einer zweiten Hierarchieebene springen, ohne erneut gestartet zu werden.
Und genau das bringt ein Problem für den Workflow-Entwickler, denn: Der Vorgesetzte wird immer auf den angemeldeten Benutzer bezogen.
OK, also nehmen wir ein User-Feld “Antragsteller”, befüllen es mit dem Default-Wert “[Ich]”. So muss der normale Antragsteller nichts verändern, aber bei Antragstellung durch eine dritte Person gibt es die Möglichkeit, jemand anderes einzutragen. Easy, oder?! Leider nicht. Denn… stellt diese(r) Dritte(r) einen Antrag für seinen/ihren Chef, läuft die Genehmigung nicht zu dessen Chef, sondern zu ihm selbst. Feld hin oder her, ausschlaggebend bleibt die am SharePoint angemeldete Person.
Eine Lösung für dieses Problem wäre, den Vorgesetzten beim Stellen des Antrags mit anzugeben. Und obwohl sich viele Angestellte sicher gerne selbst einen Chef aussuchen würden, wird diese Idee in der Regel abgelehnt. Auch die Weitergabe des Passworts, um sich für die Antragstellung als der Vorgesetzte einzuloggen, stößt selten auf Begeisterung. Also was tun?

Benutzer über LDAP-Abfrage direkt aus dem AD holen

Nintex Workflow 2013 bietet schon ab der Standard-Version die Möglichkeit, Abfragen direkt gegen das Active Directory zu stellen. Für die Abfrage des Vorgesetzten sind dabei zwei Abfragen nötig:
1) Hol mir das User Object des Antragstellers und merke dir seinen Vorgesetzten
2) Hol mir den Loginnamen des Benutzers (des Vorgesetzten), den du gerade in der anderen Abfrage gefunden hast.

Schritt 1: die Variablen

Wir benötigen drei: zwei Textfelder für den Loginnamen des Antragstellers und das User Objekt des Vorgesetzten und ein „Person oder Gruppe“-Feld für den Account des Vorgesetzten.

Schritt 2: Loginname des Antragstellers

Der Loginname in SharePoint 2013 setzt sich aus drei Teilen zusammen: Claim, Domäne und Username. Für die Abfrage benötigen wir nur den Username, der Rest muss weg!
Dafür verwenden wir zwei Aktionen: Variable setzen und Zeichenkette erstellen.

Zunächst speichern wir den Anmeldenamen des Antragstellers in eine der beiden Textwert-Variablen.

Anschließend ersetzen wir den Claim und die Domäne mit einem leeren String. Alternativ kann hier auch fn-Entfernen verwendet werden. Der Claim und die Domäne müssen selbstverständlich an die jeweilige Umgebung angepasst werden.

​Schritt 3: Abfrage des Vorgesetzten

Per LDAP-Abfrage können wir jetzt den Vorgesetzten ermitteln. Über das kleine Server-Icon neben dem LDAP-Pfad kann das Active Directory per Browser durchsucht werden.

​​(&(objectClass=user)(samaccountname={WorkflowVariable:AntragstellerLogin}))

Die Abfrage fragt das User Objekt für den Antragsteller ab. Als nachzuschlagende Eigenschaft wird das Feld Manager eingetragen und nach Klick auf Hinzufügen an die Variable ManagerLDAP übergeben.

Zurück kommt ein LDAP-User in diesem oder einem ähnlichen Format:

​CN=Username,CN=admin,DC=corp,DC=Fabrikam,DC=COM

Schritt 4: Den Zum Wörterbuch hinzufügen des Vorgesetzten ermitteln

Zum Schluss müssen wir den Accountnamen des User Objektes abfragen.

(&(objectClass=user)(distinguishedName={WorkflowVariables:ManagerLDAP}))

Als nachzuschlagende Eigenschaft interessiert uns diesmal der saMAccountName. Diesen können wir direkt in ein „Person oder Gruppe“-Feld schreiben.

Und das war’s! Dieses Vorgehen ist in vielen Szenarien denkbar und nützlich, zum Beispiel beim Weiterreichen eines Antrags über mehrere Hierarchie-Ebenen hinweg. Der Workflow muss dafür also nicht neu vom Vorgesetzten gestartet werden, sondern kann sich selbstständig durch die Hierarchie arbeiten.