Kunden mit gültigem Software Assurance - oder Premium Support – Vertrag können ab sofort kostenlos auf die neue Version aktualisieren.

Nintex Workflow 2013 – Workflow for Everyone

Die wichtigsten Links:

• Nintex Workflow 2013 Product Website
• Nintex Workflow 2013 Product Flyer
• Nintex Workflow 2013 Installation Guide
• Nintex Workflow 2013 User Manual
• Nintex Workflow 2013 Upgrade Guide
• Nintex Workflow 2013 Download (Build 3.0.0.0,veröffentlicht am 17. Dezember 2012)

Interesse an SharePoint 2013 oder SharePoint Online? Auch dafür haben wir die passenden Ansprechpartner!

Ähnliche Beiträge:

• Nintex Workflow 2013 ab Dezember verfügbar
• SharePoint ULS Log Viewer jetzt mit ‘NINTEX-Ansicht’ und Exportfunktion
• Workflows in der Cloud

Click here to view the embedded video.

Anfang August letzten Jahres veröffentlichte Atlassian mit JIRA 4.4 bereits ein Release, in dem zahlreiche neue Funktionen und Änderungen enthalten sind. Hervorgehoben werden sollen an dieser Stelle insbesondere die neue Administrationsoberfläche sowie die Einführung neuer Operatoren für die Suche. Diesen Weg ist Atlassian mit JIRA 5.0 konsequent weitergegangen.

Für den Anwender bringt das neue Major-Release auf den ersten Blick im Vergleich zur Veröffentlichung von JIRA 4.4 relativ wenige Neuerungen mit.  Die drei Wichtigsten stellen die weiteren Artikel vor:

• Schnelles erstellen und bearbeiten von Vorgängen
• Teilen von Vorgängen und @mention Funktion
• Suche nach Vorgängen anhand der Vorgangshistorie

Für Entwickler und Administratoren werfen wir weiterhin einen etwas tieferen Blick hinter die Kulissen. Die beiden folgenden Blogbeiträge betrachten in erster Linie Änderungen und Verbesserung in JIRA, die  für den reinen Endanwender nicht direkt sichtbar sind. Für Pluginentwickler und Systemadministratoren bieten sich hier jedoch eine ganze Handvoll nützlicher Erweiterungen:

• JIRA 5.0 – Unter der Haube Teil 1
• JIRA 5.0 – Unter der Haube Teil 2

So können Sie SharePoint z.B. mit Office 365, Twitter, Bing & Co. verbinden. Im Prinzip mit allen Diensten, die eine Schnittstelle via Web Service zur Verfügung stellen.

Nintex agiert dabei als Cloud Service Broker (CSB) und bietet Unternehmen Sicherheit und Stabilität in einer sich schnell verändernden Umgebung.

Kurze Beschreibung aus dem “Special Report: Cloud Computing” von Gartner:

A successful cloud computing strategy often involves customizing services from one or more vendors. One way to do this is through an intermediary service provider: a Cloud Services Brokerage. A CSB can make it easier to consume and maintain cloud services, while reducing the cost and risk encountered when an enterprise tries to address these issues alone.

Nintex Live ist auf Microsofts Cloud Plattform Windows Azure gehostet.

Dort liegt der Katalog mit den verfügbaren Workflow-Aktionen, das Queue Management für Nachrichten und Fehlerbehandlung und die Service Wrapper, welche die Web Services externer Dienste so aufbereiten, dass sie als Workflow-Aktionen verwendet werden können und innerhalb von Nintex funktionieren.

Mit dem Nintex Live Connector for Nintex Workflow 2010, welchen Sie einfach auf Ihrer lokalen Installation von Nintex Workflow nachinstallieren, machen Sie Ihren Server Nintex Live-fähig.

