Einführung für Entwickler in Workflows für Windows SharePoint Services V3 und SharePoint Server 2007

Veröffentlicht: 23. Okt 2006
Von Andrew May

Verschaffen Sie sich eine grobe Übersicht darüber, wie Microsoft Windows SharePoint Services (Version 3) die Workflowfunktionen von Windows Workflow Foundation implementiert und wie Microsoft Office SharePoint Server 2007 diese Funktionen mit symmetrischen Microsoft Office InfoPath 2007-Formularen erweitert. (28 gedruckte Seiten)

Auf dieser Seite

Einführung in Workflows Einführung in Workflows
Workflowarchitektur Workflowarchitektur
Workflowtypen Workflowtypen
Workflowkomposition Workflowkomposition
Workflow Markup Workflow Markup
Workflows in Windows SharePoint Services und SharePoint Server 2007 Workflows in Windows SharePoint Services und SharePoint Server 2007
Entwickeln von SharePoint Workflows Entwickeln von SharePoint Workflows
Entwickeln von SharePoint Workflows in Visual Studio 2005 Entwickeln von SharePoint Workflows in Visual Studio 2005
Entwickeln von SharePoint Workflows in SharePoint Designer 2007 Entwickeln von SharePoint Workflows in SharePoint Designer 2007
Vergleich von Visual Studio 2005 Designer for Windows Workflow Foundation und SharePoint Designer 2007 Vergleich von Visual Studio 2005 Designer for Windows Workflow Foundation und SharePoint Designer 2007
Workflowstruktur in Windows SharePoint Services Workflowstruktur in Windows SharePoint Services
Verwenden des Workflow Namespace Verwenden des Workflow Namespace
Schlussbemerkung Schlussbemerkung
Weitere Ressourcen Weitere Ressourcen

Einführung in Workflows

Microsoft Windows SharePoint Services bieten eine robuste, anpassbare Arbeitsumgebung für Benutzer zum Erstellen und Speichern wertvoller Geschäftsinformationen sowie für die Zusammenarbeit. Mit Microsoft Windows SharePoint Services (Version 3) und Microsoft Office SharePoint Server 2007 können Sie diesen Dokumenten oder Listenelementen jetzt benutzerdefinierte Geschäftsprozesse anhängen.

Sie können diese benutzerdefinierten Geschäftsprozesse mithilfe von Workflows darstellen. Ein Workflow ist eine natürliche Methode zum Organisieren und Ausführen eines Satzes von Arbeitseinheiten oder Aktivitäten, sodass eine ausführbare Darstellung eines Arbeitsvorgangs gebildet wird. Dieser Vorgang kann nahezu jeden Aspekt eines Elements in Windows SharePoint Services steuern, einschließlich des Lebenszyklus dieses Elements. Der Workflow ist flexibel genug, um sowohl die Systemfunktionen als auch die von Personen durchzuführenden Aktionen zu modellieren, die für den Abschluss des Workflows erforderlich sind.

Sie können Workflows erstellen, die so einfach oder so komplex sind, wie Ihre Geschäftsvorgänge es erfordern. Sie können Workflows erstellen, die vom Benutzer initiiert werden, oder Workflows, die Windows SharePoint Services automatisch auf der Basis eines Ereignisses initiieren, z. B. wenn ein Element erstellt oder geändert wird.

Angenommen, Sie müssen einen einfachen Workflow erstellen, der ein Dokument zur Genehmigung oder Kommentierung an eine Reihe von Benutzern weiterleitet. Dieser Workflow würde Aktionen enthalten, die vom System durchzuführen sind, und den Benutzern Schnittstellen bieten, über die diese in vorgeschriebener Art und Weise mit dem Workflow interagieren können. Windows SharePoint Services sendet beispielsweise eine E-Mail an die ausgewählten Benutzer, wenn das Dokument zur Überarbeitung bereit ist. Diese Benutzer müssen dann in der Lage sein, Windows SharePoint Services zu benachrichtigen, wenn sie die Überarbeitung abgeschlossen und ggf. Kommentare eingegeben haben. Mit dem in Windows SharePoint Services V3 enthaltenen und in SharePoint Server 2007 erweiterten Workflow-Framework können Sie derart komplexe Arbeitsvorgänge modellieren und den Endbenutzern in einer leicht verständlichen, unaufdringlichen Weise präsentieren, die sie durch jeden Schritt des Vorgangs führt.

Dieser Artikel bietet eine grobe Übersicht über Workflows, wie sie in Windows SharePoint Services implementiert und in SharePoint Server erweitert sind. Die verfügbaren Entwicklertools werden erörtert, mit denen Workflows in beiden Umgebungen erstellt werden können; außerdem die entsprechenden Möglichkeiten und Vorteile dieser Tools.

Workflowarchitektur

Die Workflowfunktion in Windows SharePoint Services V3 baut auf Windows Workflow Foundation (WF) auf, einer Microsoft Komponente der Windows-Plattform, die eine Programmierungsinfrastruktur und Tools für die Entwicklung und Ausführung von workflowbasierten Anwendungen bereitstellt. WF vereinfacht den Vorgang des asynchronen Programmierens und erstellt statusbehaftete, lang ausgeführte und dauerhafte Workflowanwendungen. Das WF-Laufzeitmodul verwaltet die Ausführung des Workflows und ermöglicht es Workflows, über lange Zeiträume aktiv zu bleiben und einen Neustart des Computers zu überdauern. Laufzeitdienste bieten Funktionen wie Transaktionen und Dauerhaftigkeit, sodass Fehler erfolgreich und korrekt verwaltet werden können.

Das WF-Laufzeitmodul stellt die Dienste bereit, die für jede Workflowanwendung erforderlich sind, wie z. B. Sequenzierung, Zustandsverwaltung, Überwachungsmöglichkeiten und Transaktionsunterstützung. Das WF-Laufzeitmodul dient als Statusmechanismus, der für das Laden und Entladen von Workflows ebenso verantwortlich ist wie für das Verwalten des aktuellen Status aller Workflows, die ausgeführt werden. WF ermöglicht es jedem Anwendungsprozess oder Dienstcontainer, Workflows auszuführen, indem WF bereitgestellt wird; d. h., WF wird innerhalb des Prozesses geladen.

Windows SharePoint Services stellen das WF-Laufzeitmodul bereit. Anstelle der austauschbaren Dienste, die in WF enthalten sind, bieten Windows SharePoint Services benutzerdefinierte Implementierungen der folgenden Dienste für das Modul: Transaktion, Dauerhaftigkeit, Benachrichtigungen, Rollen, Überwachung und Messaging. Entwickler können daraufhin Workflowlösungen erstellen, die innerhalb der Windows SharePoint Services ausgeführt werden.

In Abbildung 1 ist die Workflowarchitektur in Windows SharePoint Services dargestellt. Windows SharePoint Services verwalten das WF-Laufzeitmodul innerhalb ihres Prozesses und stellen benutzerdefinierte Implementierungen der erforderlichen Dienste bereit. Die Funktionalität des WF-Laufzeitmoduls sowie die von Windows SharePoint Services bereitgestellte Hostingfunktion werden durch das Windows SharePoint Services-Objektmodell offen gelegt.

Abbildung 1: Workflowarchitektur in Windows SharePoint Services V3
Abbildung 1: Workflowarchitektur in Windows SharePoint Services V3

Windows Workflow Foundation stellt außerdem Visual Studio 2005 Designer for Windows Workflow Foundation bereit, ein im Entwicklungssystem Microsoft Visual Studio 2005 verwaltetes Add-In, mit dem Entwickler ihre eigenen benutzerdefinierten Workflows und Workflowaktivitäten erstellen können. Weitere Informationen finden Sie unter Entwickeln von SharePoint Workflows in Visual Studio 2005.

SharePoint Server nutzt die Workflowfunktion in Windows SharePoint Services (Version 3) und erweitert diese Funktion durch Integration in InfoPath-Formulare und zusätzliche Workflowaktivitäten. Dies wird im Abschnitt Entwickeln von SharePoint Workflows in SharePoint Designer 2007 ausführlicher erörtert.

Das Windows Workflow Foundation-Laufzeitmodul ist als Bestandteil des Downloads Microsoft Windows Workflow Foundation Runtime Components Beta 2.2 und Visual Studio 2005 Extensions for Windows Workflow Foundation Beta 2.2 im Microsoft Download Center erhältlich. Dieser Download enthält außerdem Visual Studio 2005 Designer for Windows Workflow Foundation und das Windows Workflow Foundation Software Development Kit (SDK).

Nachdem die in Windows SharePoint Services bereitgestellte Workflowinfrastruktur kurz beschrieben wurde, wird jetzt die interne Zusammensetzung und Struktur eines WF-Workflows untersucht. Danach wird auf die verschiedenen Entwicklertools eingegangen, die Microsoft zum Erstellen von Workflowlösungen für Windows SharePoint Services und SharePoint Server 2007 zur Verfügung stellt.

Workflowdauerhaftigkeit

Einer der wichtigsten Dienste, die Windows SharePoint Services dem WF-Workflowmodul zur Verfügung stellen, ist Dauerhaftigkeit. Workflows mit Interaktionen von Personen nehmen von Natur aus viel Zeit in Anspruch. Selbst unter idealen Umständen benötigen Menschen im Vergleich zu Maschinen viel Zeit zum Abschließen von Arbeitsvorgängen. In vielen Microsoft Office-Szenarios erstrecken sich Workflows in der Regel über Tage oder noch längere Zeiträume. Betrachten Sie den Beispielworkflow, der Dokumente zur Genehmigung weiterleitet. Unter Umständen benötigt der Genehmiger mehrere Tage, um das Dokument zu überarbeiten.

Jeden ausgeführten Workflow für die gesamte Dauer seiner Ausführung im Speicher zu belassen ist also nicht durchführbar. Die Ressourcen, die für lang ausgeführte Workflows erforderlich sind, würden das System sehr bald überlasten und zum Anhalten zwingen.

Stattdessen entfernen Windows SharePoint Services eine Workflowinstanz aus dem Speicher und behält deren Daten bei, wenn sie einen Punkt erreicht hat, an dem sie auf Benutzereingaben wartet. Wenn dann ein entsprechendes Ereignis eintritt (z. B. ein Benutzereingaben), das den erneuten Start der Workflowinstanz erfordert, erstellen Windows SharePoint Services die Workflowinstanz mithilfe der beibehaltenen Daten neu. Die Workflowinstanz kann das Ereignis dann den Erfordernissen entsprechend empfangen und verarbeiten.

