Ein paar RSS Feeds

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.

Die Wahl der Technologie

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.

Atlas Workflow Designer

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.

Philosophie der Tasks

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

i-176367c69eb4c7495a7da0cf7fc11fc0-StateWithArrows.png

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.