Über eine eingebaute Katalog-Schaltfläche im Nintex Workflow Designer können sie (bei Bedarf auch erst vorher von Ihrer IT geprüfte und freigegebene) Workflow-Aktionen nachladen und Ihre lokale Installation mit der Cloud verbinden.

Arbeiten Sie beispielsweise lokal mit Ihren Kollegen an einem Dokument und stellen Sie dieses anschließend auf Office 365 / SharePoint Online zur Verfügung.

Dazu öffnen Sie einfach den Nintex Live Catalog im Nintex Workflow Designer und klicken bei “Office 365 – SharePoint upload file” auf “Add”. Die neue Workflow-Aktion steht anschließend unter “Workflow Actions > Nintex Live” zur Verfügung. Mit wenigen Handgriffen tragen Sie nun noch die entsprechenden URLs und Zugangsdaten ein und schon steht Ihnen im Kontextmenü Ihrer Dokumentbibliothek eine neue Aktion wie “Publish to Office 365” zur Verfügung. (Mike Fitzmaurice, Vice President – Product Technology at Nintex, zeigt das sehr anschaulich in einem fünfminütigen Video)

Nintex Live verbindet SharePoint mit der Cloud:

• Katalogisierte und verwaltete Cloud-Ressourcen, Download und Installation bei Bedarf (und auf Wunsch auch erst nach Freigabe durch die interne IT)
• Verwenden Sie Cloud-Ressourcen wie normale Workflow-Aktionen
• Sie können auch eigene Service Wrapper erstellen und im Katalog der Cloud zur Verfügung stellen
• Verteilte Workflows über SharePoint-Farmen hinweg sind so z.B. möglich

Wenn Sie eine Nintex Workflow Software Assurance abgeschlossen haben, steht Ihnen Nintex Live bereits zur Verfügung.

Weitere Informationen finden Sie unter:
http://www.nintex.com/en-US/Products/Pages/NintexLive.aspx

Download: Nintex Live – Installationspaket und Dokumentation (nur für angemeldete Benutzer)

Communardo unterstützt Sie als Nintex-Partner gern!

Ihr Ansprechpartner:

Andreas Eckstein
Microsoft Solutions
+49 (351) 833 82-233
andreas.eckstein@communardo.de

Bildquelle: Enable Workflows in Hybrid Deployments of SharePoint on Premise and in the Cloud (Video)

Die Veranstaltung war mit mehr als 100 Zuhörern sehr gut besucht. Laut Zählung der Organisatoren war es sogar die bisher bestbesuchte JUG Saxony-Veranstaltung überhaupt.

Der Vortrag war sehr umfangreich, so dass ich die vollen drei Stunden der geplanten Zeit ausgenutzt und mich im Anschluss noch mit einigen interessierten Besuchern weiter zum Thema unterhalten habe. Da der Raum auch nach einer Pause noch gut gefüllt war, gehe ich davon aus mein Publikum nicht gelangweilt zu haben.

Den Vortrag begann ich mit einer Auswertung der früher in diesem Jahr durchgeführten Vorbefragung und ging nach einem Vergleich von zentraler und verteilter Versionskontrolle direkt zum eigentlichen Thema – dem verteilten Versionskontrollsystem Git – über.

Neben der Vorstellung einiger essentieller Git-Kommandos ging es vor allem um die Verbindung von Git mit gängigen Werkzeugen wie Eclipse, Atlassian JIRA, Jenkins CI und weiteren.

Im Laufe des Vortrages bin ich auf einige mögliche Repositorystrukturen und Workflows, die sich mit Git realisieren lassen, eingegangen und habe insbesondere Vincent Driessens “Successful Git Branching Model” mit Unterstützung von git-flow vorgestellt. Der Workflow-Teil war dem bisher erhaltenen Feedback zufolge der für die Zuhörer interessanteste Teil. Ansatzweise habe ich auch einen Workflow mit Gerrit-Code-Review angesprochen, bin dort aber aufgrund der fortgeschrittenen Zeit nicht mehr zu einer Demonstration gekommen.

Für alle die nicht dabei sein konnten, gibt es die Slides zum Vortrag bei Scribd sowie ein paar Fotos auf der Facebook-Seite der Java User Group Saxony.

Für mich war das der erste Vortrag vor so großem Publikum. Ich bin begeistert vom großen Interesse der Zuhörer und bedanke mich für das positive und konstruktive Feedback.

Im Bereich der Fluss-Diagramme findet man das Template Microsoft SharePoint Workflow. Auf Basis dieses Templates soll nun exemplarisch ein Workflow erstellt werden.

Hat man auf Basis des Templates eine neue Zeichnung erstellt, kann man direkt mit der Erstellung des Workflows beginnen. Wenn man schon mit Flussdiagrammen gearbeitet hat, ist die Handhabung recht einfach.

Der Anwendungsfall im Beispiel soll ein einfacher Urlaubsantrag sein. Mitarbeiter sollen in der Lage sein, Urlaubsanträge zu erfassen. Dieser soll zur Genehmigung einem Mitarbeiter der HR-Abteilung vorgelegt werden. Im Anschluss daran wird der beantragende Mitarbeiter über den Status seines Antrags informiert.

Um dies zu designen zieht man einfach die entsprechenden Shapes auf die Zeichnung und verbindet diese Shapes dann. Um die Lesbarkeit zu erhöhen und Aufgaben näher zu spezifizieren kann und sollte man die Standard-Texte anpassen.

Vor dem Export sollte man mit Hilfe des Menüpunktes “Diagramm überprüfen” einen Check auf Probleme durchführen. Ein Klick auf “Exportieren” erzeugt eine VWI-Datei, die als Austauschformat dient.

Schaut man sich diese Datei etwas näher an, wird man feststellen, dass sie den Workflow als VDX-Datei, als auch als XOML-Datei beinhaltet.

In meinem Beispiel gibt es 2 Listen: Die Benutzerdefinierte Liste Urlaubsanträge beinhaltet die Urlaubsanträge, die Kalenderliste Urlaubskalender beinhaltet die genehmigten Urlaube in der Übersicht.

Um aus der Visio-Zeichnung nun einen SharePoint-Workflow zu generieren, wird SharePoint Designer 2010 benötigt. Hier kann man die eben erstellte Austauschdatei importieren. In meinem Fall soll der Workflow als Listenworkflow an die eben genannte Liste Urlaubsanträge gebunden werden.

SharePoint Designer erzeugt nun einen Workflow, der schon der grundlegenden Struktur aus der Visio-Zeichnung entspricht, nun aber noch von einer technisch versierten Person mit Leben gefüllt werden muss.

Man sieht, dass als Hilfestellung die geänderten Beschriftungen aus Visio übernommen wurden.

Erster Schritt im Workflow ist die Prüfung auf einen genehmigungspflichtigen Urlaubsantrag. Hier könnte man den Inhaltstyp abfragen. In diesem Fall gibt es ein Feld Typ und wenn hier “Sonderurlaub” steht, soll eine Genehmigung erfolgen. Die Einrichtung ist recht selbsterklärend.

In den Workflow-Einstellungen kann man nun noch definieren, wann der Workflow starten soll (z.B. sobald ein Eintrag erstellt wurde) – das ist ja schon aus SharePoint bekannt.

Der Workflow kann nun auch wieder nach Visio exportiert werden. Es entsteht dabei wieder eine VWI-Datei, die in Visio importiert und weiter bearbeitet werden kann. Im Beispiel könnte man nun noch eine Eingangsbestätigung zu Beginn des Workflows versenden. Dazu wird der Workflow einfach im Visio geändert, exportiert und erneut in SharePoint Designer geöffnet.

Wie man sieht, sind alle Einstellungen noch enthalten, die neu hinzugefügten Schritte müssen nur noch bearbeitet werden.