Obwohl u. U. jederzeit zahlreiche Workflowinstanzen ausgeführt werden, befindet sich wahrscheinlich nur ein Bruchteil dieser Workflows im Speicher und nutzt Systemressourcen.

Workflowtypen

Windows Workflow Foundation unterstützt zwei grundlegende Workflowstile:

  • Sequenzielle Workflows:   Stellen einen Workflow als Abfolge von Schritten dar, die der Reihe nach ausgeführt werden, bis die letzte Aktivität abgeschlossen ist. Sequenzielle Workflows werden jedoch nicht ausschließlich sequenziell ausgeführt. Da sie externe Ereignisse empfangen und parallele logische Abläufe enthalten können, kann die genaue Reihenfolge der Ausführung der Aktivitäten abweichen.

  • Statusmechanismusworkflows:   Stellt einen Satz von Status, Übergängen und Aktionen dar. Einer der Status wird als Startstatus bezeichnet und kann nach einem abgeschlossenen Ereignis in einen anderen Status übergehen. Der Statusmechanismus kann durch einen definierten Endstatus beendet werden.

Sie können Workflows jeden Typs für Windows SharePoint Services und SharePoint Server erstellen.

Sequenzielle Workflows

enzielle Workflows lassen sich am besten grafisch als Flussdiagramm von Aktionen darstellen, mit einem Anfang, einem Ende und einer sequenziellen Flussrichtung von Anfang bis Ende. Sequenzielle Workflows können Flussstrukturen wie Wiederholungen, Schleifen und parallele Teilstrukturen enthalten, doch letztendlich schreiten sie von der ersten Aktion zur letzten Aktion fort.

Nehmen Sie einmal an, Sie sollten einen einfachen Workflow zeichnen, der ein Dokument in Windows SharePoint Services zur Genehmigung weiterleitet. Wenn der Workflow startet, benachrichtigt das System den angegebenen Bearbeiter mithilfe einer E-Mail-Nachricht, dass ein Dokument zur Überarbeitung vorliegt. Daraufhin überarbeitet der Bearbeiter das Dokument und benachrichtigt das System, dass die Aufgabe abgeschlossen ist, und darüber, ob das Dokument genehmigt oder abgelehnt wird. Je nach Antwort des Bearbeiters führt der Workflow eine von zwei parallelen Teilstrukturen aus. Wenn der Bearbeiter das Dokument genehmigt hat, verschiebt das System das genehmigte Dokument in eine bestimmte SharePoint-Dokumentbibliothek und sendet anschließend eine E-Mail-Nachricht an das gesamte Team, das dadurch über das genehmigte Dokument benachrichtigt wird. Wenn der Bearbeiter das Dokument ablehnt, benachrichtigt das System den Ersteller des Dokuments. In beiden Fällen ist der Workflow am Ende angelangt und wird beendet. Dieser Workflow ist in Abbildung 2 dargestellt.

Abbildung 2: Konzeptuelles Diagramm eines sequenziellen Workflows
Abbildung 2: Konzeptuelles Diagramm eines sequenziellen Workflows

Statusmechanismusworkflows

Im Gegensatz zu sequenziellen Workflows müssen Statusmechanismusworkflows keinen vorgeschriebenen Ausführungsablauf und auch kein Ende haben. Stattdessen definieren Statusmechanismusworkflows eine beliebige Anzahl von Status, die ein Element annehmen kann, sowie die Ereignisse, durch die das Element von einem Status in einen anderen übergeht.

In Abbildung 3 ist ein einfacher Dokumentveröffentlichungsvorgang dargestellt, der als Statusmechanismusworkflow modelliert ist. Der Workflow wird initiiert, wenn ein Dokument erstellt wird, und endet, wenn der Dokumentstatus „abgeschlossen“ erreicht ist. Dazwischen nimmt das Dokument jedoch keinen vordefinierten Weg, sondern geht von einem Status in einen anderen über, während Ereignisse eintreten.

Der Statusmechanismusworkflows setzt sich aus Statusaktivitäten zusammen. Jede Statusaktivität stellt einen Status des Elements dar. Jede Statusaktivität kann eine Statusinitialisierung, Statusbeendigung und einen oder mehrere Ereignishandler enthalten. Jede Ereignishandleraktivität kann ein Ereignis verarbeiten. In Reaktion auf ein verarbeitetes Ereignis kann eine Verarbeitung erfolgen, und es kann ein Übergang in einen anderen Status stattfinden.

Abbildung 3: Konzeptuelles Diagramm eines Statusmechanismusworkflows
Abbildung 3: Konzeptuelles Diagramm eines Statusmechanismusworkflows

Ein gemeinsames Merkmal des sequenziellen Workflows und des Statusmechanismusworkflows ist es, dass jeder Workflowtyp in eine Sammlung einzelner Aktionen unterteilt werden kann: diejenigen, die vom System durchgeführt werden, und diejenigen, die von Benutzern durchgeführt werden. Sie können diese Aktionen als Bausteine von Workflows betrachten. In WF-Workflows werden diese Aktionen als Aktivitäten bezeichnet.

Workflowkomposition

Weiter oben wurde ein Workflow als Methode zum Organisieren und Ausführen eines Satzes von Arbeitseinheiten oder Aktivitäten definiert, mit denen eine ausführbare Darstellung eines Arbeitsvorgangs gebildet wird. Aus diesem Grund besteht jeder WF-Workflow aus einem Satz verwandter Aktivitäten. Eine Aktivität ist die elementare Einheit der Modellierung, Programmierbarkeit, Wiederverwendung und Ausführung innerhalb von Windows Workflow Foundation. Eine Aktivität kann vom System oder von einem Benutzer durchgeführt werden. Beispielsweise kann das System jemandem eine E-Mail-Nachricht als Alarm senden, oder eine Person kann ein Dokument zur Verteilung genehmigen.

Konzeptuell umfasst unser Beispiel für den sequenziellen Workflow fünf Aktivitäten:

  • Senden einer E-Mail-Nachricht zur Benachrichtigung des Genehmigers

  • Genehmigen oder Ablehnen eines Dokuments

  • Verschieben des Dokuments in die Dokumentbibliothek „Genehmigt“

  • Senden einer E-Mail-Nachricht zur Benachrichtigung des Teams

  • Senden einer E-Mail-Nachricht zur Benachrichtigung des Dokumenterstellers

Aktivitäten können auch logische Steuerstrukturen darstellen, die ähnlich wie Codeverknüpfungssteuerungen den Umfang des Workflows definieren und den Ausführungsablauf dirigieren. Beispiele dafür sind die Schleifen If Then und Do While, die den Programmablauf in Code steuern.

Aktivitäten können Eigenschaften, Methoden und Ereignisse haben. Einfache Aktivitäten führen eine einzelne Arbeitseinheit durch, z. B. „um 1 Tag verzögern“ oder „Webdienst aufrufen“. Zusammengesetzte Aktivitäten enthalten weitere Aktivitäten, z. B. eine bedingte Aktivität mit zwei Teilstrukturen. Sie können auch Handler wie z. B. Fehler- oder Kompensationshandler an Aktivitäten anhängen. Dies ist besonders bei zusammengesetzten Aktivitäten ratsam.

Im Wesentlichen ist der Workflow selbst schlicht eine zusammengesetzte Aktivität, die alle anderen Aktivitäten in diesem Workflow beinhaltet.

Daher kann ein Workflow als Satz von Aktivitäten betrachtet werden, die als Modell gespeichert sind, das einen realen Vorgang beschreibt. Arbeit geht von Anfang bis Ende durch das Modell, und Aktivitäten können von Personen oder Systemfunktionen ausgeführt werden. Workflows bieten eine Möglichkeit, die Ausführungsreihenfolge sowie Abhängigkeitsbeziehungen zwischen kurze Zeit und lange Zeit in Anspruch nehmenden Arbeitsgängen zu beschreiben.

Windows Workflow Foundation beinhaltet eine Reihe vordefinierter Aktivitäten, die Sie in Ihren Workflows verwenden können. Sie können auch Ihre eigenen, benutzerdefinierten Aktivitäten erstellen. Das Workflowprojekt-Vorlagenpaket von Windows SharePoint Services enthält zahlreiche Aktivitäten, die ausdrücklich für die Verwendung in der Windows SharePoint Services-Umgebung entwickelt wurden. Das Vorlagenpaket enthält außerdem die Verweise, die erforderlich sind, um auf der Grundlage des Windows SharePoint Services-Objektmodells programmieren zu können. Das SharePoint Server-Projektvorlagenpaket ist in ähnlicher Weise für die Verwendung in der SharePoint Server-Umgebung angepasst. Weitere Informationen finden Sie unter Entwickeln von SharePoint Workflows in Visual Studio 2005.

Workflow Markup

Jeder WF-Workflow kann durch die folgende Kombination von Dateien repräsentiert werden:

  • eine XML-Datei oder Markup-Datei, die die deklarativen Metadaten des Workflows enthält

  • die Markup-Datei in Kombination mit einer Code-Behind-Datei, die benutzerdefinierten Code enthält, der die Eigenschaften und das Verhalten des Workflows repräsentiert

  • eine Codedatei bzw. -dateien, die sowohl die deklarative Logik als auch das Verhalten des Workflows enthalten

Die Markup-Datei ist in Extensible Application Markup Language (XAML) geschrieben, die über ein veröffentlichtes Schema verfügt, an das die Datei sich halten muss. Die vorgegebene Dateierweiterung lautet XOML.

Da XAML ein veröffentlichtes Schema hat, können Sie XAML-Dateien mit einem Text- oder XML-Editor Ihrer Wahl erstellen. Die beiden in diesem Artikel erörterten Workflowentwicklungstools jedoch, Visual Studio 2005 Designer for Windows Workflow Foundation und Microsoft Office SharePoint Designer 2007, bieten Entwicklern eine grafische Oberfläche, in denen sie Workflows erstellen und automatisch die entsprechende Markup-Datei generieren können.

