Teil III: Audit- und Maßnahmenmanagement – How to: Parsen von XML einer Nintex Repeating Section
Im ersten Beitrag unserer mehrteiligen Blogserie haben wir Ihnen von unserem internen Projekt zur Optimierung der technischen Unterstützung unseres Audit- und Maßnahmenmanagements mit SharePoint Online und Nintex für Office 365 erzählt und eine allgemeine Zusammenfassung der Umsetzungsbestandteile beschrieben.
Beitrag verpasst? Lesen Sie hier Teil I – Audit- und Maßnahmenmanagement – Unser neues Audit-Tool.
In diesem Teil III betrachten wir den Prozessschritt der Auditdurchführung und werfen einen tieferen Blick auf die technische Umsetzung der Erfassung und Verarbeitung von Beobachtungen mit der Nintex Repeating Section (dt. wiederholender Abschnitt).
Zur Erinnerung: Im ersten Prozessschritt wird ein Audittermin als neues Element in der Auditliste erstellt. Via automatischem Nintex Workflow wird die Auditeinladung im iCalendar-Format an die teilnehmenden Personen übermittelt. Während des Audittermins trägt unsere Qualitätsmanagementbeauftragte (QMB) ihre Beobachtungen in das gleiche Formular ein, mit dem sie zuvor den Termin erstellt hat.
Die Repeating Section auf dem Auditformular
Bei der Auditdurchführung öffnet unsere QMB das Auditformular im Edit-Modus.
Im neuen Modus des Formulars werden nur die obigen Eingabefelder für die Termindaten eingeblendet. Im Edit-Modus ist zusätzlich die Repeating Section sichtbar. Die Repeating Section ist ein Bereich, in dem die dort enthaltenen Eingabefelder beliebig oft mittels neuer Zeile bzw. neuem Abschnitt wiederholt werden können. In unserem Use Case sammeln wir pro Abschnitt die Beobachtungsnummer, die Qualifizierung sowie die Beschreibung der Beobachtung. Über den Button „Neue Beobachtung“ wird eine neue Zeile mit diesen drei Eingabefeldern dem Formular innerhalb der Repeating Section hinzugefügt.
In den Konfigurationseinstellungen der Repeating Section im Nintex Forms-Designer wird die Anzahl der Abschnitte festgelegt. Es muss mindestens eine Zeile und es dürfen maximal 50 Zeilen in der Repeating Section existieren.
Während im Nintex Forms-Designer alle Eingabefelder außerhalb der Repeating Section direkt mit einer Spalte in einer SharePoint-Liste verbunden werden, werden die Felder innerhalb der Repeating Section nicht verbunden. Stattdessen wird die Repeating Section mit einer mehrzeiligen Textspalte (hier: RepSecBeobachtungen) verbunden und die Werte innerhalb des Steuerelements im XML-Format abgespeichert.
Parsen des XML-Codes der Repeating Section mit Nintex Workflow für Office 365
Alle Informationen über die Beobachtungen, die während des Audits erfasst wurden, liegen nun im XML-Format vor und diese sollen im nächsten Schritt in den Auditbericht integriert werden. Da der XML-Code nicht besonders leserlich ist, bereiten wir die Daten mittels Nintex Workflow für Office 365 auf. Hierfür nutzen wir die Query XML-Aktion.
In der Konfiguration der Workflowaktion geben wir die XML-Source an. In unserem Use Case ist dies die Listenspalte „RepSecBeobachtungen“, in der wir den XML-Code zuvor abgespeichert haben. Aus unserem XML-Code möchten wir als erstes die Beobachtungsnummern herausziehen. Die XPath query lautet entsprechend /RepeaterData/Items/Items/[Steuerelement-Identifier]. Um die richtige Steuerelementbezeichnung bzw. den Identifier herauszufinden, lohnt sich ein Blick auf den XML-Code. Dieser steht nämlich direkt vor und nach dem Wert, den wir herausziehen möchten, als öffnender und schließender Tag. Das Ergebnis wird als Text zurückgegeben und wird in einer Collection-Variable (coll_BeobachtungNr) gespeichert.
Folgender Screenshot zeigt Ihnen, auf welche Passagen des XML-Codes wir mit der Query zielen.
Anhand der blauen Markierung wissen wir, wie der Wert für unsere XPath query lauten muss. Die hier eher kryptische Bezeichnung kann je nach Nintex Software verschieden sein. Wir nutzen für unser Use Case Nintex Workflow für Office 365. In anderen Nintex Workflow-Versionen wie etwa Nintex Workflow 2013 on Premise werden die konkreten Steuerelementbezeichnungen angezeigt.
Die rot markierten Werte sind die Beobachtungsnummern, die in der Collection gespeichert werden:
coll_BeobachtungNr = [1, 2, 3, 4, 5]
Auf die gleiche Art konfigurieren wir im Workflow zwei weitere Query-XML-Aktionen für die Qualifizierung und die Beobachtungsbeschreibung. Im Ergebnis lauten die Collection-Variablen wie folgt:
coll_Qualifizierung = [Hinweis, Hinweis, Hinweis, Hinweis, Hinweis]
coll_Beobachtung = [Text1, Text2, Text3, Text4, Text5]
Nun haben wir alle Werte aus dem XML-Code herausgezogen, die zuvor in die Eingabefelder innerhalb der Repeating Section auf dem Formular eingetragen wurden, und haben diese je Steuerelement bzw. Datentyp in einer eigenen Collection gespeichert. Im nächsten Schritt möchten wir die zusammengehörigen Werte wieder verknüpfen. Hierfür bedienen wir uns einer Schleifenfunktion (For each loop).
Die Schleife wird für jeden Indexwert in der Collection „coll_BeobachtungNr“ durchlaufen. Die jeweilige Beobachtungsnummer sowie der Index selbst werden dabei in je einer Integer-Variablen zwischengespeichert.
Anhand der Indexvariable werden die nächsten beiden Workflowaktionen „Get Item from Collection“ durchlaufen und der entsprechende Wert aus den Collections „coll_Qualifizierung“ und „coll_Beobachtung“ in je einer Textvariablen zwischengespeichert.
Nach diesen Schritten haben wir folgende zwischengespeicherten Werte während des ersten Schleifendurchlaufs:
intBeobachtungNr = 1
intIndexBeobachtungNr = 0
txt_Qualifizierung = Hinweis
txt_Beobachtung = Text1
Diese Einzelwerte werden in der nächsten Aktion wieder in einer Variablen zusammengefügt. Da wir in den einzelnen Variablen unterschiedliche Datentypen vorliegen haben, erstellen wir eine Dictionary-Variable:
dic_BeobachtungNrQualifizierungBeobachtung = [1, Hinweis, Text1]
Die letzte Workflowaktion innerhalb des Schleifendurchlaufs „Add Item to Collection“ erstellt eine sog. komplexe Collection-Variable bzw. fügt dieser Werte hinzu. Am Ende jedes Schleifendurchlaufs wird das im Schritt zuvor erstellte Dictionary der Collection hinzugefügt. In unserem Beispiel wird die Schleife fünf Mal durchlaufen und die finale komplexe Collection hat zusammengefasst folgende Struktur:
coll_AlleWerteAusDictionary = [{1, Hinweis, Text1}, …, {5, Hinweis, Text5}]
Je nach Use Case ist dieser letzte Schritt nicht unbedingt erforderlich. Wir benötigen diese komplexe Collection in einem späteren Workflowschritt für die Generierung des Auditberichts.
Mehr dazu lesen Sie demnächst in Teil V unserer Blogserie.
Bleiben Sie neugierig und seien Sie gespannt!
Lesen Sie auch:
Teil I – Audit- und Maßnahmenmanagement – Unser neues Audittool
Teil II – Audit- und Maßnahmenmanagement – Die Auditeinladung als praktische iCalendar-Datei
Teil IV – Audit- und Maßnahmenmanagement – Nintex, don’t give me a break! HTML-Bastelei für übersichtliche Tabellen
Teil V – Audit- und Maßnahmenmanagement – Mit Nintex Document Generation zum automatischen Auditbericht