Zusammenfassend kann man sagen, dass die Erstellung von Workflows per Visio in meinen Augen eine schöne Möglichkeit ist, von fachlicher Seite her zu definieren wie ein Prozess ablaufen soll. Die technische Umsetzung muss nach wie vor ein Entwickler oder Power-User durchführen.

Eine solche Aufgabe hat nicht nur die Standardeigenschaften wie einen Titel oder eine Beschreibung sondern auch erweiterte Eigenschaften. Das praktische daran ist, dass diese kein eigenes Feld in der Liste benötigen sondern die Daten in den bereits vorhandenen Feldern gespeichert werden.

Und wenn man weiß, wie es geht, ist der Zugriff auf diese Daten auch sehr einfach.

1.) bei der Erstellung
Während der Erstellung der Aufgaben verwendet man in der Regel den Typ WssTaskActivity. Dieser verfügt bereits über eine Eigenschaft ExtendedProperties, die vom Typ Hashtable ist und in die man seine gewünschten Daten schreiben kann.

createTask.TaskId = Guid.NewGuid();
createTask.TaskProperties.Title = "Bitte genehmigen";
createTask.TaskProperties.ExtendedProperties["AdditionalText"]
    = "Bitte persönlich bearbeiten!";

2.) über den Item der TaskList

Möchte man nun später noch einmal darauf zugreifen, sieht man sich vor die Aufgaben gestellt, die Daten wieder aus dem SPListItem der TaskList zu lesen und nach der Änderung auch wieder zu schreiben. Sieht man sich das SPListItem genauer an, das die Aufgabe repräsentiert, so erkennt man, dass es ein Feld ExtendedProperties enthält, in dem die Daten auch enthalten sind – allerdings sind hier einfach die XML-Attribute die die Eigenschaften repräsentieren angegeben:

"AdditionalText='Bitte persönlich bearbeiten!' Department='Einkauf'"

Die große Frage ist jetzt, wie man einfach auf diese Daten zugreift, diese verändert und wieder abspeichert. Die Hashtable die bei der Erstellung wäre hierfür ein adäquates Objekt, das hier aber wie es zunächst scheint nicht vorhanden ist. Aber man muss hier nicht verzagen – auch dafür gibt es eine bereits vorhandene Lösung, auf die man aber erst kommen muss. Der Typ SPWorkflowTask aus dem NameSpace Microsoft.SharePoint.Workflow verfügt über 2 interessante statische Methoden: GetExtendedPropertiesAsHashtable hat als Rückgabewert genau die eben noch vermisste Hashtable und AlterTask verfügt über die Möglichkeiten, den Item mit den geänderten Daten auch wieder zu aktualisieren.

// get the extended properties hashtable
Hashtable taskItemExtProps = SPWorkflowTask.GetExtendedPropertiesAsHashtable(this.TaskListItem);
// write new values to the hashtable
taskItemExtProps["AdditionalText"] = "Mein Kommentar: genehmigt!";
// update the task item with new values
SPWorkflowTask.AlterTask(this.TaskListItem, taskItemExtProps, true);

Hier die Schritt-für-Schritt-Anleitung:

1. ASPX-Seite oder Webpart zum Anlegen des List-Items
Zum Anlegen des List-Items, für den der Workflow gestartet werden soll, kann ein einfaches ASPX-Formular oder ein Webpart zum Einsatz kommen. Dem Formular muss als Parameter die Listen-ID mitgegeben werden.

2. Anlegen der Eingabefelder für das Listenelement
Das ASPX-Formular sollte nun alle Datenfelder abfragen und ein neues Listenelement mit entsprechenden Werten anlegen. Dies muss unbedingt mit erhöhten Privilegien geschehen:

SPSecurity.RunWithElevatedPrivileges(delegate()

{

    using (SPSite site = new SPSite(web.Site.ID))

    {

    // implementation details omitted

    }

});