Entwickler können ihre deklarativen Metadaten in die in dem Workflow enthaltene Geschäftslogik integrieren oder davon trennen. Konzeptuell betrachtet ähnelt das von den WF-Workflows verwendete Beispiel der „Codetrennung“ demjenigen in Microsoft ASP.NET: deklarative Metadaten sind von der Datei getrennt, die Ihre Geschäftslogik enthält. Obwohl die Markup-Datei die Metadaten für die in dem Workflow enthaltenen Aktivitäten enthält, sind die Eigenschaften und Verhaltensweisen dieser Aktivitäten also in einer separaten Datei aufgeführt.

Bei Workflows, die mithilfe von Codetrennung erstellt werden, werden die Informationen wie bereits erwähnt in der Markup-Datei und in einem der beiden folgenden Dateitypen erhalten:

  • Einer Code-Beside-Datei, die den Code enthält, der Ihre Geschäftslogik einkapselt. Diese Datei kann in Microsoft Visual C# oder Microsoft Visual Basic .NET geschrieben sein.

  • Einer Datei mit Workflowregeln, die Ihre Geschäftslogik in deklarative Regeln und nicht in Code einkapselt.

Jeder auf diese Weise erstellte Workflow ist tatsächlich ein einzigartiger Microsoft .NET-Typ, der aus zwei partiellen Klassen konstruiert wird, die wiederum durch die XOML- und eine Code-Behind- oder Regeldatei repräsentiert werden. Wenn das Workflowprojekt kompiliert wird, werden diese beiden partiellen Klassen in einer .NET-Assembly zusammengefasst. Diesen Ansatz verwenden Sie beim Entwickeln von Workflows für Windows SharePoint Services oder SharePoint Server mit Visual Studio 2005 Designer for Windows Workflow Foundation.

Workflows, die nur aus Codedateien bestehen, folgen demselben allgemeinen Kompilierungsvorgang; d. h., die Dateien werden in einen .NET-Typ kompiliert.

Zusätzlich können Sie Workflows kompilieren, die ausschließlich aus Markup-Dateien bestehen. Dies ist jedoch nicht erforderlich. Das WF-Laufzeitmodul kann auch nicht kompilierte Markup Workflows laden und ausführen. Diesen Ansatz verwenden Sie beim Entwickeln von Workflows für Windows SharePoint Services oder SharePoint Server mit SharePoint Designer 2007.

Workflows in Windows SharePoint Services und SharePoint Server 2007

Bisher wurden die Attribute für Workflows für alle Anwendungen erörtert, die Windows Workflow Foundation implementieren. Jetzt erfahren Sie mehr über Workflows, die speziell in Windows SharePoint Services implementiert werden. Außerdem werden wichtige Aspekte dieser Implementierung behandelt.

Workflowvorlagen und -instanzen

In Windows SharePoint Services werden Workflows, die über eine Site oder Liste erhältlich sind, als Workflowvorlagen bezeichnet. Ein Workflow, der für ein bestimmtes SharePoint-Element ausgeführt wird, wird Workflowinstanz genannt. In einer beliebigen Liste können also mehrere Instanzen derselben Workflowvorlage gleichzeitig ausgeführt werden, jede für ein anderes SharePoint-Element. Für ein beliebiges SharePoint-Element kann jeweils mehr als ein Workflow ausgeführt werden.

Sie können Workflows für Dokumente oder Listenelemente ausführen. Durch einen Zuordnung genannten Vorgang, der weiter unten in diesem Artikel erläutert wird, stellen Sie eine Workflowvorlage auf einer Site zur Verfügung.

Verwenden von Formularen zum Aktivieren der Benutzerinteraktion mit Windows SharePoint Services

Obwohl Sie mit den Workflows von Windows SharePoint Services eine beliebige Anzahl eindeutiger Geschäftsprozesse modellieren können, gibt es mehrere Phasen, in denen Benutzer mit der Workflowvorlage oder -instanz interagieren können.

Damit der Benutzer Informationen an den Workflow weitergeben kann, muss der Entwickler unter Verwendung eines Formulars eine Schnittstelle für diese Interaktion bereitstellen. Durch das Hinzufügen von Formularen zu Workflows können Sie Ihre Workflows dynamischer und flexibler gestalten. Mithilfe von Formularen können Sie zu vordefinierten Zeitpunkten während der Lebensdauer eines Workflows Informationen von Benutzern sammeln und zulassen, dass Benutzer mit den Aufgaben in dem Workflow interagieren.

Vom technischen Standpunkt aus gesehen können Sie jede beliebige Formulartechnologie bei WF-Workflows einsetzen, so lange Ihre Formulare zu Folgendem in der Lage sind:

  • Aufrufen des Windows SharePoint Services-Objektmodells

  • Generieren der Daten, die an das Windows SharePoint Services-Objektmodell gesendet werden müssen

  • Empfangen und Analysieren der erforderlichen Daten von dem Windows SharePoint Services-Objektmodell

Jegliche Informationen, die an das geladene Formular weitergegeben werden, werden als Zeichenfolge formatiert. Grund dafür ist, dass die Daten in dem Formular wieder an das Objektmodell von Windows SharePoint Services V3 zurückgegeben werden müssen, wenn der Benutzer das Formular übermittelt. Obwohl diese Zeichenfolge in der Regel im XML-Format vorliegt, können Sie alle Datenformate verwenden, die als Zeichenfolge formatiert werden können. Ihr Formular muss in der Lage sein, Zeichenfolgen in diesem Format zu erzeugen und die empfangenen Zeichenfolgen zu analysieren.

Windows SharePoint Services unterstützen Formulare von ASP.NET 2.0. Wie diese Formulare implementiert werden, hängt davon ab, ob der Entwickler Visual Studio 2005 Designer for Windows Workflow Foundation oder SharePoint Designer 2007 als Workflowentwicklungstool verwendet. SharePoint Server 2007 bietet Entwicklern zusätzlich die Möglichkeit, Formulare von Microsoft Office InfoPath in ihre Workflows zu integrieren. Diese InfoPath-Formulare können in den Microsoft Office-Clientanwendungen Microsoft Office Word, Microsoft Office PowerPoint, Microsoft Office Excel und InfoPath sowie im Clientbrowser verwaltet werden und so ein umfangreicheres Clientbenutzerszenario bereitstellen. Weitere Informationen dazu, wie die einzelnen Workflowentwicklungstools Workflowformulare implementieren, finden Sie unter ASP.NET-Formulare in Windows SharePoint Services Workflows, InfoPath-Formulare in SharePoint Server Workflows und ASP.NET-Formulare in SharePoint Designer Workflows.

Welche Formulartechnologie Sie auch verwenden, das Betriebskonzept ist für jedes Formular dasselbe. Zum entsprechenden Zeitpunkt im Workflow zeigen Windows SharePoint Services dem Benutzer das Formular an. Der Benutzer gibt Informationen ein und übermittelt das Formular.

Als Workflowentwickler müssen Sie programmieren, was geschieht, wenn der Benutzer ein Formular übermittelt. In den meisten Fällen führt Ihr Formular einen Aufruf an das Windows SharePoint Services-Objektmodell durch und ruft die entsprechende Methode auf, um die Formularinformationen an die richtige Workflowinstanz weiterzugeben.

Die Informationszeichenfolge kann in jedem beliebigen Format vorliegen, vorausgesetzt, dass sowohl das Formular als auch die Workflowaktivität darauf programmiert sind, die Zeichenfolge zu analysieren. In den meisten Fällen entscheiden Entwickler sich wahrscheinlich für die Verwendung von XML.

Windows SharePoint Services geben die Zeichenfolgeninformationen an das WF-Laufzeitmodul, die Workflowinstanz und letztlich an die richtige Aktivität innerhalb der Workflowinstanz weiter. Die Aktivität, die die Informationen empfängt, kann dann wie programmiert reagieren. In Abbildung 4 wird veranschaulicht, wie ein Formular in einen Workflow integriert wird.

Abbildung 4: Formularintegration in Workflow
Abbildung 4: Formularintegration in Workflow

In Windows SharePoint Services-Workflows werden drei Arten von Formularen verwendet:

  • Zuordnungs- und Initialisierungsformulare:   Zuordnungs- und Initialisierungsformulare werden Benutzern angezeigt, bevor ein Workflow überhaupt gestartet wird. Mithilfe dieser Formulare können Sie Benutzer befähigen, Parameter und andere Informationen für den Workflow festzulegen, bevor er beginnt.

  • Änderungsformulare:   Änderungen sind Optionen, die Sie Benutzern bieten, um den Workflow zu ändern, während dieser für ein Element durchgeführt wird. Sie können Änderungsformulare erstellen, die es Benutzern ermöglichen, die Parameter der Änderung anzugeben.

  • Aufgabenformulare:   Auf der Grundlage des Aufgabentyps des Workflows können Sie auch benutzerdefinierte Formulare für die Aufgaben in Ihrem Workflow angeben. In Windows SharePoint Services wird jedem Workflowaufgabentyp ein Inhaltstyp zugewiesen. Die Inhaltstypdefinition legt fest, ob für einen beliebigen Workflowaufgabentyp ein benutzerdefiniertes Formular angegeben wird.

Diese drei Formulartypen stellen die vordefinierten Phasen dar, in denen Benutzer mit dem Workflow interagieren können. Diese Phasen werden als nächstes erläutert.

Benutzerinteraktionspunkte in Workflows

In diesem Abschnitt erfahren Sie mehr über die verschiedenen Phasen, in denen Benutzer mit Workflows in Windows SharePoint Services und SharePoint Server interagieren können.

Zuordnung

Eine Zuordnung tritt dann auf, wenn ein Siteadministrator die Workflowvorlage in einer bestimmten Dokumentbibliothek, Liste oder einem bestimmten Inhaltstyp zur Verfügung stellt. In dieser Phase passt der Siteadministrator den Workflow an diese bestimmte Dokumentbibliothek, Liste bzw. an den Inhaltstyp an, indem er die folgenden Parameterinformationen angibt:

  • einen eindeutigen Namen für den Workflow

  • die Art der Anwendung des Workflows auf ein bestimmtes Element: entweder automatisch, wenn das Element erstellt oder geändert wird, oder manuell; des Weiteren, welche Rollen (z. B. Administrator oder Mitwirkender) einen Workflow starten können

  • die Aufgabenliste, in der der Workflow Aufgaben erstellen kann

  • die Verlaufsliste, in der der Workflow Verlaufsereignisse wie vom Workflow definiert speichern kann

