SharePoint Community Camp 24.&25. April 2008

Heute auf dem Programm stand "Datenansichten mit SharePoint Designer" (Michael Greth), "Gestaltung und Anpassung von SharePoint Plattformen" (Fabian Moritz), SharePoint Workflows erstellen" (Daniel Wessels) und "Best Practices/Tipps für die Umsetzung von Web Content Management Systemen auf Basis von MOSS" (Fabian Moritz).

Im ersten Slot wurden die Möglichkeiten von Datenansichten aufgezeigt. Nachdem gestern die Dataviews genutzt wurden, um die Suchresultat anzupassen, wird heute der Fokus stärker auf die Verknüpfung von Daten gelegt. Auch lag hier der Schwerpunkt auf die Nutzung des SharePoint Designers, welcher gute Unterstützung für Nicht-Entwickler bietet, um Anpassungen selber durchzuführen. Über bedingte Formatierungen und individuelle Filterkriterien, können
so gute Übersichts- und Auswertungsviews erstellt werden.
Was eher zu kurz kam, sind die Nachteile vom SharePoint Designer. Es muss bewusst sein, dass die Anpassungen jeweils nur für diese Seite greifen, auf welcher die Anpassungen gemacht werden. Für wiederverwendbare Komponenten, was oft bei grösseren Unternehmen benötigt wird, sollte zwingende die Funktionalitäten über Features implementiert werden. Da sehe ich den SharePoint Designer eher als Tool fürs Prototyping, die Umsetzung dabei erfolgt von den Entwicklern im Visual Studio.

Der zweite Slot zeigte anhand verständlicher Demos, die verschiedenen Stufen der Anpassungen innerhalb von SharePoint. Über Administrator, Publisher bis hin zum Entwickler.
Zwar wurden die Gefahren der Tools erklärt, aber auch die Vorteile der Eigenentwicklung eher in den Hintergrund gerückt. Obwohl die Eigenentwicklung zeitaufwendiger ist, erhöht das die Kontrolle über den Code und erleichtert das Change Management und Bug Fixing enorm.

Der Nachmittag begann mit der Session "SharePoint Workflows".
Sehr detaillierte Demo, wie der im SharePoint Umfeld bekannte Ferienantrag mittels InfoPath und SharePoint Designer erstellt werden kann. Dabei wurde ein 3-stufiger Workflow erstellt (Antragsteller --> Vertreter --> Manager). Die Demo bestätigt, dass für einfache Workflows, wie Spesenabrechnungen, Ferienanträge etc. SharePoint durchaus sinnvoll eingesetzt werden kann. Aber es ist nicht zu vergessen, dass die Transaktionalität nicht unterstützt wird und so für Businesskritische Prozesse auf einen anderen Workflowhost ausgewichen werden muss.

Zum Abschluss wird noch auf das Web Content Management eingegangen.
In einer Kurzen Präsentation wird der Weg zum Web Content Management aufgezeigt. Von der Erstellung von Publishing Sites, Erstellen Masterpages mit Bilder und Styles bis hin zur Anwendung von Page Layouts. Gute Einführung ins Web Content Management. Das Fazit kam zum Schluss: Man hat viele Möglichkeiten, aber es gibt viele Anpassungen und Eigenentwicklungen zu machen, für eine komplette Webseite.
Am Schluss noch einige Beispiele von Webseiten auf Basis von MOSS, leider fehlte die von namics erstellte Seite von www.nestle.ch :-)

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.

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

Eine SharePointListe kann man ohne grosse Probleme mit einer zusätzlichen Metaspalte erweitern. Mit den Metainformationen kann man zum Beispiel weitere Informationen zu einem Dokument ablegen. Diese Informationen werden sogar direkt aus den Office Clients editiert und angezeigt.

Wenn man bei diesen Felder angibt, dass sie zwingend gefüllt werden müssen, kann der Benutzer das Dokument erst speichern wenn er einen Wert eingegeben oder selektiert hat.

In diesem Artikel geht es jedoch nicht um diese Funktion, denn diese wurde schon durch Mischa Mundwiler (Klassifizierung von Dokumenten mit dem Document Information Panel) beschrieben. Er ist sogar einen Schritt weiter gegangen und hat gezeigt, wie man die Anzeige im Word anpassen kann.