Zu beachten ist, dass keine Kontext-Objekte (SPContext) verwendet werden dürfen, da diese mit den Rechten des aktuellen Nutzers laufen.

3. Weiterleitung zum Instatiation-Form
Nachdem das Item angelegt wurde (Update nicht vergessen), kann der Workflow gestartet werden. Voraussetzung ist, dass dieser bereits mit der Liste verknüpft ist und neue Instanzen gestartet werden dürfen. Der Aufruf des Instantiation-Form erfolgt mittels Response.Redirect. Folgende Url muss übergeben werden:

"_layouts/IniWrkflIP.aspx?List=<listID>&ID=<itemID>&TemplateID=<WFAID>&Source=<webUrl>"

Folgende Parameter müssen ersetzt werden:
<listID> – ID der Liste (siehe 1.)
<itemID> – ID des soeben erzeugten Items (siehe 2.)
<WFAID> – ID der WorkflowAssoziation (diese hängt an der Liste)
<webUrl> – Url an die weitergeleitet wird, nachdem der Workflow gestartet wurde

Den Rest erledigen Infopath und die aufgerufene ASPX-Datei.

Um das Deployment während der Entwicklung zu beschleunigen, kann direkt nach dem Build eine Batch-Datei ausgeführt werden, die diese Aufgabe übernimmt. Post-build events werden direkt in den Projekteigenschaften unter “Build Events” konfiguriert. Um eine Batch-Datei aufzurufen ist folgender Befehl notwendig:

call “$(ProjectDir)\PostBuildEvent.bat”

Um die Batch-Datei möglichst generisch zu gestalten stehen diverse Makros zur Verfügung, die als Parameter übergeben werden können.

Folgende Aktionen sind per Batch auszuführen:

1. Assembly zum GAC hinzufügen mittels GACUtil
2. Kopieren von Dateien in den 12-Ordner von Sharepoint
3. Kopieren von Dateien direkt in die Sharepoint-Datenbank. Dies kann mittels UNC-Pfad geschehen. Bsp: \\server\website1\documents
4. Deaktivieren des Features
5. Deinstallieren des Features
6. Installieren des Features
7. Aktivieren des Features
8. IISRESET

Sollte es nur ein Webpart sein, können die Punkte 4-7 ausgelassen werden. Alternativ kann die DLL auch ins BIN-Verzeichnis von Sharepoint kopiert werden, anstatt sie im GAC zu deployen. Die Verzeichnisse können mittels Umgebungsvariablen und der oben bereits erwähnten Makros systemunabhängig ermittelt werden. Mit dem eigenen Deployment lässt sich während der Entwicklung viel Zeit sparen…

Zuerst werde ich jedoch kurz beispielhaft die manuelle Vorgehensweise vorstellen: Ausgangspunkt ist ein Sharepoint-Workflow, der mit Visual Studio entwickelt wurde. Auf dem Entwicklersystem geschieht das Deployment mittels des Visual Studio-Plugins vollautomatisch. Soll der Workflow nun auf einem fremden System deployed werden, sind eine Reihe von Schritten notwendig:

1. Compilieren des Projekts
2. Kopieren/Installieren der Assembly auf das Zielsystem
3. Kopieren der Feature-Dateien auf das Zielsystem
4. Ggf. Deaktivieren/Deinstallieren des vorhandenen Features
5. Installieren/Aktivieren des Features auf dem Zielsystem
6. IISRESET

Die einzelnen Schritte lassen sich durchaus scripten, aber eine einfache und elegante Deployment-Möglichkeit wird dadurch nicht geschaffen. Abhilfe schaffen hier zwei Open-Source-Tools: WSPBuilder und SharepointInstaller.