Zusätzlich kann der Workflowentwickler die Siteverwaltung aktivieren, um den Workflow noch weiter anzupassen. Dabei legt er Parameterinformationen fest, die für diesen bestimmten Workflow spezifisch sind. Der Administrator muss u. U. Parameter, Standardwerte und weitere Informationen für den Workflow angeben, wenn er auf die Elemente in der Liste, der Bibliothek bzw. dem Inhaltstyp angewendet wird, denen der Administrator den Workflow zuordnet.

Das Zuordnen eines Workflows geschieht außerhalb des Workflows selbst. Während der Zuordnung ist keine Workflowinstanz gestartet. Vielmehr speichert Windows SharePoint Services die Zuordnungsinformationen in einer besonderen internen Workflowzuordnungstabelle. Wenn die Workflowinstanz dann gestartet ist, legen Windows SharePoint Services anhand der Zuordnungsdaten (und der Initiierungsdaten, falls vorhanden) die Parameter der neuen Workflowinstanz fest.

Initiierung

Während es bei der Zuordnung um den Workflow geht, der auf eine bestimmte Liste, eine Bibliothek oder einen Inhaltstyp angewendet wird, behandelt die Initiierung den Workflow, der auf ein bestimmtes SharePoint-Element angewendet wird.

Die Initiierung tritt dann auf, wenn ein Benutzer eine Workflowinstanz für ein bestimmtes Element startet. Falls erforderlich, liefert der Benutzer Informationen, die für diesen bestimmten Workflow für dieses Element angepasst sind, und startet dann den Workflow.

Workflowentwickler können es Benutzern mit der Initiierung ermöglichen, die von den Administratoren festgelegten Zuordnungsparameter außer Kraft zu setzen oder anzuhängen bzw. zusätzliche Parameter oder Informationen über den Workflow anzugeben, wenn dieser auf ein SharePoint-Element angewendet wird. Nicht alle Workflows müssen initiiert werden. Ein Workflow, der automatisch startet, kann gar keine Initiierungsparameter haben.

Das Windows SharePoint Services-Workflowprojekt für Visual Studio 2005 Designer for Windows Workflow Foundation enthält eine Aktivität, die als Ereignishandler dient, wenn der Workflow initiiert wird. Diese Aktivität ist die erste Aktivität in jedem Windows SharePoint Services-Workflow.

Änderung

Änderungen ermöglichen es Benutzern, die Parameter oder den Fluss einer Workflowinstanz zu ändern, während sie ausgeführt wird. Als Entwickler haben Sie u. U. Punkte in Ihrem Workflow, an denen Sie Benutzern ermöglichen möchten, den Workflow zu ändern, während er für ein Element ausgeführt wird. Unter Umständen möchten Sie es beispielsweise einem Benutzer ermöglichen, eine Aufgabe einer anderen Person zuzuweisen oder gar dem Workflow eine bestimmte Aufgabe hinzuzufügen. Die Optionen, mit denen Benutzer den Workflow ändern können, während dieser für ein Element durchgeführt wird, werden Änderungen genannt.

Das Windows SharePoint Services-Workflowprojekt für Visual Studio 2005 Designer for Windows Workflow Foundation enthält eine Aktivität, mit der eine Workflowänderung aktiviert werden kann; außerdem eine Aktivität, die als Ereignishandler dient, wenn eine Workflowänderung aktiviert wird.

Aufgaben

Workflowaktivitäten, die von Personen durchgeführt werden, werden in Windows SharePoint Services-Workflows als Aufgaben dargestellt.

Als Workflowentwickler können Sie das Aufgabenschema festlegen. Die Aufgabenauflistung könnte beispielsweise Folgendes beinhalten:

  • Aufgabentitel

  • Name der Person, der die Aufgabe zugewiesen ist

  • Aufgabenstatus

  • Aufgabenpriorität

  • Fälligkeitsdatum der Aufgabe

  • Verknüpfung zu dem referenzierten Element

Der Benutzer kann die Aufgabe dann bei Bedarf bearbeiten. Die Workflowinstanz wird über Änderungen an Workflowaufgaben benachrichtigt und kann darauf wie im Workflow angegeben reagieren.

Das Windows SharePoint Services-Workflowprojekt für Visual Studio 2005 Designer for Windows Workflow Foundation enthält Aktivitäten, die Aufgaben erstellen, löschen und aktualisieren können, außerdem Aufgaben, die als Ereignishandler dienen, wenn Aufgaben erstellt, aktualisiert oder gelöscht werden.

Entwickeln von SharePoint Workflows

Microsoft bietet zwei Entwicklungstools zum Entwickeln von Workflows für Windows SharePoint Services: Visual Studio 2005 Designer for Windows Workflow Foundation und Office SharePoint Designer 2007. Da jedes Entwicklungstool Workflows mit unterschiedlichen Attributen und Möglichkeiten erzeugt, lohnt es sich, jedes Tool detailliert zu betrachten.

In Abbildung 5 werden die verschiedenen Schritte veranschaulicht, die in jedem der Erstellungstools durchgeführt werden müssen, um einen Workflow zu erstellen, bereitzustellen, zuzuordnen und auszuführen. Im Allgemeinen sind die größten Unterschiede zwischen den beiden Tools folgende:

  • Workflowerstellung in Visual Studio 2005 Designer for Windows Workflow Foundation wird von einem professionellen Entwickler durchgeführt, der eine Workflowvorlage erstellt, die auf mehreren Sites bereitgestellt wird und benutzerdefinierten Code sowie Aktivitäten enthält. Der Entwickler gibt die Workflowvorlage zur eigentlichen Bereitstellung und Zuordnung an einen Serveradministrator weiter.

  • Die Workflowentwicklung in SharePoint Designer wird wahrscheinlich von Personen durchgeführt, die keine professionellen Entwickler sind. Das kann ein Webdesigner oder ein Büroanwender sein, der einen Workflow für eine bestimmte Liste oder Dokumentbibliothek erstellen möchte. In diesem Fall ist der Entwickler auf die Workflowaktivitäten in der Liste der „SafeControls“ beschränkt. Der Workflow kann keinen benutzerdefinierten Code enthalten. Der Workflowentwickler stellt die Workflowvorlage als Bestandteil des Workflowentwicklungsprozesses direkt für die Liste oder die Dokumentbibliothek bereit.

Einen detaillierten Vergleich der Fähigkeiten der beiden Tools finden Sie unter Vergleich von Visual Studio 2005 Designer for Windows Workflow Foundation und SharePoint Designer 2007.

Abbildung 5: Workflowentwicklungs-, Bereitstellungs- und Initiierungsprozess
Abbildung 5: Workflowentwicklungs-, Bereitstellungs- und Initiierungsprozess

Entwickeln von SharePoint Workflows in Visual Studio 2005

Visual Studio 2005 Designer for Windows Workflow Foundation ist ein Add-In für Visual Studio 2005. Es bietet eine Möglichkeit, rasch Workflows zu entwickeln. Dabei wird eine grafische Oberfläche verwendet, die sich das Wissen des Entwicklers um die Entwicklungsumgebung Visual Studio zunutze macht.

Visual Studio 2005 Designer for Windows Workflow Foundation ist ein Tool, mit dem Sie den Workflow rasch in einer Weise erstellen können, die in die Entwicklung des Codes integriert ist, der Ihren Geschäftsprozess einkapselt. Dazu bietet Visual Studio 2005 Designer for Windows Workflow Foundation eine grafische Oberfläche mit intuitiven Steuerelementen, die in der vertrauten Entwicklungsumgebung von Visual Studio bereitgestellt wird. Diese Oberfläche beinhaltet folgende Features:

  • eine Drag & Drop-Entwurfsoberfläche, in der Sie aus vordefinierten Workflowaktivitäten, die Sie aus der Toolbox ziehen, benutzerdefinierte Workflows zusammenstellen.

  • eine Oberfläche, in der Sie mit intuitiven grafischen Tools an Ihrem Workflow Markup arbeiten können

  • Integration in das Fenster Eigenschaften, sodass Entwickler Eigenschaften von Workflowaktivitäten entweder über die grafische Oberfläche oder direkt in der Code-Beside-Datei konfigurieren können, wobei die beiden immer synchronisiert bleiben

  • Debuggen Ihrer Workflows durch Anhängen an den Windows SharePoint Services-Prozess, einschließlich des Setzens von Haltepunkten in Ihrem Workflow

  • die Möglichkeit, Fehler-, Kompensations- und Ereignishandler an Aktivitäten anzuhängen und Aktivitäten grafisch auszukommentieren

Visual Studio 2005 Designer für Windows Workflow Foundation ist als Bestandteil des Downloads Microsoft Windows Workflow Foundation Runtime Components Beta 2.2 und Visual Studio 2005 Extensions for Windows Workflow Foundation Beta 2.2 im Microsoft Download Center erhältlich. Dieser Download enthält außerdem das Windows Workflow Foundation-Laufzeitmodul und das Windows Workflow Foundation SDK.

Zur weiteren Unterstützung Ihrer Workflowentwicklung stellt Microsoft zwei Visual Studio-Projektvorlagenpakete für die Verwendung mit Visual Studio 2005 Designer for Windows Workflow Foundation bereit: das eine Paket ist für Windows SharePoint Services Workflows angepasst, das andere zum Erstellen von Workflows für SharePoint Server.

Die Windows SharePoint Services Workflow-Projektvorlage enthält einen Verweis auf den Windows SharePoint Namespace und beinhaltet benutzerdefinierte Workflowaktivitäten, die besonders für die Windows SharePoint Services-Umgebung entwickelt wurden. Mit diesen benutzerdefinierten Aktivitäten können Sie in der Windows SharePoint Services-Umgebung übliche Aufgaben durchführen, wie z. B. Erstellen, Aktualisieren, Abschließen und Löschen von SharePoint-Aufgaben, Senden von E-Mails und Aktivieren von Workflowänderungen.

Das SharePoint Server-Workflowprojekt enthält alles in der Windows SharePoint Services-Workflowprojektvorlage, außerdem einen Verweis auf den SharePoint Server Namespace und zusätzliche Funktionen zum Verwalten von Workflowaufgaben in der SharePoint Server-Arbeitsumgebung.

Der Workflowentwicklungsprozess in Visual Studio

Im Allgemeinen befolgen Sie die folgenden grundlegenden Schritte, wenn Sie mit Visual Studio 2005 Designer for Windows Workflow Foundation Workflows für Windows SharePoint Services oder Office SharePoint Server entwickeln:

  1. Entwickeln Ihres Workflows in Visual Studio 2005 Designer for Windows Workflow Foundation und bei Bedarf Einbeziehen der Code-Beside-Datei.

  2. Entwickeln und Veröffentlichen aller Formulare, die Sie mit Ihrem Workflow verwenden möchten.

  3. Entwickeln der Funktionsdefinitions- und Workflowvorlagen-Definitionsdatei, die Informationen zu der Workflowassembly enthält und die Formulare an die Workflowassembly bindet.

  4. Kompilieren der Workflowdateien in eine .NET-Assembly.

  5. Verpacken der Workflowassembly und der Workflowdefinition sowie deren Bereitstellung mithilfe der Funktionen der Features in Windows SharePoint Services.

  6. Debuggen der Live-Workflowassembly mit Visual Studio 2005 Designer for Windows Workflow Foundation.

  7. Bei Bedarf erneutes Kompilieren und Bereitstellen der Workflowassembly, um alle entdeckten Fehler zu beheben.

In den folgenden Abschnitten erhalten Sie eine Übersicht über jeden dieser Entwicklungsschritte.

Erstellen von Workflows mit Visual Studio 2005 Designer for Windows Workflow Foundation

Wenn Sie ein neues Windows SharePoint Services- oder Office SharePoint Server-Workflowprojekt ausgewählt haben, zeigt Visual Studio die Entwurfsoberfläche von Visual Studio 2005 Designer for Windows Workflow Foundation an (Abbildung 6). Diese Entwurfsoberfläche stellt eine grafische Oberfläche dar, in der Sie Workflows zusammenstellen können, indem Sie verschiedene Aktivitäten aus der Toolbox ziehen und auf der Oberfläche ablegen.

Abbildung 6: Oberfläche von Visual Studio 2005 Designer for Windows Workflow Foundation
Abbildung 6: Oberfläche von Visual Studio 2005 Designer for Windows Workflow Foundation

Wenn Sie eine bestimmte Aktivität in Ihren Workflow ziehen, zeigt Visual Studio 2005 Designer for Windows Workflow Foundation Ihnen die gültigen Positionen für diese Aktivität innerhalb des Workflows an. Sie können eine Aktivität nicht an einer Position platzieren, an dem sie ungültig wäre. Zum Beispiel können Sie eine Send-Aktivität nicht als erste Aktivität in einer Teilstruktur der Listen-Aktivität positionieren. Wie in Abbildung 7 dargestellt, zeigt Visual Studio 2005 Designer for Windows Workflow Foundation grüne Symbole mit Pluszeichen an, um gültige Positionen für die bestimmte Aktivität zu kennzeichnen.

Abbildung 7: Gültige Positionen für eine Workflowaktivität
Abbildung 7: Gültige Positionen für eine Workflowaktivität

Während Sie Ihren Workflow grafisch entwerfen, generiert Visual Studio 2005 Designer for Windows Workflow Foundation das entsprechende Markup.

Wenn Sie außerdem mit Codetrennung arbeiten, enthält Ihr Workflowprojekt eine Code-Behind-Datei, in der Sie die Geschäftslogik Ihres Workflows programmieren. Sie können jederzeit zwischen der Workflowentwurfsoberfläche und der Code-Beside-Datei wechseln.

Einstellen der Workfloweigenschaften

Nachdem Sie die Aktivität dem Workflow hinzugefügt haben, müssen Sie die Eigenschaften der Aktivität festlegen, damit sie innerhalb des Workflows gültig ist. Sie können diese Eigenschaften mit dem standardmäßigen Fenster Eigenschaften in Visual Studio festlegen. Der Datentyp, den Sie angeben können, ist abhängig von dem Datentyp, den die Eigenschaft akzeptiert: Literalwerte, Variablen oder Methodennamen.

Wenn Sie eine Variable für die Eigenschaft angeben möchten, können Sie den Variablennamen in das Fenster Eigenschaften eingeben. In diesem Fall deklariert Visual Studio 2005 Designer for Windows Workflow Foundation die Variable automatisch in der Code-Behind-Datei. Sie können die Variable aber auch in der Code-Behind-Datei deklarieren und sie anschließend im Fenster Eigenschaften auswählen.

Bestimmte Eigenschaften von Aktivitäten sind im Wesentlichen Verweise auf Methoden in der Code-Beside-Datei, die einer bestimmten Signatur entsprechen. Wie bei Variablennamen können Sie den Methodennamen in das Fenster Eigenschaften eingeben und Visual Studio 2005 Designer for Windows Workflow Foundation die Methodensignatur zu der Code-Behind-Datei hinzufügen lassen. Sie können die Methode aber auch in der Code-Behind-Datei erstellen und anschließend im Fenster Eigenschaften auswählen.

Sie können eine Eigenschaft auch an die Eigenschaft einer anderen Aktivität binden.

Handleraktivitäten

Ein Workflow hat u. U. mehrere potenzielle Fehlerpunkte. Es ist wichtig, den Status eines Workflows zu überwachen und Fehler zu melden, sobald sie auftreten, damit Sie Probleme sorgfältig und mit einem Minimum an Aufwand lösen können. Ebenso wichtig für einen Workflow ist der Erhalt der Integrität eines Satzes eng verwandter Aktionen. Dadurch kann der gesamte Vorgang wieder aufgerollt werden, wenn ein Teil des Vorgangs stattfindet und ein anderer nicht. Mit den Aktivitäten FaultHandlerActivity, TransactionScopeActivity, CompensationHandlerActivity und CancellationHandlersActivity können Sie Fehler verarbeiten, den Status eines Workflows verwalten und Probleme beheben, sobald sie auftreten.

Sie können sich eine FaultHandlersActivity-Aktivität als try-Block in der Sprache C vorstellen, an den Sie einen geordneten Satz von FaultHandlerActivity-Aktivitäten anfügen können, die als Ausnahmehandler dienen. Diese Ausnahmehandler können Sie sich als catch-Blocks der Sprache C vorstellen. Wenn während der Ausführung einer zusammengesetzten Aktivität eine Ausnahme auftritt, vergleicht das WF-Laufzeitmodul die Ausnahme mit den Ausnahmetypen, die von den FaultHandlerActivity-Aktivitäten verarbeitet werden. Wenn das Laufzeitmodul keinen übereinstimmenden Ausnahmehandler findet, meldet es die Ausnahme der nächsthöheren zusammengesetzten Aktivität, wo der Prozess wiederholt wird. Dies wird so lange fortgesetzt, bis ein geeigneter Handler gefunden ist.

Sie können auch EventHandlersActivity-Aktivitäten haben, die auf Ereignisse reagieren, indem Sie einer EventHandlerScopeActivity-Aktivität Ereignishandler hinzufügen. Vom Konzept her sind diese Ereignishandler denjenigen in den Sprachen C oder Visual Basic .NET sehr ähnlich. Wenn Sie einen Ereignishandler erstellen möchten, müssen Sie EventDrivenActivity-Aktivitäten verwenden.

CompensationHandlerActivity-Aktivitäten enthalten Code, der die Vorgänge einer zusammengesetzten Aktivität kompensiert oder wieder aufrollt, wenn er nicht erfolgreich durchgeführt wird.

ASP.NET-Formulare in Windows SharePoint Services Workflows

Wie bereits zuvor erwähnt, können Sie mit ASP.NET die Formulare erstellen, die Sie mit Ihrem Windows SharePoint Services Workflow verwenden. Diese Formulare werden dann in den entsprechenden Phasen des Workflows in der Windows SharePoint Services-Benutzeroberfläche angezeigt.

Workflowformulare sind durch Informationen, die Sie durch die XML-Datei mit der Workflowvorlagendefinition bereitstellen, an die Workflowassembly gebunden (late-bound). Das Workflowvorlagen-Definitionsschema enthält Elemente zum Kennzeichnen der URL der verschiedenen Formulartypen, die Sie in Windows SharePoint Services Workflows verwenden können. Dadurch erhalten Sie die Möglichkeit, für alle benutzerdefinierten Workflowänderungen Elemente für Formulare zu erstellen, ebenso wie Formulare für die verschiedenen Typen von SharePoint-Aufgaben, die im Workflow verwendet werden.

In den meisten Fällen enthält die Workflowassembly selbst keinerlei Informationen oder Verknüpfungen zu den Workflowformularen. Entwickler können die zu verwendenden Workflowformulare ändern, indem sie schlicht die Workflowdefinitions-XML bearbeiten, ohne die Workflowassembly selbst neu kompilieren zu müssen. Die einzige Ausnahme bilden Workflowänderungen; jede Aktivität, die eine Workflowänderung aktiviert, muss die GUID des Formulars für diese Workflowänderung enthalten.

InfoPath-Formulare in SharePoint Server Workflows

Sie können zwar auch ASP.NET-Workflowformulare in SharePoint Server Workflows verwenden, doch SharePoint Server bietet Ihnen die Möglichkeit, Ihre Workflowformulare zu erweitern und in Microsoft Office-Clientanwendungen anzuzeigen.

Sie können InfoPath-Formulare mit Ihren Workflows verwenden. Mit InfoPath haben Sie die Möglichkeit, symmetrische Formulare zu erstellen. Das sind Formulare, die immer gleich aussehen und funktionieren, gleichgültig, ob sie in der SharePoint Server Weboberfläche oder in einer Microsoft Office-Clientanwendung wie Word, Excel oder PowerPoint angezeigt werden. Dadurch wird eine ausgezeichnete Interaktion geboten, bei der der Benutzer direkt in der Clientanwendung mit dem Workflow interagieren kann. Er muss den Client nicht verlassen und in die SharePoint Server Weboberfläche wechseln. Als Entwickler sind Sie nicht gezwungen, zwei getrennte Formulare zu erstellen – eines für den Server und das andere für den Client – um dem Benutzer diese Integration in die Clientanwendung zur Verfügung zu stellen.

Weitere allgemeine Informationen zum Erstellen symmetrischer Formulare finden Sie in der Hilfe zum Microsoft Office InfoPath 2007-Client oder in Office Online.

SharePoint Server verwaltet Workflow-Formulare mit Office Forms Services, einer serverbasierten Laufzeitumgebung für InfoPath-Formulare. Office Forms Services nutzt die Formulare, die Sie in der InfoPath-Clientanwendung erstellen, und gibt sie in einem ASP.NET Framework wieder, das als Laufzeitumgebung für das Formular dient. Diese Umgebung bietet eine Benutzerfreundlichkeit bei der Formularbearbeitung, die derjenigen in der InfoPath-Clientanwendung gleicht.