In diesem Artikel geht es darum eine DocumentLibrary mit einem einfachen Workflow zu erweitern. Dabei soll es ein Workflow sein, welcher ohne Kenntnisse von Programmiersprachen erstellt werden kann.

Als erstes braucht man eine DocumentLibrary. Dort fügen wir zwei Spalten hinzu und zwar „Konzepttyp“ und „Dokument Status“. Zuerst muss man zu der gewünschten DocumentLibrary gehen und bei den Einstellungen die neuen Spalten hinzufügen.
In meinem Beispiel habe ich in der Spalte „Konzepttyp“ die Möglichkeiten „Detailkonzept“ oder „Grobkonzept“ hinzugefügt. Bei der zweiten Spalte „Dokument Status“ stehen mehrere Werte zur Auswahl. Für dieses Beispiel ist aber nur der Wert „Abgeschlossen“ relevant.

Wenn man bei den Spalten angegeben hat, dass sie zwingend gefüllt werden müssen, erscheint beim Speichern automatisch der Dialog, welcher auf dem ersten Bild gezeigt wurde. Sobald das Dokument gespeichert wurde, sieht das Dokument in SharePoint wie folgt aus:

Nun kommt der eigentliche Teil dieses Eintrages. Wir möchten ja einen einfachen Workflow erstellen, und zwar einen ohne Programmierung. Das bedeutet wir werden einen Sequentiellen Workflow mit dem SharePoint Designer erstellen.

Dazu müssen wir die Seite mit der Liste mittels SharePoint Designer öffnen. Im SharePoint Designer kann man die Seite öffnen indem man unter File > Open Site einfach die URL zu der Seite eintippt/einfügt (Bei meinem Beispiel http://wss/Demo/). Dann sollte man folgendes sehen:

Der Name meiner Document Library ist „Konzept“. Über das Menü kann man dieser Library einen neuen Workflow hinzufügen.

Das Erstellen eines Sequentiellen Workflows mit dem Designer erfolgt mit einem Wizard. Dieser fragt zuerst nach dem Namen des Workflows und der gewünschten SharePoint Liste, bei welcher der Workflow hinzugefügt werden soll. Hier kann man weitere Optionen setzen, wie zum Beispiel ob der Workflow bei einem neuen Dokument automatisch gestartet werden soll. Dies macht in unserem Fall natürlich Sinn. Denn so muss bei einem neuen Dokument kein Workflow von Hand gestartet werden.

In diesem Workflow soll folgendes geschehen. Sobald ein Grobkonzept abgeschlossen wird, soll ein Task einem Benutzer zugewiesen werden. Falls ein Detailkonzept abgeschlossen wird, soll ebenfalls ein Task zugewiesen und ausserdem eine Email versandt werden. Der Workflow gilt erst als abgeschlossen, wenn der zugewiesene Task als erledigt markiert wird.

Der Workflow ist nur ein Beispiel und kann oder muss keinen Sinn ergeben. ;-)

Damit wir die beschriebene Funktion erhalten, verwenden wir zwei Überprüfungen.

Grobkonzept
Falls das Dokument bei der Metainformation „Dokument Status“ = „Abgeschlossen“ und „Konzepttyp“ = „Grobkonzept“
=> Task an eine Person

Detailkonzept
Falls das Dokument bei der Metainformation „Dokument Status“ = „Abgeschlossen“ und „Konzepttyp“ = „Detailkonzept“
=> Task an eine Person & Email an eine Person

Der Wizard gibt uns verschiedene Activities zur Auswahl um einen Workflow zu erstellen. Bei der Überprüfung der Metafelder stellt er die möglichen Werte zur Verfügung, falls es sich um ein Dropdown Feld handelt.

In diesem Bild wurden die nötigen Überprüfungen zu den zwei Möglichkeiten eingefügt. Wenn nun noch die Aktionen eingefügt werden sieht das Ganze so aus:

Ein Sequentieller Workflow kann mittels deklarativer Sprache (XML) beschrieben werden, ein StateMachine Workflow hingegen nicht. Der SharePoint Designer kann somit nur einen Sequentiellen Workflow erstellen. Wenn man den Workflow speichert, zeigt sich einem wieder die Ordnerstruktur von SharePoint. Dabei sieht man die Definitionsdateien des Workflows „Benachrichtigen“:

Wenn nun ein neues Dokument in der Dokument Library abgelegt wird, muss der Benutzer die zwei neuen Metainformationen angeben. Ausserdem wird beim ersten Speichern automatisch der Workflow gestartet. Dieser überprüft bei jeder Änderung des Dokumentes die zwei Felder. Sobald eine der beiden Überprüfungen zutreffen, erstellt er einen Task und versendet bei einem Detailikonzept sogar ein Email. In der Taskliste zeigt sich ein neuer Task wie folgt:

Beim Öffnen des Taks sieht man folgendes:

Wenn dieser Task nun abgeschlossen wird, ist auch der Worklfow beendet und geht auf „Completed“.

Natürlich hat man mit einem Sequentiellen Workflow nur begrenzte Möglichkeiten, jedoch kommt man ohne Programmieren schon zu einem Workflow. In einem älteren Blog habe ich eine andere Möglichkeit gezeigt, wie man einen Sequentiellen Workflow visuell gestalten kann: Atlas Workflow Designer
Weitere Informationen zu dem SharePoint Designer gibt es auf dem offiziellen Blog unter: http://blogs.msdn.com/sharepointdesigner/default.aspx (Englisch)
Besonders interessant sind die neuen Lernvideos.

Im Anhang finden Sie meinen Artikel zum Thema Business-Prozesse mit SharePoint, InfoPath und der Windows Workflow Foundation, welcher in der Spezialausgabe von InfoWeek 1/07 zum Launch von Vista, Office 2007, SharePoint 2007 herausgegeben wurde.

Download Artikel (pdf, 527k)

Viel Spass beim Lesen und ich freue mich auf Ihr Feedback.

Heute hatten wir eine Schulung bei namics wo wir über SharePoint 2007, Workflow, WebParts und mehr gesprochen haben. Ich habe den Teilnehmern versprochen ein paar interessante Feeds als .opml Datei in den Blog zu stellen.

Ressourcen zum Thema Workflow und SharePoint 2007 gibt es doch schon einige.
In Buchform leider wenige (z.B. von Paul Andrew), und das ist momentan auf dem Stand von Beta2 somit nicht ganz aktuell.

Datei kann direkt im RSS-Reader importiert werden.

Weitere Quellen gibt’s momentan nicht so viele.

Welche Workflows gibt's?
Zur Erinnerung nochmals die zwei Workflowtypen:

Sequenz Workflow "SharePoint Sequential Workflow Library"

State Machine Workflow "SharePoint State Machine Workflow Library"

Es gibt verschiedene Entscheidungsfaktoren. Es muss aufgrund der Möglichkeiten, Funktionsweisen und den gegebenen Umstä¤nden entschieden werden.

Möglichkeiten
Grundsätzlich kann man jeden State Machine Workflow auch mit einem sequenziellen Workflow abbilden. Dies führt aber bei einem sequenziellen Workflow in kurzer Zeit zu einer unüberschaubaren und kaum wartbaren Komplexität.

Funktionsweise State Machine Workflow
Bei einem State Machine Workflow wird vom Benutzer entschieden, wann es in den nächsten Zustand geht. Man nennt den State Machine Workflow auch "Human Workflow".

Funktionsweise Sequential Workflow
Bei einem sequenziellen Workflow hingegen wird diese Entscheidung vom System anhand vordefinierter Regeln entschieden.

Funktionsweise spezieller State Machine Workflow
In der Anfangsphase von den SharePoint 2007 Workflows war manchmal auch die Rede von einem dritten Workflow unter dem Namen Datadriven Workflow. Dabei war die Idee, dass der Workflow seine Zustandsänderungen nicht anhand der Aktionen des Benutzers erfährt, sondern aufgrund von Informationen in dem SPListItem oder in der Datenbank entscheidet. Der Benutzer soll eine sekundäre Rolle spielen. Von dieser Art Workflow hat man aber in letzter Zeit nicht mehr viel gehört. Denn eigentlich ist es ein normaler State Machine Workflow, welcher programmatisch auf die Datenbank und das SPListItem zugreift und dessen Werte in die Entscheidungen miteinbezieht.

Entstehungsprozess
Eine andere Entscheidungsgrundlage ist auch die Tatsache, dass mit dem SharePoint Designer jeder einen sequenziellen Workflow erstellen kann. Vorausgesetzt er hat die benötigten Berechtigungen auf dem SharePoint. Wenn diese Person mit den Vorhandenen Activities nicht in der Lage ist den gewünschten Workflow abzubilden, muss entweder von einem Programmierer ein neues Activity mit der fehlenden Funktion erstellt werden, oder der gesamte Workflow ist für einen sequenziellen Workflow zu komplex. Somit muss er vielleicht als State Machine Workflow erstellt werden. In diesem Fall wird der Workflow von einem Programmierer erstellt.

Wenn man die Möglichkeit hat den Workflow als sequenziellen Workflow abzubilden ist es sicher einfacher dies so zu machen. Setzt aber bei dem Ersteller des Workflows voraus, dass er den abzubildenden Prozess kennt und versteht und somit eine Aussage machen kann ob der den anhand der gegebenen Activities abbilden kann. Somit muss er auch grundlegende Kenntnisse von Programmlogik beherrschen.

Was soll man installieren wenn man SharePoint Workflows haben will? Und welche Möglichkeiten hat man mit welcher Installation?

Die Windows SharePoint Services in der Version 3 liefert die nötige Basis um SharePoint basierende Workflows einzusetzen. Der Office SharePoint Server 2007 hingegen bringt noch einige zusätzliche Workflows mit. Mit dem Formsserver hat man auch die Möglichkeit Infopathformulare direkt im Browser anzuzeigen. Eine Installation des Infopath Clients beim Benutzer ist somit nicht nötig.

Hier ein paar wichtige Punkte für die Entscheidung:

Windows SharePoint Services Version 3
- Einsatz von Workflows, welche mit Dokumenten und Listen arbeiten.
- Erstellen von Workflows, welche nur ASPX Formularen benötigen.

Office SharePoint Server 2007
- Einsatz der mitgelieferten Workflows des Servers. Eine Ausnahme ist der "Issue Tracking" Workflow welcher keine Infopathformulare benötigt und auch bereits mit einer WSS-Installation dabei ist.

Das deklarative Modell der SharePoint WF ermöglicht es selbst einen Designer zu erstellen. Genau dies hat Jon Flanders gemacht. Sein Designer benötigt nur einen Browser. Nun kann er auch ohne installation getestet werden:
Online Demo

Diesen Designer gibts in zwei Geschmacksrichtungen. Reines Html, oder mit Atlas.

Wo soll man bei einem StateMachine Workflow in SharePoint 2007 die Tasks anlegen und wieder aufräumen?

Möchte hier meine Überlegungen mit euch teilen. Anmerkungen und Kommentare sind willkommen.

Es geht dabei um die Stelle im Workflow, wo der Task angelegt wird. Als mögliche Pattern möchte ich auf zwei Varianten eingehen.

Pattern1
-Task wird immer bei einem Event erstellt oder aufgeräumt
Pattern2
-Task wird immer im "Initialisation" Block erstellt und im "Finalisation" Block wieder aufgeräumt

Einsatzgebiete Pattern1
Beispiel Pattern1
Das Pattern1 ist am besten dort einzusetzen, wo es verschiedene langlebige Tasks mit gleichen Besitzern gibt.

Wenn das Taskformular oder deren Besitzer häufig wechseln, ist das Pattern2 ev. übersichtlicher für die Entwicklung. Vor allem wenn man Zustände über mehrere Wege erreichen kann. Dann muss bei diesem Pattern bei verschiedenen vorangehenden Zuständen ein Task erstellt oder auf die gleiche Weise angepasst werden.

Einsatzgebiete Pattern2
Beispiel Pattern2

Das Pattern2 kann am besten dort eingesetzt werden, wo sich die Zustände in den Tasks-Besitzern und in den TaskFormularen unterscheiden.
Wenn also zwischen den Zuständen sowieso der bestehende Task abgeschlossen oder gelöscht werden soll, und im nächsten Zustand wieder ein neuer Task mit einem neuen Formular erstellt werden soll.

Es muss somit nur überlegt werden ob der Zustand verlassen wird, wenn dem so ist wird, zum Beispiel im "OnTaskChange"-Eventhandler mit SetState ein neuer Zustand gesetzt.
Das Abschliessen des aktuellen Zustandes respektive dessen Task geschieht im "Finalisation"-Block. Das Einrichten des neuen Zustandes wird vom Initialisation-Block des nächsten Zustandes übernommen. Dabei ist es sogar egal welches der nächste Zustand ist, weil dieser die Arbeit übernimmt.