In diesem Artikel (http://sharepoint.namics.com/2007/04/26/moss_workflow/moss_workflow_limits.pdf) möchte ich erklären, warum die Workflow-Infrastruktur der Office SharePoint Services nicht für erweiterte oder kritische Geschäftsprozesse geeignet ist.

Dieser Artikel soll jedem als Hilfestellung bei der Entscheidung über die Verwendung der Workflow Infrastruktur in MOSS dienen, und gleichzeitig eine Grundlage für Diskussionen darstellen.

P.S.: Wie Microsoft sich das Zusammenspiel von MOSS und kritischen Geschäftsprozessen vorstellt, welche Rolle MOSS in "Enterprise Applications" spielt und was "Office Business Applications" sind, versuche ich in weiteren kommenden Artikeln zu veranschaulichen.

In einem älteren Post habe ich ein paar Grenzen aufgezeigt welche zu Performanceproblemen führen können. In diesem Post geht es um harte Grenzen. Wenn diese Grenzen überschritten werden begegnet man Fehlermeldungen.

Der Punkt mit den Workflows betrifft verschiedene Workflows per Item. Natürlich können Innerhalb von SharePoint mehr als 15 Workflows laufen. ;-) Workflows der gleichen Art kann nur einer pro Dokument gestartet werden.

Gefunden habe ich diese Daten bei Harshawardhan Chiplonkar. Er hat sie den entsprechenden Produktspezifikationen entnommen.

Es gibt viele verschiedene Architekturen um SharePoint im Extranet zu verwenden. Bei der Wahl der Technologie muss man wissen was man für Anforderungen hat und was man für technische Rahmenbedingungen sind. Bei der Planung eines Extranets muss man zwei Bereiche beachten. Wie gelange ich auf den Server und wie authentifiziere ich mich.

In diesem Post möchte ich ein wenig auf die Authentifizierung zu sprechen kommen.
Für die Authentifizierung stehen Windows, ASP.NET forms und Web Single Sign-On (SSO) zur Auswahl. Bei jeder Authentifizierungsmethode gibt es verschiedene Technologien die zur Auswahl stehen. So kann man bei SSO eine externe Person über ADFS eingebunden werden, (*1) oder bei forms authentification ein MembershipProvider(*2) verwenden um die Benutzer an SharePoint authentifizieren.

Es ist möglich mehrere Authentifizierungsmechanismen auf einem Web zu verwenden, man kann aber nur maximal fünf verschiedene auf einer Applikation haben. Denn pro Webzone kann man nur eine Authentifizierung konfigurieren, und für eine WebApplication kann man maximal fünf Webzonen einrichten.

In einem Post hat Fabian die Probleme einer WebForm Authentifizierung sehr schön auf den Punkt gebracht. Dabei sieht es bei ADFS und SSO auch nicht viel besser aus. Die Clientintegration ist nur noch bedingt brauchbar. Dabei ist die Clientintegration ein wichtiger Bestandteil von SharePoint und sollte falls möglich auch bei einem externen Zugang ermöglicht werden.

Nichtsdestotrotz, hat sich also seit SharePoint 2003 einiges getan. SharePoint 2003 hatte nur eine marginale extranet Unterstützung. So nun bin ich etwas abgeschweift. ;-) Wollte eigentlich auf einen Vortrag von den Microsoft TechDays 07 eingehen. Und zwar von Domick Baier von Thinktecture. In seiner Präsentation über die neue Architektur von künftigen IIS 7 gesprochen.
IIS7 bietet eine sehr flexible Architektur. Im IIS7 kann man einzelne Bestandteile hinzufügen oder Entfernen. Man kann zum Beispiel eine Authentification entfernen und selbst implementieren. Somit könnte man zum Beispiel die Basic Authentication selbst implementieren und die Benutzer aus einem eigenen Benutzerstore an SharePoint authentifizieren. Ohne das es sich dabei wirklich um einen WindowsAccount handelt. Dies würde eine zusätzliche Möglichkeit schaffen um in einem Extranet Clientintegration zu ermöglichen. Dies würde aber nur funktionieren solange man den IIS im integrated Modus verwendet. Solange man eine Applikation im Classic Mode einsetzt kann man auch keine Module ersetzen.
Bis man sowas aber testen kann muss man noch eine Weile warten. Denn schliesslich kommt der IIS7 zusammen mit dem Longhorn Server. Und eine SharePoint Version die IIS7 im integrated Modus unterstützt gibt es auch nicht. Das kann auch noch eine Weile dauern.

----------------------------------------------------------------------------

