Nintex Inline-functions ausprobiert

Published on Monday, 30 October 2017

Nintex verfügt über inline functions, mit denen die übergaben einiger Workflow-Schritte (Schritte, die das Erfassen einer Referenz erlauben) noch angepasst werden kann.

Diese inline-functions sind recht schnell und einfach selber erstellt - dafür gibt es z.B. hier und hier Anleitungen.

Die beschriebenen Schritte sind zusammengefasst wie folgt:

  • eine statische Methode bereitstellen, für die Verarbeitung
  • die entsprechende DLL auf alle Nintex-Server im GAC installieren
  • Einen Funktionsalias in Nintex registrieren (über NWAdmin.exe bzw. Add-InlineFunction)

Mehrere Dinge finde ich an dem Vorgehen nicht optimal:

  • Warum müssen die DLLs auf allen Servern manuell in den GAC installiert werden
  • Warum muss mit einem weiteren Tool der Funktionsalias registriert werden?

Bei der Überlegung wie man dies in einen automatischen Prozess überführen kann - am besten so, dass ein Standard-SharePoint-Admin sich "wie zuhause" fühlt hatte ich die folgende Überlegung:

In diesem Fall würde das Deployment einer inline-function sich auf das bekannte Add-SPSolution und Install-SPSolution beschränken.

Für die Registrierung würde ich ein verstecktes Farm-Feature verwenden und die eigentliche Registrierung in SPFeatureReceiver.FeatureInstalled durchführen. (Bzw. die De-Registrierung dann in SPFeatureReceiver.FeatureUninstalling)

Es bleibt die Frage danach wie man denn in einem Event-Receiver den Funktionsalias an Nintex registriert. Die Antwort war recht schnell gefunden: Die Klasse Nintex.Workflow.Common.StringFunctionInfoCollection verfügt über die statische Methode Add.

public static void Add(string FunctionAlias, string AssemblyName, string NameSpace, string TypeName, string MethodName, string description, string usage, int lcid, bool hidden)

Die Parameter entsprechen 1:1 denen von NWAdmin.exe - mit der Ergänzung, dass die LCID -1 ist, wenn sie in NWAdmin nicht gesetzt wird. Auf diese Weise lässt sich Nintex einfach um inline-functions erweitern und das Ergebnis ist eine "schöne", SharePoint-Konforme Lösung, die auch jeder kritischen Überprüfung eines Kunden standhalten kann...

Ergänzen muss ich noch etwas zu der Sprache/LCID die bei der Registrierung verwendet wird.

  • Die Doku behauptet "Duplicate function aliases are not allowed, even if the locale identifiers are different." - dies ist nicht so: Ein Funktionsalias kann mehrfach, mit verschiedenen lcids registriert werden.
  • Die Anzeige der Inline-functions in Nintex ist lokalisiert, d.h. in einem Web der lcid 1031 werden auch nur (!) inline-functions angezeigt, die mit der lcid 1031 registriert wurden. In Mehrsprachigen Umgebungen ist es daher wichtig die inline-function für alle vorgesehenen Sprachen zu registrieren.
  • Die Standard-Sprache (englisch, in Nintex keine lcid) wird nur angezeigt, wenn es keine einzige (!) lokalisierte inline-function gibt. Daraus folgt
    1. dass man seine eigenen Funktionen nur lokalisieren sollte, für Sprachen die in Nintex bereits lokalisiert sind und
    2. für die lcid 1033 sollte nie (!) eine Lokalisierung angelegt werden.