Gerade mal wieder in die Falle getappt, möchte ich die Gelegenheit gleich nutzen um hier meinen ersten Beitrag zu liefern.
Es ist ja gar nicht so unüblich in bestimmten Situationen auf eigene ConfigSections in der Web.config einer SharePoint-WebApplication zugreifen zu wollen.
Ansich ja auch kein Problem - würde man meinen:
- zum Entwicklungszeitpunkt wird man von Visual Studio unterstützt (siehe app.config)
- zum Zeitpunkt des Verteilens der Solution durch die WSS-API
- und zur Laufzeit ist der Zugriff auf die Konfig-Einträge bestenfalls ein Ein-Zeiler
Doch was tun, wenn zur Laufzeit eines Custom Workflows in SharePoint plötzlich nicht mehr die in der Web.config eingetragenen Konfigurations-Werte verwendet werden, sondern jene die zum Entwicklungszeitpunkt als "Default"-Values in den Code (Settings.Designer.cs) generiert wurden und man ist sich absolut sicher, dass die richtigen Einträge in der richtigen Web.config untergebracht sind?
Nach einem Blick auf den Lebenszyklus eines SharePoint-Workflows habe ich dann die Ursache gefunden:
SharePoint-Workflows laufen ja grundsätzlich unter dem Worker Process "w3wp.exe" (da darunter ja die SharePoint-WebApplication läuft, die den Workflow "hostet"). Dauern Activities von Workflows länger (etwa die Delay-Activity, Task-Activities oder aber auch aufwändige, länger laufende CodeActivities, etc.), wird die Workflow-Instanz serialisiert und in der SharePoint-Datenbank abgelegt (de-hydriert) - sie verschwindet somit aus dem Speicher. Soll der Workflow zu einem späteren Zeitpunkt wieder fortgesetzt werden, wird er wieder "re-hydriert" - also aus der Datenbank geholt und wieder deserialisiert (siehe dazu auch diesen Artikel).
Um Ressourcen zu schonen werden die Workflow-Instanzen allerdings nicht immer vom "w3wp.exe"-Prozess verarbeitet, sondern ab dem Zeitpunkt des "Wieder-Aufweckens" übernimmt das "Windows SharePoint Services Timer"-Service (OWSTIMER.EXE) das Kommando. Der Schwellenwert, ab dem Workflow-Instanzen vom Timer-Service verarbeitet werden sollen, kann übrigens konfiguriert werden (siehe diesen Blog).
Und genau diese Systematik ist jedoch der Knackpunkt wenn aus Workflows auf die Web.config zugegriffen werden soll:
- Läuft der Workflow (noch) im Kontext des "w3wp.exe"-Prozesses sind die Konfig-Einträge aus der Web.config auch "greifbar"
- Läuft der Workflow allerdings in späterer Folge im Kontext von "OWSTIMER.EXE" ist (logischerweise) von einer Web.config weit und breit keine Spur
Die Lösung ist schlussendlich aber relativ simpel:
Einfach in den Ordner in welchem das Executable "OWSTIMER.EXE" liegt (12-hive\BIN) ein Konfig-File "OWSTIMER.EXE.config" ablegen, welches die gleichen eigenen ConfigSections enthält, die auch in der Web.config enthalten sind und schon kann es dem Workflow egal sein, im Kontext welchen Prozesses er ausgeführt wird.
Dennoch ist dabei etwas Vorsicht geboten:
- doppelter Konfigurations- & Administrations-Aufwand
- "eigene" Files in den SharePoint 12-hive\BIN reinzulegen - naja - ist meiner Meinung nach nicht gerade die feine englische Art...
Ach ja: bei Konfig-Änderungen einen Restart des Timer-Services nicht vergessen... ;-)