Bei der Entwicklung komplexer Workflows für den SharePoint spielen auch Workflowaufgaben für die Benutzerinteraktion während der Ausführung des Workflows eine nicht unbedeutende Rolle.

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);

In verschiedenen Anwendungsfällen kann es vorkommen, dass eine Liste mit den dazugehörigen Einträgen dem Nutzer der Site verborgen bleiben soll. Trotzdem muss der Nutzer einen Workflow mit Instantiation-Form starten können und ein entsprechendes Listenelement anlegen können. Für diesen Beitrag wird von einem vorhandenen Infopath-Formular ausgegangen, welches als Instantiation-Form verwendet wird.

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.

Mit den Visual-Studio-Erweiterungen für Sharepoint wird der Entwickler schon sehr gut beim Deployment auf seinem Entwicklungssystem unterstützt. Ein Nachteil ist jedoch, dass der Deployment-Prozess recht lang dauert. Der Grund ist, dass der Workflow in eine Solution verpackt und deployed wird.

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…

Dieser Blogeintrag stellt eine Deployment-Variante für Sharepoint-Enwicklungen, wie z.B. WebParts oder Workflows, vor. Im Mittelpunkt stehen zwei Open-Source-Tools zur Erstellung und zum Deployment von Sharepoint Solutions.

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.

In einem Blogeintrag vom 20. Juli 2007 habe ich bereits über diese Fehlermeldung berichtet und einen Lösungsweg aufgezeigt. In einem aktuellen Projekt trat der Fehler jedoch erneut auf, diesmal mit einer anderen Ursache.

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.

In Visual Studio 2005 gibt es leider einen kleinen Bug in den “Extensions for WF”. Das Debuggen von Workflows, also nicht des Quellcodes, funktioniert oft nur schlecht oder garnicht. Häufig stürzt das Visual Studio sogar ab, wenn man versucht den Debugger an einen Prozess zu hängen, der Workflows verwendet. Einen solchen Prozess erkennt man recht leicht, indem man einen Blick auf den Typ wirft. Steht dort u.a. “Workflow” (siehe Abbildung) sollte man sich besser nicht an den Prozess hängen.

Verhindern lässt sich dieser Effekt indem man das Visual Studio bereits an den Prozess hängt, bevor die Assembly des Workflows geladen wurde, wobei ggf. vorher ein iisreset durchgeführt werden muss. Sobald die Assembly geladen wurde, lässt sich der Quelltext wie gewohnt debuggen.

Ein gängige Methode in der Workflowentwicklung für Sharepoint 2007 ist es, Infopath-Formulare zu verwenden. Um die Daten dieser Formulare komfortabel zu deserialisieren, werden in der Regel die von Infopath zur Verfügung gestellten XSD-Schemas mittels des XSD-Tools in Klassen umgewandelt. Bei der Weiterverwendung der generierten Klasse kann folgendender Fehler ggf. auch nur sporadisch auftreten:

DehydrateInstance: System.Runtime.Serialization.SerializationException: End of Stream encountered before parsing was completed.
at System.Runtime.Serialization.Formatters.Binary.__BinaryParser.Run()
at System.Runtime.Serialization.Formatters.Binary.ObjectReader.Deserialize(HeaderHandler handler, __BinaryParser serParser, Boolean fCheck, Boolean isCrossAppDomain, IMethodCallMessage methodCallMessage)
at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize(Stream serializationStream, HeaderHandler handler, Boolean fCheck, Boolean isCrossAppDomain, IMethodCallMessage methodCallMessage)
at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize(Stream serializationStream)
at System.Workflow.ComponentModel.Activity.Load(Stream stream, Activity outerActivity, IFormatter formatter)
(…)

Das Problem liegt hierbei nicht an den eigentlichen Daten, sondern an einem zusätzlichen Datenfeld, welches von Infopath erzeugt wird:

private System.Xml.XmlAttribute[] anyAttrField;

Da dieses mit keinem Attribut dekoriert ist, kommt es zu Problemen bei der (De-)Serialisierung. Abhilfe schafft das NonSerialized()-Attribut:

[NonSerialized()]
private System.Xml.XmlAttribute[] anyAttrField;

Bei der Entwicklung von Sharepoint-Workflows mit Visual Studio tritt diese Fehlermeldung häufig auf, wenn ein recht komplexer Workflow, z.B. durch hinzufügen umgebender Activities wie ‘while’- oder ‘if’-Activities, umgebaut wurde. Wie so oft liegt der eigentliche Fehler woanders als die Meldung vermuten lässt: Nicht die ‘Correlation value’ direkt ist das Problem, sondern die (Unter-)Eigenschaft ‘OwnerActivityName’. Diese muss immer die direkt darüberliegende Activity beinhalten, welche sich bei Änderungen am Workflow ebenfalls ändern kann. Nachdem diese Eigenschaft für alle Activities nachgepflegt wurde, sollte der Workflow wieder funktionieren.

Bei der Entwicklung von Workflows mit den WSS-Plugins für Visual Studio kommt es häufig vor, dass von einem Workflow nach dem Deployment keine neuen Instanzen mehr gestartet werden können. Der Workflow fehlt dann in der Auswahlliste, obwohl er ordnungsgemäß installiert und aktiviert ist. Ursache des Problems ist, dass der Workflow auf “Keine neuen Instanzen” gestellt wird, nach er deployed wurde. Die Option zur Reaktivierung des Workflows wurde von Microsoft in den Workfloweinstellungen unter “Workflow entfernen” bzw. “Remove Workflows” versteckt.

Wenn man schöne Vorlagen in Word oder Powerpoint gewohntermaßen als pot, potx, dot oder dotx abspeichert funktionieren Sie leider nicht als Vorlagen für Content Types in Dokumentbibliotheken im Zusammenhang mit Workflows.

Will man in einer Bibliothek durch einen Workflow ein Dokument auf Basis eines Content Types erstellen, muss als Vorlage für den Content Type ein normales Dokument (ppt, pptx, doc, docx) angegeben werden. Ansonsten ignoriert SharePoint die Vorlagendatei.

Außerdem beim Erstellen der Bibliothek darauf achten, das die richtige Office Version für den Dokumenttyp angegeben ist:

z.B. Microsoft Word Dokument für Office 2007 bzw. Microsoft Word 97-2003 Dokument für ältere Versionen.