*1
Diese Technologie ist interessant wenn man einer Firma Zugang auf einen SharePoint Rechner geben will und die Benutzer nicht in einem eigenen AD verwalten will. Dabei werden die Benutzerdaten aus dem AD der externen Firma per ADFS angezapft. Der Vorteil: sobald der Benutzer in der Externen Firma keinen gültigen Account mehr hat ist hat er auch auf dem SharePoint keinen Zugriff mehr.
*2
Diese Technologie ist interessant wenn man die externen Benutzer bereits in einem eigenen Benutzer Store verwaltet. Nun kann man einen MembershipProvider programmieren und die Benutzer somit am SharePoint authentifizieren. Oder man verwendet den SQLMembershipProvider welcher mit dem ASP.NET Framework ausgeliefert wird.

Das Debugging eines Workflows ist nicht immer ganz einfach. Bei einem SharePoint Workflow hat man verschiedene Bedingungen die es einem erschweren. So wird zum Beispiel bei einem CreateTask Activity der Task nicht gleich erstellt sondern asynchron erst zu einer späteren Zeit. Falls nun das Erstellen dieses Tasks fehl schlägt merkt man dies im eigenen Code vielleicht gar nicht. Wenn man nun mit dem Visual Studio am debuggen ist und herausfinden will wieso der Task nicht erstellt wird bekommt man keine Exception. Der eigene Code wird durchlaufen. Bei einem State Machine Workflow wird je nach Implementation sogar der ganze State durchlaufen. Erst bei der nächsten Dehydration wird der Task erstellt.

Doch in diesem Beispiel gehen wir davon aus, dass der Task eben nicht erstellt wird. Es kann sich auch um ein UpdateTask Activity handeln oder schlicht ein Activity welches seine Arbeit asynchron erledigt.
Auf dieses Beispiel möchte ich hier nicht weiter eingehen. Es soll auch nur dazu dienen ein Beispiel aufzuzeigen wo der Code nicht vorhanden ist und man auch keine Exception bekommt. Und man somit nicht so einfach herausfinden kann was man genau für Problem vor sich hat.

Bei einer Solchen Situation müsste man das Problem aus ein wenig Distanz ansehen. Dabei kann man mit verschiedenen Ansätzen vorgehen. Einer ist das von Ingo Rammer an den TechDays von Microsoft vorgestellte Tool WinDbg. Mit WinDbg kann man einen Dump des Memory erstellen. In dem Dump kann man nach der Exception suchen. Dabei muss man sich überlegen wie man den Dump erstellen möchte denn schliesslich soll die Exception auch darin enthalten sein. Man hat auch die Möglichkeit an einer globalen Stelle im eigenen Code einen Dump zu erstellen. Dabei sollte man aber gut Überlegen wie man das macht und mit welchen Parametern man den Dump erstellt. Je nachdem wie gut die eigene Applikation ist. Hat man schnell ein paar Dumps zusammen. ;-)

Die Arbeit mit Dumps kann eine sehr zeitintensive Angelegenheit sein. Bei der Entwicklung von WinForm Anwendungen kann man eine Anwendung direkt mit dem WinDbg starten somit kann man bei einer Exception anhalten und direkt den Dump nach dem Problem durchsuchen. Bei einem Server den ganzen w3wp Prozess über WinDbg laufen zu lassen ist aber kaum möglich.

Aus den gleichen Gründen wie debuggen mit Visual Studio auf dem Server nicht erwünscht ist, ist auch eine solche Aktion nicht erwünscht: Wenn irgendwo ein Benutzer vor dem Bildschirm sitzt und auf seinen Browser wartet. Ist ein step-by-step Debugging nicht nett. :-)

Da hilft einem Adplus weiter. Adplus wird ebenfalls mit den Debugingtools for Windows mitinstalliert. Eine Anleitung wie man einen Dump bei einer Exception erstellt findet man hier:

Wenn man einen dieser Wege wählt hat man zwar einen Dump doch die Arbeit ist noch nicht erledigt. Danach muss man noch den Fehler finden.

Habe eine nützliche Seite zu diesem Thema gefunden: WinDbg / SOS Cheat Sheet leider ist sie momentan nur im Google Cache zu finden.

Falls die Seiten ganz verschwinden sollten hier eine kleines Beispiel:

1. Crashdump öffnen über das Menu
   Falls WinDbg folgende Meldung bringt "This dump file has an exception of interest stored in it" hat man schon mal was im Dump


2. .loadby sos mscorwks
   Laden des SoS für Framework 2.0


3. !threads
   Anzeige der "managed" Threads


4. ~0s
   Selektion des Threads 0
   (Nur ein Beispiel. Bei Punkt 3 sollte der Thread ersichtlich sein.)


5. !PrintException

Als die Office 2007 Produkte noch in der Betaphase waren, war die Rede von einer Export/Speicher Funktion zu PDF. Standardmässig ist dieses Feature leider nicht installiert. Man kann es aber hier herunterladen und nachinstallieren. Das ganze sieht dann so aus: