Communardo Techblog

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…

Bei der Arbeit mit dem Microsoft Office Sharepoint Server 2007 oder den Windows Sharepoint Services 2007 treten gelegentlich Fehler auf, die leider nur mit nichtssagenden Fehlermeldungen quittiert werden. Bekannte Beispiele sind u.a. „File not found.“ oder „Unexpected Exception.“. Dieser Artikel gibt einen Überblick, an welchen Stellen die wirklichen Fehler gefunden werden können und unterstützt den Entwickler oder Administrator somit bei der Fehlersuche.

1. Fehlermeldung vorhanden?

Als Erstes ist zunächst die Fehlermeldung, die Sharepoint im Browser anzeigt zu untersuchen. Gelegentlich werden Fehlercodes (z.B. „HRESULT“) angegeben, die einen ersten Hinweis auf den realen Fehler geben können. Auch eine Internet-Recherche mit der fehlgeschlagenen Aktion und der Standard-Fehlermeldung kann hilfreich sein, wenn das Problem häufiger auftritt.

2. Sharepoint Log durchsuchen

Der zweite Schritt ist ein Blick in die Logs, welche von Sharepoint erstellt werden. Diese befinden sich in der Regel im Ordner %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\12\LOGS. Dieser Ordner enthält eine Reihe von Log-Dateien. Am besten ist es, den Ordner nach dem Datum der letzten Änderung zu sortieren und die aktuellste Datei mit einem Editor zu öffnen. Innerhalb des Logs sollte von unten nach oben nach Begriffen wie „Exception“ oder „ERR“ gesucht werden. Ist der genaue Zeitpunkt bekannt, kann auch anhand dessen gesucht werden.

3. Windows Event Log

Weitere Informationen zum Fehler können sich auch im Event Log des Systems befinden. Dieser kann durch den Befehl „Eventvwr“ in der Kommandozeile aufgerufen werden. Unter „Application“ finden sich Anwendungsfehler, -warnungen und -informationen, die ggf. Aufschluss über den aufgetretenen Fehler und seine Ursachen geben können.

4. SQL Server Log

Im Log des eingesetzten SQL Server können Fehler gefunden werden, die von der Datenbank kommen. Dies sind insbesondere Probleme mit dem Datenbankserver oder fehlende Berechtigungen auf der Datenbank.

5. Best Practices Analyzer for WSS 2007 and MOSS 2007

Der BPA ist ein Tool zur Analyse der Sharepoint Installation und Konfiguration. Er untersucht die aktuelle Installation und gleich diese mit einigen Vorgaben („Best Practices“) ab. Weicht die aktuelle Version von diesen ab, werden entsprechende Hinweise zur Behebung der Probleme gegeben. Der BPA kann direkt bei Microsoft heruntergeladen werden:

http://www.microsoft.com/downloads/details.aspx?familyid=cb944b27-9d6b-4a1f-b3e1-778efda07df8&displaylang=en

Nach dem Download kann der BPA mit dem Befehl sharepointbpa –cmd analyze gestartet werden. Nach Abschluss der Analyse stehen eine HTML-Auswertung und ein Log zur Verfügung.

6. Sharepoint Spy

Mit Hilfe des Sharepoint Spys ist es möglich, die Konfiguration des Sharepoint Servers genauer zu untersuchen. Es werden sämtliche Einstellungen der einzelnen Komponenten angezeigt. Zudem besteht die Möglichkeit, die Konfiguration zweier Element direkt zu vergleichen. Der Sharepoint Spy kann nach Registrierung kostenlos heruntergeladen werden:

http://www.echotechnology.com/products/spy/Pages/default.aspx

Abbildung 1: Sharepoint Spy (Quelle: http://echotechnologie.com/products/spy)

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.