Der WSPBuilder erstellt aus einer vorgegebenen Struktur eine WSP-Datei. Im Wesentlichen müssen nur die notwendigen Dateien in eine Sharepoint-ähnliche Ordnerstruktur (12/…) kopiert und das Programm gestartet werden. Es können alle Dateien automatisch deployed werden, die unter dem 12-Pfad liegen müssen. Assemblies müssen in ein spezielles Verzeichnis namens GAC kopiert werden, damit Sie automatisch in den Assembly Cache deployed werden. Der WSPBuilder ist sehr gut per Kommandozeile konfigurierbar. Sinnvoll ist es, den Namen der Solution (WSPName) sowie den Ausgabepfad selbst festzulegen (OutputPath). Letzteres ist insbesondere für die Nutzung des SharepointInstallers hilfreich. Die Kommandozeilenoptionen können mit Hilfe des Parameters /? abgerufen werden.

Die nun vorhandene WSP-Datei kann mit dem Sharepoint-eigenen Tool STSADM deployed werden. Einfacher ist es aber, den SharepointInstaller zu verwenden. Dieser bietet eine Standard-Installationsoberfläche und prüft zudem ob bestimmte Voraussetzungen für die Installation von Sharepoint-Solutions vorhanden sind. Für die Installation sind drei Dateien notwendig: setup.exe, setup.exe.config und die zuvor erstellte Solution. Alle Parameter für das Setup können in der config-Datei eingestellt werden. Besonders wichtig ist die Solution-ID, welche der WSPBuilder im gleichen Verzeichnis wie die Solution ablegt. Genauere Informationen zur Konfiguration enthält die Readme-Datei.

Das vorhandene Setup-Paket kann nun ausgliefert und installiert werden. Es werden alle Features aktiviert. Beim Ausliefern eines Updates oder eines Patches kann ebenfalls der SharepointInstaller verwendet werden. Während der Installation muss hier Repair ausgewählt werden.

Entwickelt wurde ein automatisch ablaufendener Workflow für den MOSS 2007, der manuell sofort oder mit festgelegter Startzeit gestartet werden werden konnte. Um den verzögerten Start zu realisieren wurde eine DelayActivity eingesetzt.

Eine erste prototypische Implementierung zeigte einen interessanten Effekt: Der Workflow funktionierte ohne Probleme, wenn er sofort gestartet wurde. Kam jedoch die DelayActivity für einen verzögerten Start zum Einsatz, wurde der Workflow-Status sofort auf “Beendet” gesetzt. Die Aktionen, die laut Workflow ausgeführt werden sollten, blieben unbeachtet. Eine Fehlermeldung fand sich nur nach intensiver Suche im Sharepoint-Log:

DehydrateInstance: System.Runtime.Serialization.SerializationException: End of Stream encountered before parsing was completed.

Trotzdem in diesem Workflow keine InfoPath-Dokumente verwendet wurden, gab die Exception den entscheidenen Hinweis: Es gibt ein Problem mit der Serialisierung. Anders als im vorangegangen Blogeintrag lag das Problem nicht bei der Serialisierung der Daten, die von einem Formular übergeben werden, sondern bei der Serialisierung des Workflows selbst. Eine Bereinigung bzw. Konvertierung der Attribute der Workflowklasse brachte letztlich den Erfolg. Hierzu sei anzumerken, dass besonders die Sharepoint-Klassen SP* in den meisten Fällen nicht serialisierbar sind.

Abschließend bleibt noch die Frage, warum der Fehler nur beim verzögerten Start des Workflows auftritt. Dies lässt sich mit der Grundfunktionalität der Windows Workflow Foundation erklären. Die in Sharepoint integrierte Workflow Runtime verwaltet alle Workflowinstanzen. Wird eine solche Instanz mittels einer DelayActivity angehalten, wird diese aus Speicher- und Performancegründen persistent ausgelagert. Für diese Auslagerung muss die Instanz natürlich serialisiert werden. Ohne die DelayActivity wird die Instanz im Speicher gehalten, bis der Workflow beendet wurde. Der Fehler tritt also nicht auf.