Weitere Informationen zu Office Forms Services finden Sie im Microsoft Office SharePoint Server 2007 SDK.

Hinweis:   Da Office 2007-Clientanwendungen wie Word, PowerPoint und Excel Funktionen zum Verwalten von InfoPath-Formularen enthalten, muss der Benutzer die InfoPath-Clientanwendung nicht installiert haben, um diese reichhaltige Integration nutzen zu können.

Anzeigen von InfoPath-Workflowformularen

SharePoint Server zeigt mit derselben grundlegenden Technik alle benutzerdefinierten InfoPath-Workflowformulare an, einschließlich Zuordnungs-, Initiierungs- und Änderungsformularen bzw. Formularen zum Bearbeiten von Aufgaben.

Wenn der Benutzer auf eine Verknüpfung klickt, um ein Workflowformular in der SharePoint Server-Oberfläche anzuzeigen, lädt SharePoint Server eine ASPX-Seite, die ein Office Forms Services-Webpart enthält. Dieses Webpart konvertiert dann das entsprechende InfoPath-Formular in ASP.NET und lädt es. Wenn der Benutzer dieses Formular übermittelt, empfängt das Webpart die Daten aus dem Formular und verarbeitet diese dementsprechend.

Die ASPX-Seiten, die das Office Forms Services-Webpart enthalten, sind in SharePoint Server enthalten.

Angeben von InfoPath-Workflowformularen

Die benutzerdefinierten Formulare, die Sie verwenden möchten, geben Sie in der Workflowvorlagendefinition an, und nicht im Workflow selbst. In den meisten Fällen müssen dazu zwei Elemente festgelegt werden. Zunächst legen Sie die Formular-URL für diesen Workflowprozess (Zuordnung, Initiierung, Änderung und so weiter) auf der entsprechend bereitgestellten ASPX-Seite fest, die in SharePoint Server enthalten ist. Als Nächstes fügen Sie ein Element hinzu, das den URN für das benutzerdefinierte InfoPath-Formular für diesen Typ von Workflowprozess angibt.

Übermitteln von Informationen mit InfoPath-Workflowformularen

Damit die bereitstellende ASPX-Seite Daten von dem bereitgestellten Formular empfangen kann, fügt der Entwickler dem InfoPath-Formular die Schaltfläche Absenden hinzu. Diese Schaltfläche verwendet eine Regel zum Übermitteln von Daten, indem die Datenverbindung zur Hostumgebung verwendet wird. Diese Verbindung gibt die Daten automatisch an die bereitstellende ASPX-Seite zurück, wenn der Benutzer auf die Schaltfläche Absenden klickt. Anschließend analysiert die bereitstellende ASPX-Seite die Daten und gibt diese nach Bedarf an den Workflow oder die Dokumentbibliothek zurück.

Bereitstellen von Workflows

Wenn Sie die Festlegung Ihres Workflows abgeschlossen haben, können Sie Ihren Workflow als Workflow oder als Aktivität kompilieren.

Nachdem Sie Ihren Workflow kompiliert haben, können Sie mit den Funktionen der SharePoint-Features die Workflowassembly und alle erforderlichen unterstützenden Dateien zusammenpacken und bereitstellen.

Featureverpackung ist eine Möglichkeit, Lösungen und Funktionen von Windows SharePoint Services einzukapseln, um die Bereitstellung zu erleichtern. Dadurch können Entwickler die Dateien, die für eine Lösung erforderlich sind, zur leichteren Verteilung und Bereitstellung zusammenpacken. Diese Dateien umfassen z. B. Workflows, Webparts, Listen und Sitedefinitionen. Entwickler packen die erforderlichen Dateien in eine WSP-Datei. Dies ist im Wesentlichen eine CAB-Datei mit einem Manifest, in dem der Inhalt aufgelistet ist. Weitere Informationen zu SharePoint-Features finden Sie im Microsoft Windows SharePoint Services V3 SDK.

Jede Workflowvorlage, die Sie bereitstellen, muss eine Workflowvorlagen-Definitionsdatei enthalten. Bei einer Workflowvorlagendefinition handelt es sich um eine XML-Datei, die jene Informationen enthält, die Windows SharePoint Services zum Instanziieren und Ausführen des Workflows benötigt. Dazu gehören Folgende:

  • der Name, die GUID und die Beschreibung der Workflowvorlage

  • die Assembly

  • die URLs (oder URNs für IP-Formulare) aller benutzerdefinierten Formulare, die mit dieser Workflowvorlage verwendet werden

  • optional die Namen des Workflows, des Workflowmoduls und der Hostdienstassemblys, die beim Ausführen des Workflows zu verwenden sind

  • optional die richtigen Klassen innerhalb dieser Assemblys, die aufgerufen werden sollen

Die Workflowassembly selbst muss im globalen Assemblycache bereitgestellt werden.

Nachdem der Workflow auf einer Site bereitgestellt wurde, steht er als Workflowvorlage zur Verfügung. SharePoint-Administratoren können diese Vorlage den Dokumentbibliotheken und Listen auf dieser Site zuordnen.

Debuggen von Workflows

Nachdem Sie Ihre Workflowassembly bereitgestellt haben, können Sie Ihren Workflow debuggen, indem Sie Ihr Workflowprojekt öffnen und an den Windows SharePoint Service-Prozess w3wp anhängen.

Da Visual Studio 2005 Designer for Windows Workflow Foundation innerhalb von Visual Studio bereitgestellt wird, können Sie die Debuggingmöglichkeiten von Visual Studio voll ausnutzen. Sie können Fehlerpunkte sowohl in dem Code setzen, den Sie in Ihre Code-Beside-Datei schreiben, als auch in den Workflowaktivitäten in der Entwurfsoberfläche.

Hinweis:   Um das Debuggen zu erleichtern, wird dringend empfohlen, Ihre Workflowvorlagen auf dem Server zu entwickeln, auf dem Sie sie auch bereitstellen möchten.

Visual Studio 2005 Designer for Windows Workflow Foundation unterstützt nicht nur standardmäßige Visual Studio-Debuggingfunktionen wie die Fenster Haltepunkt und Aufrufliste. Das Programm enthält auch eine ganze Reihe visueller Indikatoren, die während des Debuggens Informationen bereitstellen. Sie können auch Haltepunkte zu einer Workflowaktivität hinzufügen, während Sie die Assembly debuggen.

Sie können Einzelschritt-, Rücksprung- und Prozedurschrittvorgänge durchführen, um sich durch den Workflowcode zu bewegen.

Die folgenden Arten von Debugging werden nicht von Visual Studio 2005 Designer for Windows Workflow Foundation unterstützt:

  • Just-In-Time-Debuggen von Laufzeitausnahmen im Hostprozess

  • Just-In-Time-Debuggen durch Auswählen eines Prozesses im Task-Manager

Weitere Informationen zum Debuggen mit Visual Studio 2005 Designer for Windows Workflow Foundation finden Sie im Windows Workflow Foundation SDK.

Hinweis:   Das Windows Workflow Foundation SDK ist als Bestandteil des Downloads Microsoft Windows Workflow Foundation Runtime Components Beta 2.2 und Visual Studio 2005 Extensions for Windows Workflow Foundation Beta 2.2 im Microsoft Download Center erhältlich. Dieser Download enthält außerdem Visual Studio 2005 Designer for Windows Workflow Foundation und das Windows Workflow Foundation-Laufzeitmodul.

Entwickeln von SharePoint Workflows in SharePoint Designer 2007

Wenn Sie einen Workflow in Office SharePoint Designer 2007 erstellen, entwickeln Sie diesen Workflow direkt und mit Datenbindung auf der Grundlage einer bestimmten Liste bzw. Dokumentbibliothek in Windows SharePoint Services. Sie verwenden eine vordefinierte Liste von Workflowaktivitäten und keinerlei Code. Der von Ihnen entworfene Workflow wird nicht als Assembly kompiliert, sondern er wird in Quelldateien gespeichert, bis er bei der ersten Ausführung von Windows SharePoint Services kompiliert wird.

Ein solcher Ansatz hat mehrere Vorteile:

  • Workflows können schnell entwickelt und getestet werden.

  • Da der Workflow speziell auf der Grundlage einer bestimmten Liste erstellt wurde, ist der Bereitstellungsprozess sehr viel einfacher.

  • Aus demselben Grund gibt es auch viel weniger Sicherheitsprobleme.

  • Da sie nicht in Assemblys kompiliert werden, können in SharePoint Designer erstellte Workflows auf Servern bereitgestellt werden, auf denen die Verwaltungsrichtlinie die Bereitstellung von Assemblys mit benutzerdefiniertem Code untersagt.

    Hinweis:   In SharePoint Designer entwickelte Workflows werden mithilfe einer „sicheren Liste“ von vordefinierten Aktivitäten zusammengestellt, die vermutlich von Administratoren für die Ausführung auf den Servern genehmigt wurden.

  • Workflows können von Benutzern mit geringer Entwicklungserfahrung erstellt werden, z. B. Webdesignern oder Büroanwendern.

Dieser Ansatz bedeutet auch, dass die in SharePoint Designer entwickelten Workflows sich von den mit Visual Studio 2005 Designer for Windows Workflow Foundation erstellten in mehreren wichtigen Punkten unterscheiden:

  • Ein in SharePoint Designer entwickelter Workflow kann nicht in mehreren Listen bereitgestellt werden. Er gilt nur für die Liste, für die er erstellt wurde.

  • Da Sie den Workflow direkt auf Grundlage einer Liste entwickeln, wird der Workflow zur Entwurfszeit der Liste zugeordnet. Deshalb haben in SharePoint Designer entwickelte Workflows keine Zuordnungsphase.

  • Workflowänderungen sind für in SharePoint Designer entwickelte Workflows nicht verfügbar.

  • In SharePoint Designer können Sie nicht auf Grundlage eines Inhaltstyps entwickeln.

Einen ausführlichen Vergleich finden Sie unter Vergleich von Visual Studio 2005 Designer for Windows Workflow Foundation und SharePoint Designer 2007.

Ausführen von Workflows, die in SharePoint Designer 2007 erstellt wurden

