Communardo Techblog

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.