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:
- Eine DLL die Teil einer SharePoint-Farm-Lösung ist, wird quasi automatisch in den GAC von allen SharePoint-Servern installiert.
- Ein Feature Event Receiver der Lösung könnte die Registrierung vornehmen
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
- dass man seine eigenen Funktionen nur lokalisieren sollte, für Sprachen die in Nintex bereits lokalisiert sind und
- für die lcid 1033 sollte nie (!) eine Lokalisierung angelegt werden.