Da sie keinen benutzerdefinierten Code enthalten, werden in Office SharePoint Designer erstellte Workflows nicht kompiliert und als Assemblys bereitgestellt. Stattdessen werden sie in ihren Quelldateien innerhalb von Windows SharePoint Services gespeichert und nur bei Bedarf in den Speicher kompiliert.

Für jede Site werden die Workflows dieses Typs in einer separaten Dokumentbibliothek gespeichert. Diese Dokumentbibliothek enthält einen Ordner für jeden Workflow, der in SharePoint Designer erstellt wird. Der Ordner enthält alle für den Workflow erforderlichen Dateien, einschließlich:

  • der Workflow Markup-Datei

  • der Workflow-Regeldatei

  • ASPX-Formularen für alle erforderlichen benutzerdefinierten Workflowformulare

Windows SharePoint Services enthält einen Just-In-Time-Compiler, mit dem die Quelldateien in einen Workflow kompiliert werden, wenn dieser Workflow zum ersten Mal für ein Element gestartet wird. Windows SharePoint Services behält den kompilierten Workflow für den Zeitpunkt, an dem er erneut aufgerufen wird, im Speicher – so ähnlich wie Server kompilierte ASPX-Seiten im Speicher bewahren, um die Ausführungsleistung zu steigern, wenn die Seite das nächste Mal aufgerufen wird.

Jedes Mal, wenn ein Workflow für ein Element gestartet wird, ermitteln die Windows SharePoint Services, ob der Workflow als Assembly oder aus Quelldateien bereitgestellt wurde. Ist ein Workflowassembly vorhanden, rufen Windows SharePoint Services diese Assembly auf, um die Workflowinstanz zu erstellen. Wenn der Workflow aus Quelldateien bereitgestellt wurde, ermitteln Windows SharePoint Services, ob im Speicher bereits ein Workflow vorhanden ist, der aus diesen Quelldateien kompiliert wurde. Wenn das der Fall ist, rufen Windows SharePoint Services den kompilierten Workflow im Speicher auf, um die Workflowinstanz zu erstellen. Ist das nicht der Fall, kompilieren Windows SharePoint Services mit ihrem Just-In-Time-Compiler die Quelldateien in einen Workflow im Speicher, der dann aufgerufen wird, um die Workflowinstanz zu erstellen.

Workflowentwicklungsprozess in SharePoint Designer 2007

Zur Unterstützung der schnellen Entwicklung und Bereitstellung von Workflows ist der Entwicklungsprozess in SharePoint Designer viel einfacher als in Visual Studio.

Im Allgemeinen befolgen Sie diese grundlegenden Schritte, wenn Sie mit Visual Studio 2005 Designer for Windows Workflow Foundation Workflows für Windows SharePoint Services oder Office SharePoint Server entwickeln:

  1. Sie entwickeln Ihren Workflow, indem Sie die in SharePoint Designer vordefinierten Aktivitäten und Bedingungen zusammenstellen und konfigurieren.

  2. Sie lassen SharePoint Designer automatisch ASP.NET-Formulare für die Workflowinitiierung und ggf. alle benutzerdefinierten SharePoint-Aufgaben generieren.

  3. Gegebenenfalls passen Sie die Workflowformulare an.

SharePoint Designer generiert automatisch die Workflowvorlagendefinition und kümmert sich um die Bereitstellung des Workflows in der angegebenen Liste.

In den folgenden Abschnitten erhalten Sie eine Übersicht über jeden dieser Entwicklungsschritte.

Erstellen von Workflows mit SharePoint Designer 2007

SharePoint Designer verwendet eine assistentengesteuerte Oberfläche, mit der Benutzer sequenzielle Workflows aus vordefinierten Aktivitäten zusammenstellen können. Benutzer wählen Aktivitäten aus einer vordefinierten Liste aus und konfigurieren sie mit der SharePoint Designer-Oberfläche. Bei diesen Aktivitäten kann es sich um dieselben Aktivitäten handeln wie in Visual Studio 2005 Designer for Windows Workflow Foundation; die Aktivitäten dieser beiden Tools unterscheiden sich nicht voneinander.

In SharePoint Designer jedoch wird jede Aktivität als Aktion angezeigt, dargestellt durch einen Satz mit Variablen, die der Benutzer mithilfe von Dropdownmenüs und Nachschlage-Dialogfeldern konfigurieren kann. Benutzer können auch Bedingungen auswählen, bei denen es sich um konfigurierbare Bedingungssätze handelt, die den Fluss des Workflows dirigieren.

Während der Benutzer Bedingungen und Aktionen in der Workflowoberfläche auswählt und konfiguriert, generiert SharePoint Designer die beiden Dateien, die die Workflowklasse repräsentieren:

  • die Workflow Markup-Datei mit Markup, das die in dem Workflow enthaltenen Aktivitäten beschreibt

  • die Workflow-Regeldatei, die die Geschäftslogik des Workflows in Form deklarativer Regeln enthält, und nicht in Code

Hinzufügen von benutzerdefinierten Aktivitäten und Bedingungen

Wie angemerkt können Workflowentwickler in SharePoint Designer keine benutzerdefinierten Aktivitäten zur Verwendung in Ihren Workflows erstellen. Stattdessen sind sie auf die Aktivitäten und Bedingungen beschränkt, die in der Liste der „Safe Controls“ (vermutlich von einem Serveradministrator genehmigt) zur Verfügung gestellt wurden, die in SharePoint Designer angezeigt wird.

Bei einer Bedingung handelt es sich schlicht um eine benutzerdefinierte Assembly mit einer statischen Methode, die eine Bedingung bewertet und bei Aufruf einen booleschen Ausdruck zurückgibt.

Entwickler können benutzerdefinierte Aktivitäten und Bedingungen erstellen und diese in der „sicheren Liste“ zur Verfügung stellen. Dazu müssen Entwickler Folgendes tun:

  1. Die Aktivität oder Bedingung erstellen, als Assembly mit starkem Namen kompilieren, und im globalen Assemblycache bereitstellen.

  2. Die Aktivität oder Bedingung zu der sicheren Liste der Aktivitäten in der Datei web.config hinzufügen.

  3. In der Datei WSS.Actions, die sich im Workflowordner befindet, Regeln und Parameter für den Satz hinzufügen, der die Aktivität oder Bedingung in der SharePoint Designer-Benutzeroberfläche repräsentiert. Durch dieses Markup wird festgelegt, wie die Aktivität bzw. Bedingung in der Oberfläche angezeigt und durchgeführt wird, da diese Informationen nicht in der Aktivitäts- oder Bedingungsassembly vorhanden sind.

Weitere Informationen zum Bereitstellen von benutzerdefinierten Aktivitäten und Bedingungen finden Sie in der Hilfe zu SharePoint Designer.

ASP.NET-Formulare in SharePoint Designer Workflows

In SharePoint Designer können Sie eine Initiierungsphase für Ihren Workflow erstellen. Wenn Sie dies tun, generiert SharePoint Designer gemäß Ihren Initiierungsspezifikationen unter Verwendung von ASP.NET automatisch ein Initiierungsformular.

In ähnlicher Weise können Sie benutzerdefinierte SharePoint-Aufgaben für Ihren Workflow erstellen. SharePoint Designer generiert gemäß Ihren Spezifikationen automatisch ein ASP.NET-Formular für die Aufgabe.

Diese ASPX-Formulare werden mit den Quelldateien des Workflows auf der SharePoint-Site gespeichert. Sie können sie wie jedes andere ASPX-Formular öffnen und anpassen.

Hinweis:    SharePoint Designer 2007 bietet keine Integration in InfoPath-Formulare.

Bereitstellen von Workflows mit SharePoint Designer 2007

Da Sie auf Grundlage einer bestimmten Liste entwickeln, ist die Bereitstellung von Workflows, die in Office SharePoint Designer erstellt wurden, viel einfacher als bei Workflows, die in Visual Studio 2005 Designer for Windows Workflow Foundation erstellt wurden. SharePoint Designer verarbeitet die Bereitstellung des Workflows in der angegebenen Liste.

SharePoint Designer bietet keine benutzerdefinierte Debuggingfunktion.

Wenn ein in SharePoint Designer erstellter Workflow aus einer Liste gelöscht wird, werden die Quelldateien, aus denen dieser Workflow in den Speicher kompiliert wurde, nicht gelöscht. Vielmehr ist der Workflow nicht mehr der Liste zugeordnet, doch die Quelldateien bleiben in der Workflow-Dokumentbibliothek auf der Site gespeichert.

Im Windows SharePoint Services-Objektmodell lassen sich Workflows, die in SharePoint Designer erstellt wurden, nicht von Workflows unterscheiden, die in Visual Studio 2005 Designer for Windows Workflow Foundation erstellt wurden.

Vergleich von Visual Studio 2005 Designer for Windows Workflow Foundation und SharePoint Designer 2007

Die folgende Tabelle bietet einen detaillierten Vergleich zwischen den Möglichkeiten von Visual Studio 2005 Designer for Windows Workflow Foundation und Office SharePoint Designer 2007 sowie den Workflows, die Sie mit jedem Programm erstellen können.

Tabelle 1: Detaillierter Vergleich der Möglichkeiten

Visual Studio 2005 Designer for Windows Workflow Foundation

SharePoint Designer 2007

Kann Workflows für Windows SharePoint Services oder SharePoint Server schreiben

Kann Workflows für Windows SharePoint Services oder SharePoint Server schreiben

Mit einer Code-Behind-Datei kann der Entwickler benutzerdefinierten Code in Visual C# oder Visual Basic .NET schreiben, um die Geschäftslogik auszudrücken

Keine Code-Behind-Datei; Workflow-Regeldatei kapselt Geschäftslogik deklarativ ein

Generiert Workflow Markup-Datei

Generiert Workflow Markup-Datei

Workflow wird als Vorlage erstellt, die mehreren Sites und Listen zugeordnet werden kann

Workflow wird zur Entwurfszeit mit Datenbindung auf Grundlage einer bestimmten Liste erstellt

Workflow Markup-Datei oder Markup und Code-Behind-Dateien werden in Workflowassembly kompiliert

Workflow Markup, Workflowregeln und unterstützende Datei werden unkompiliert in einer bestimmten Dokumentbibliothek auf der Site gespeichert

Workflowvorlage muss jeder Liste zugeordnet werden, in der sie verfügbar sein soll

Zuordnung geschieht, wenn der Workflow auf Grundlage der bestimmten Liste erstellt wird; später ist keine Zuordnung mehr erforderlich oder möglich

Kann jede Formulartechnologie verwenden, z. B. ASP-Formulare für Windows SharePoint Services Workflows oder InfoPath-Formulare für SharePoint Server Workflows

Generiert automatisch ASP.NET-Formulare, die Sie dann anpassen können

Kann Workflowänderungen enthalten

Workflowänderungen nicht verfügbar

Kann benutzerdefinierte, symmetrische InfoPath-Formulare verwenden, wodurch die Integration benutzerdefinierter Workflowformulare in Office-Client ermöglicht wird

Integration von InfoPath-Formularen nicht verfügbar

Kann benutzerdefinierte Aktivitäten für Einbeziehung in Workflows erstellen

Muss die bereitgestellten Aktivitäten verwenden

Verpackt Workflowassembly und Workflowdefinition als SharePoint-Feature und stellt diese auf der Site bereit

Verarbeitet Bereitstellung in einer bestimmten Liste automatisch

Kann beim Starten des Workflows anhand des Initiierungsformulars Informationen vom Benutzer sammeln

Kann beim Starten des Workflows anhand des Initiierungsformulars Informationen vom Benutzer sammeln

Kann benutzerdefinierte Formulare verwenden, damit Benutzer mit SharePoint-Aufgaben interagieren können

Kann benutzerdefinierte Formulare verwenden, damit Benutzer mit SharePoint-Aufgaben interagieren können

Visual Studio-Debugging verfügbar

Kein schrittweises Debuggen verfügbar

Kann sowohl sequenzielle Workflows als auch Statusmechanismusworkflows erstellen

Kann nur sequenzielle Workflows erstellen

Workflowstruktur in Windows SharePoint Services

In Abbildung 8 wird veranschaulicht, wie die verschiedenen Elemente der Windows SharePoint Services-Workflowstruktur miteinander verbunden werden, nachdem eine Workflowvorlage erstellt, bereitgestellt und einem bestimmten Inhaltstyp, einer Liste oder einer Dokumentbibliothek zugeordnet wurde.

Wenn Sie eine Workflowvorlage einem bestimmten Inhaltstyp, einer Liste oder Dokumentbibliothek zuordnen, schreibt Windows SharePoint Services die vom Administrator festgelegten Informationen bezüglich der Zuordnungsparameter in eine Workflowzuordnungstabelle auf Farmebene. Durch den Eintrag in diese Zuordnungstabelle wird der bestimmte Inhaltstyp, die Liste oder die Dokumentbibliothek mit der Workflowvorlagendefinition des zugeordneten Workflows verknüpft. Die Informationen in der Workflowvorlagendefinition wiederum enthalten Verweise auf die Workflowassembly selbst, des Weiteren alle benutzerdefinierten Workflowformulare, die vom Workflow verwendet werden.

Bei in SharePoint Designer 2007 entwickelten Workflows schreibt der Designer die Informationen bezüglich der Zuordnungsparameter automatisch in die Workflowzuordnungstabelle und generiert und installiert die Workflowvorlagendefinition. Außerdem wird der Workflow in einer Workflow-Dokumentbibliothek auf Siteebene gespeichert, und zwar nicht als kompilierte Assembly, sondern als Markup und Quelldateien mit Workflowregeln.

Abbildung 8: Struktur der Workflowkomponenten in Windows SharePoint Services
Abbildung 8: Struktur der Workflowkomponenten in Windows SharePoint Services

Verwenden des Workflow Namespace

Nachdem Sie Ihre Workflowlösung bereitgestellt haben, können Sie mit dem Windows SharePoint Services-Objektmodell Workflowprozesse abfragen und programmgesteuert Workflowaktionen wie das Hinzufügen eines Workflows zu einer Liste oder das Starten eines Workflows für ein Element durchführen.

Hauptobjekte von „Microsoft.Windows.SharePoint.Workflow“

Der Namespace Microsoft.Windows.SharePoint.Workflow repräsentiert die in Windows SharePoint Services enthaltene Workflowfunktionalität.

Das Objekt SPWorkflowTemplateCollection stellt die aktuell auf einer Site bereitgestellten Workflowvorlagen dar. Jedes SPWorkflowTemplate-Objekt repräsentiert eine Workflowvorlage und enthält Eigenschaften, mit denen Sie Informationen über die Vorlage abrufen oder festlegen können, wie etwa die Instanziierungsdaten und die Verlaufs- und Aufgabenlisten für die Vorlage.

Mit der Methode SPList.AddWorkflowAssociation können Sie einen Workflow einer Liste oder Dokumentbibliothek zuordnen. Diese überladene Methode benötigt vier Parameter:

  • den Namen oder die Kennung der Workflowvorlage

  • den Namen, den Sie dem Workflow geben möchten

  • den Namen oder die Kennung der Aufgabenliste, die Sie mit diesem Workflow verwenden möchten

  • die Verlaufsliste für den Workflow

Wie beim Hinzufügen eines Workflows über die Benutzeroberfläche fügt diese Methode der Liste eine Statusspalte für den Workflow hinzu. Mit der Methode SPList.RemoveWorkflowAssociation entfernen Sie eine Workflowvorlage aus einer Liste.

Das Objekt SPWorkflowAssociationCollection stellt die interne Workflowzuordnungstabelle für eine Site dar; d. h., es repräsentiert die Workflows, die aktuell Listen einer Websitesammlung zugeordnet sind, zusammen mit den jeweiligen Zuordnungsinformationen. Jedes SPWorkflowAssociation-Objekt repräsentiert eine Workflowvorlage, die einer bestimmten Liste zugeordnet wurde. Diese Objekte enthalten Eigenschaften, die benutzerdefinierte Informationen über die Zuordnung zurückgeben, z. B. ob der Workflow aktiviert ist, ob der Workflow geändert wurde, die Liste, der der Workflow zugeordnet ist, und außerdem einen Verweis auf das Objekt SPWorkflowTemplate, das als Grundlage für dieses SPWorkflowAssociation-Objekt dient.

Die Eigenschaft SPWorkflowAssociation.IsDeclarative gibt für Workflows, die als unkompilierte Dateien (wie die in SharePoint Designer erstellten) gespeichert werden, True zurück.

SPWorkflowCollection stellt die Workflowinstanzen dar, die für ein bestimmtes Listenelement ausgeführt wurden bzw. aktuell ausgeführt werden. Jedes SPWorkflow-Objekt enthält Eigenschaften, die Informationen über die Workflowinstanz zurückgeben, z. B. ob der Workflow abgeschlossen wurde, seinen internen Status sowie die Workflowvorlage, auf der er basiert. Zusätzlich enthält jeder Workflow eine Sammlung der Aufgaben für den Workflow: SPWorkflowTaskCollection.

Mit der Eigenschaft SPListItem.Workflows geben Sie ein SPWorkflowCollection-Objekt zurück, das die Workflows darstellt, die aktuell für dieses Listenelement ausgeführt werden.

Programmgesteuertes Verwalten ausgeführter Workflowinstanzen

Benutzer interagieren mithilfe der Windows SharePoint Services-Benutzeroberfläche individuell mit den Workflows, die für Elemente ausgeführt werden. Doch Windows SharePoint Services bietet Funktionen, mit denen Sie die ausgeführten Instanzen von Workflows in Ihrer gesamten Serverfarm zentral durch das Objektmodell steuern können. Mit dem Objekt SPWorkflowManager können Sie die ausgeführten Instanzen von Workflows in der gesamten Farm verwalten. Das Objekt SPWorkflowManager hat keine Entsprechung in der Benutzeroberfläche. Obwohl über das Objekt SPSite auf das Objekt zugegriffen wird, können Sie damit die Workflowinstanzen verwalten, die in Ihrer gesamten Farm ausgeführt werden. Mit dem Objekt SPWorkflowManager können Sie:

  • Workflows starten, ausführen und abbrechen.

  • Alle derzeit für ein bestimmtes Element ausgeführten Workflows zurückgeben.

  • Alle Workflowinstanzen abbrechen, die auf einer bestimmten Workflowvorlage innerhalb einer Liste basieren.

  • Weitere Workflowverwaltungsvorgänge durchführen.

Verwenden Sie die Methode SPSite.WorkflowManager.StartWorkflow, um einen bestimmten Workflow für ein Element manuell zu starten (damit ist ein Workflow gemeint, der nicht für automatisches Starten konfiguriert ist). Diese Methode erfordert drei Parameter: den Namen des Listenelements, den Namen der Workflowvorlage und das Startereignis.

In Abbildung 9 ist eine hierarchische Ansicht des Objekts SPWorkflowManager und der darin enthaltenen Objekte dargestellt.

Abbildung 9: Objekthierarchie in SPWorkflowManager
Abbildung 9: Objekthierarchie in SPWorkflowManager

Schlussbemerkung

Windows SharePoint Services V3 stellt Windows Workflow Foundation bereit. Dadurch können Sie benutzerdefinierte Geschäftsprozesse, die als sequenzielle Workflows oder Statusmechanismusworkflows implementiert werden, an SharePoint-Elemente anfügen. Diese Implementierung beinhaltet die Fähigkeit, benutzerdefinierte Workflows zu erstellen, zusammen mit der Formularintegration für Benutzereingriffe. SharePoint Server 2007 erweitert diese Workflowfunktionen, indem es die Integration in symmetrische InfoPath-Formulare anbietet, die in Office-Clientanwendungen wie Word, PowerPoint, Excel und InfoPath bereitgestellt werden können.

Microsoft bietet zwei leistungsfähige Entwicklungstools zum Entwickeln von Workflows für Windows SharePoint Services: Visual Studio 2005 Designer for Windows Workflow Foundation ist ein Add-In für Visual Studio 2005, mit dem Sie Workflowvorlagen zusammen mit benutzerdefiniertem Code entwickeln können, die Sie in mehreren Sites und Listen bereitstellen können. Alternativ können Sie SharePoint Designer verwenden, um aus einer vordefinierten Liste von Workflowaktivitäten rasch listenspezifische Workflows zu entwickeln und bereitzustellen.

In beiden Fällen können Sie nach der Bereitstellung Ihrer Workflowlösung das Windows SharePoint Services-Objektmodell verwenden, um Workflowprozesse abzufragen und programmgesteuert Workflowaktionen durchzuführen.

Weitere Ressourcen


Anzeigen: