Galileo Computing < openbook > Galileo Computing - Professionelle Bücher. Auch für Einsteiger.
Professionelle Bücher. Auch für Einsteiger.

Inhaltsverzeichnis
Geleitwort zu diesem Buch
Inhalt des Buchs
1 Warum eine neue Server-Version?
2 Editionen und Lizenzen
3 Hardware und Dimensionierung
4 Protokolle
5 Was überhaupt ist .NET?
6 Installation
7 Core-Installationsoption
8 Active Directory-Domänendienste
9 Netzwerkdienste im AD-Umfeld
10 Active Directory Lightweight Directory Services (AD LDS)
11 Active Directory-Verbunddienste (Federation Services)
12 Active Directory-Zertifikatdienste
13 Active Directory-Rechteverwaltungsdienste (AD RMS)
14 »Innere Sicherheit«
15 Dateisystem und Dateidienste
16 Drucken
17 Webserver (IIS)
18 SharePoint (Windows SharePoint Services, WSS)
19 Remotedesktopdienste (Terminaldienste)
20 Hochverfügbarkeit
21 Datensicherung
22 Servervirtualisierung mit Hyper-V
23 Windows PowerShell
24 Windows 7 und Windows Server 2008 R2
Stichwort

Download:
- ZIP, ca. 104 MB
Buch bestellen
Ihre Meinung?

Spacer
<< zurück
Windows Server 2008 R2 von Ulrich B. Boddenberg
Das umfassende Handbuch
Buch: Windows Server 2008 R2

Windows Server 2008 R2
geb., 1.410 S., 59,90 Euro
Galileo Computing
ISBN 978-3-8362-1528-2
Pfeil 18 SharePoint (Windows SharePoint Services, WSS)
Pfeil 18.1 Warum SharePoint?
Pfeil 18.1.1 Unternehmenswissen
Pfeil 18.1.2 Intranet, Extranet und Internet
Pfeil 18.1.3 Content Manager und andere Rollen
Pfeil 18.1.4 Wie viele Mausklicks? Oder: Über die Benutzereffizienz
Pfeil 18.2 Welche SharePoint-Edition?
Pfeil 18.3 Das initiale Projekt
Pfeil 18.4 Hinweise zur Lizenzierung
Pfeil 18.5 Installation
Pfeil 18.6 Ein erster Blick
Pfeil 18.6.1 Zentraladministration
Pfeil 18.6.2 SharePoint Website
Pfeil 18.6.3 Konfigurationsmöglichkeiten auf der Website
Pfeil 18.6.4 Dateistruktur
Pfeil 18.7 Webanwendung, Websitesammlung, Website
Pfeil 18.7.1 Vorhandene Webanwendung administrieren
Pfeil 18.7.2 Vorhandene Websitesammlung administrieren
Pfeil 18.7.3 Neue Webanwendung und Websitesammung erstellen
Pfeil 18.8 Listen und Dokumentbibliotheken
Pfeil 18.8.1 Listen anlegen
Pfeil 18.8.2 Listen konfigurieren
Pfeil 18.8.3 Listenwebparts
Pfeil 18.8.4 Der Papierkorb
Pfeil 18.8.5 Dokumentbibliotheken
Pfeil 18.8.6 Eingehende E-Mail
Pfeil 18.9 Benutzerverwaltung in SharePoint
Pfeil 18.9.1 SharePoint-Gruppen
Pfeil 18.9.2 AD-Benutzer und Gruppen ohne SharePoint-Gruppen verwenden
Pfeil 18.9.3 AD-Gruppen vs. SharePoint-Gruppen
Pfeil 18.9.4 Berechtigungsstufen
Pfeil 18.9.5 Vererbung
Pfeil 18.10 Webparts
Pfeil 18.10.1 Webparts hinzufügen
Pfeil 18.10.2 Webparts mit dem SharePoint Designer platzieren
Pfeil 18.10.3 Webparts konfigurieren
Pfeil 18.10.4 Der Webpartkatalog
Pfeil 18.10.5 Webparts mit Verbindungen
Pfeil 18.11 Workflows
Pfeil 18.11.1 SharePoint Designer-Workflows vs. Visual Studio-Workflows
Pfeil 18.11.2 SharePoint-Workflows aus 10.000 m Höhe
Pfeil 18.11.3 Standard-Workflows (Drei-Status-Workflow)
Pfeil 18.11.4 SharePoint Designer-Workflows
Pfeil 18.11.5 Visual Studio-Workflows
Pfeil 18.12 Vorlagen
Pfeil 18.13 Abschlussbemerkung


Galileo Computing - Zum Seitenanfang

18.11 Workflows Zur nächsten ÜberschriftZur vorigen Überschrift

Workflow ist in der IT ein magisches Wort geworden. So ziemlich jeder IT-Verantwortliche, den ich in der letzten Zeit getroffen habe, hatte als ein wesentliches Ziel die »Abbildung der Unternehmensprozesse mit Workflows« auf seiner Aufgabenliste.

Da passt es ja gut, dass »SharePoint 2007/3.0 Workflow kann« … Zeit für eine Klarstellung: Die Komponente, die für die Abarbeitung der Workflows zuständig ist, ist Windows Workflow Foundation (WF). WF ist nun allerdings keine Komponente von SharePoint – sonst hieße es vermutlich auch »SharePoint Workflow Foundation«.

Windows Workflow Foundation ist ein Bestandteil des .NET Frameworks 3.0/3.5 (auch als WinFX bekannt) und ist zunächst weder mit SharePoint noch mit einer anderen Applikation oder einem anderen Applikationsserver gekoppelt. Positiv ausgedrückt kann WF grundsätzlich mit allen anderen Komponenten zusammenarbeiten.

WF kann nicht als einzelne Komponente laufen; das heißt, Sie können nicht ein WF-Installationsarchiv nehmen, einen Server vorbereiten und einen »Workflow-Server« installieren. WF ist vielmehr eine Technologie, die Entwickler in ihren Applikationen verwenden können, um Workflows aller Art abzubilden. Die Entwickler von SharePoint haben also die Windows Workflow Foundation in SharePoint integriert, was insbesondere diese Aspekte beinhaltet:

  • SharePoint dient als Host für die Windows Workflow Foundation.
  • Aus SharePoint können WF-Workflows aufgerufen werden. Dies kann sowohl manuell (d. h. durch den Benutzer) als auch automatisch geschehen.

Etwas technischer betrachtet, ist die Integration von WF in SharePoint wesentlich komplexer. So ist beispielsweise ein neuer Namespace (Mirrosoft.SharePoint.Workflow) hinzugekommen, der 21 Klassen enthält, um Workflows zu initiieren und zu steuern. Weiterhin ist der SharePoint Designer (vormals FrontPage) so erweitert worden, dass einfache Workflows ohne Programmierkenntnisse implementiert werden können.

Es gibt also zwei verschiedene Möglichkeiten bzw. Werkzeuge, um Workflows in SharePoint zu implementieren:

  • SharePoint Designer: Mit diesem Werkzeug können Sie einfache Workflows implementieren, ohne Code schreiben zu müssen.
  • Visual Studio: Bei Nutzung von Visual Studio 2005 stehen Ihnen alle Möglichkeiten offen – allerdings werden Sie Code schreiben und sich vergleichsweise intensiv mit »der Technik« beschäftigen müssen.

Steng genommen gibt es sogar noch eine dritte Möglichkeit, um Workflows zu implementieren. In SharePoint sind Workflowvorlagen (MOSS: 4; WSS: 1) vorhanden, mit denen grundlegende Aufgaben wie ein einfacher Genehmigungsworkflow realisiert werden können.

Im nächsten Abschnitt finden Sie einen funktionalen Vergleich zwischen SharePoint Designer- und Visual Studio-Workflows.


Galileo Computing - Zum Seitenanfang

18.11.1 SharePoint Designer-Workflows vs. Visual Studio-Workflows Zur nächsten ÜberschriftZur vorigen Überschrift

Zunächst müssen Sie abschätzen, wie komplex der zu implementierende Workflow letztendlich werden wird. Das Wort »letztendlich« soll darauf hinweisen, dass Sie die Komplexität nach Einbau sämtlicher »Features« berücksichtigen müssen. Es ist sicherlich nicht sonderlich effizient, wenn Sie wochenlang im SharePoint Designer arbeiten, um dann schließlich doch festzustellen, dass Sie einen Visual Studio-Workflow implementieren müssen – Sie fangen in einem solchen Fall definitiv wieder von vorn an!

An dieser Stelle möchte ich betonen, dass der Benutzer, der den Workflow anstößt oder im Rahmen eines Workflows Tätigkeiten vornimmt, nicht unterscheiden kann, ob ein Workflow im SharePoint Designer oder mit Visual Studio erstellt worden ist. Ebenso ist in beiden Fällen die Windows Workflow Foundation die »Grundlage« für die Ausführung des Workflows.

Zielgruppen

Die Werkzeuge SharePoint Designer und Visual Studio wenden sich an zwei unterschiedliche Zielgruppen:

  • SharePoint Designer ist primär ein Werkzeug für Site- und Content-Administratoren, die damit ohne Programmierkenntnisse weniger komplexe Workflows abbilden können.
  • Die Erstellung von Workflows mit Visual Studio ist definitiv eine Aufgabe für Entwickler, da Programmierkenntnisse in C# oder VB.NET und zumindest grundlegende Kenntnisse der ».NET-Welt« erforderlich sind.

Der Vergleich im Detail

Die folgende Tabelle zeigt die Unterschiede zwischen den beiden Entwicklungswerkzeugen:


Tabelle 18.2 Die Entwicklungswerkzeuge im Vergleich

Visual Studio-Workflows SharePoint Designer-Workflows

Mittels Code-Behind-Dateien können Entwickler Business-Logik mit den .NET-Sprachen C# und VB.NET implementieren.

Es gibt keine Möglichkeit, Code-Behind-Dateien zu erstellen, es ist also keine Programmierung möglich.

Ein Workflow wird mit der Workflowvorlage (Template) erstellt, die in mehreren Websites und Listen verwendet werden kann.

Ein Workflow ist stets einer bestimmten Liste zugeordnet und wird zur Design-Zeit an diese fest gebunden.

Die diversen Dateien, mit denen der Workflow beschrieben wird, werden in die Workflow-Assembly kompiliert.

Die verschiedenen Dateien, die den Workflow beschreiben, werden unkompiliert in einer Dokumentbibliothek in der jeweiligen SharePoint-Website gespeichert.

Die Workflowvorlage muss den Listen zugeordnet werden, für die sie verwendet werden soll.

Beim Erzeugen des Workflows mit SharePoint Designer wird der Workflow der Liste direkt zugeordnet. Eine spätere Zuordnung ist nicht notwendig – übrigens auch nicht möglich.

Alle Formulartechnologien können verwendet werden. Dies sind momentan InfoPath-Formulare und ASP.NET-Formulare.

ASP.NET-Formulare werden automatisch erzeugt und können nachträglich editiert werden.

Eigene Aktivitäten (Custom Activities) können entwickelt und verwendet werden.

Grunsätzlich können nur die standardmäßig vorhandenen Aktivitäten verwendet werden; das Entwickeln und Integrieren eigener Aktivitäten mit Visual Studio ist möglich.

Ein Debugging mit dem vollen Leistungsumfang von Visual Studio ist möglich.

Ein Schritt-für-Schritt-Debugging ist nicht möglich.

Sowohl sequenzielle als auch Statuscomputer-Workflows (State Machine Workflows) können entwickelt werden.

Es sind nur sequenzielle Workflows möglich.

Workflow-Modifikationen (Änderungen des Ablaufs zur Laufzeit) sind möglich.

Workflow-Modifikationen sind nicht möglich.


Grundsätzlich lässt sich festhalten, dass die Erstellung eines Workflows mit dem SharePoint Designer deutlich schneller zu realisieren ist. Insofern gibt es auch Gründe, nicht direkt zur »großen Lösung« greifen. Aus der Tabelle ergeben sich die Situationen, in denen Sie Visual Studio verwenden müssen.

Ansonsten ist es natürlich eine Frage der persönlichen »Vorlieben«: Wenn Sie ohnehin fließend C# sprechen und die notwendigen Schritte im Schlaf beherrschen, werden Sie vermutlich gern zu Visual Studio greifen – allein der grafische Designer und die Debugging-Möglichkeiten sind starke Argumente.

In den folgenden Abschnitten werden Sie die beiden Varianten im Einsatz sehen. Machen Sie sich selbst ein Bild davon, welche Entwicklungsmöglichkeit Ihnen eher zusagt.


Galileo Computing - Zum Seitenanfang

18.11.2 SharePoint-Workflows aus 10.000 m Höhe Zur nächsten ÜberschriftZur vorigen Überschrift

Sehr allgemein betrachtet, funktionieren Workflows in SharePoint wie folgt:

  • Ein Workflow »hängt« stets an einem Element; dies kann entweder ein Listeneintrag oder ein Dokument sein.
  • Der Workflow wird entweder automatisch beim Erstellen oder Ändern des Dokuments oder manuell durch den Anwender gestartet.
  • Falls im Rahmen des Workflows Aufgaben (also beispielsweise das Genehmigen eines Urlaubsantrags oder das Freigeben eines Dokuments) für andere Benutzer generiert werden müssen, werden diese in einer Aufgabenliste angelegt und dem entsprechenden Benutzer zugewiesen.
  • Die Benutzer erhalten per E-Mail eine Information darüber, dass ihnen eine Information zugewiesen wurde. In dieser befindet sich ein Link, mit dem die weitere Bearbeitung geschehen kann.

Sehr stark vereinfachend gesprochen, läuft die »Kommunikation« mit den am Workflow beteiligten Benutzern über Einträge in einer Aufgabenliste – das bedeutet allerdings nicht, dass die Anwender ständig diverse Aufgabenlisten durcharbeiten müssten.

Wie Sie bereits gehört haben, beziehen sich Workflows stets auf ein Element, genauer auf einen Listeneintrag oder ein Dokument einer Dokumentbibliothek. Die auf Elemente innerhalb einer Liste bzw. Dokumentbibliothek anwendbaren Workflows werden in den Einstellungen der Liste bzw. Dokumentbibliothek vorgenommen. In Abbildung 18.134 sind die Zusammenhänge grafisch dargestellt:

  • Eine Workflowvorlage ist »technisch gesehen« nichts anderes als ein installierbares Feature.
  • Für eine Liste bzw. Dokumentbibliothek wird ein Workflow definiert, der auf der als Feature installierten Workflowvorlage basiert. In einer Liste bzw. Dokumentbibliothek können mehrere Workflows angelegt werden.
  • Für ein Listenelement wird dann ein Workflow gestartet, der beliebige Aktionen ausführen kann.

Abbildung 18.134 Schematische Darstellung des Zusammenhangs von Workflowvorlagen, Workflows, Listen u.v.a.m.

Wichtiger Hinweis: Diese Skizze gilt nicht (oder nur begrenzt) für Workflows, die mit dem SharePoint Designer 2007 (vormals FrontPage) erstellt werden. Mit SharePoint Designer wird direkt ein Workflow in der Liste bzw. Dokumentbibliothek und keine Workflowvorlage erstellt. Mit Visual Studio hingegen erstellen Sie eine Workflowvorlage, die als Feature installiert wird.

Workfloweinstellungen in der SharePoint-Zentraladministration

In der SharePoint 3.0-Zentraladministration finden Sie auf der Karteikarte Anwendungsverwaltung im Abschnitt Workflowverwaltung einen Link namens Workfloweinstellungen. Dieser führt zu der Dialogseite aus Abbildung 18.135, in der Sie einige Konfigurationseinstellungen vornehmen können – sie bewirken nichts wirklich Bahnbrechendes, aber Sie sollten die Optionen dieser Dialogseite zumindest im Hinterkopf haben, falls Sie sie in dem einen oder anderen Szenario benötigen.

Pro Webanwendung kann hier festgelegt werden, ob

  • benutzerdefinierte Workflows zulässig sind
  • interne Benutzer ohne Zugriff auf die Website benachrichtigt werden sollen, wenn ihnen eine Workflowaufgabe zugewiesen wird
  • externe Benutzer eine Kopie des Dokuments erhalten sollen, das dem Workflow zugrunde liegt

Abbildung 18.135 Dieser Dialog in der SharePoint 3.0-Zentraladministration bietet einige Konfigurationsoptionen für die SharePoint-Workflows.


Galileo Computing - Zum Seitenanfang

18.11.3 Standard-Workflows (Drei-Status-Workflow) Zur nächsten ÜberschriftZur vorigen Überschrift

Bei den SharePoint Services ist eine Workflowvorlage, nämlich für einen Drei-Status-Workflow, vorhanden. Dieser basiert auf folgendem Ansatz:

  • In den Metadaten einer Liste bzw. Dokumentbibliothek muss mindestens eine Spalte vom Typ Auswahl (Menü) vorhanden sein.
  • Für diese Spalte geben Sie drei Auswahlmöglichkeiten (Status) vor, mit denen die drei möglichen Zustände bei der Ausführung des Workflows beschrieben werden. Sie können hier zwar mehr als drei Auswahlmöglichkeiten vorgeben – der Standard-Workflow Drei Status kann diese allerdings nicht berücksichtigen.

Abbildung 18.136 Damit ein Drei-Status-Workflow eingerichtet werden kann, muss eine Spalte vom Typ »Auswahl« vorhanden sein.

Der erste Schritt bei der Konfiguration eines Drei-Status-Workflows ist also, die Liste oder Dokumentbibliothek vorzubereiten, für die ein solcher Workflow ausgeführt werden soll, sprich, eine Spalte vom Typ Auswahl hinzuzufügen. In Abbildung 18.136 sehen Sie, wie das gemacht wird:

  • Navigieren Sie in die Einstellungen der Liste bzw. Dokumentbibliothek, und fügen Sie dort eine zusätzliche Spalte hinzu.
  • Als Spaltentyp geben Sie Auswahl an.
  • Die drei (!) möglichen Werte tragen Sie im Bereich Zusätzliche Spalteneinstellungen ein.

Wenn die Liste bzw. Dokumentbibliothek vorbereitet ist, können Sie in den Workfloweinstellungen das Hinzufügen eines neuen Workflows auswählen. Falls noch kein Workflow vorhanden ist, wird direkt die Dialogseite für das Hinzufügen eines Workflows aufgerufen (Abbildung 18.137). Standardmäßig ist nur eine Workflowvorlage vorhanden, nämlich Drei Status.

Abbildung 18.137 Einrichten eines Workflows

Abbildung 18.138 Das »Association Form« des Drei-Status-Workflows

Anschließend erscheint der Dialog aus Abbildung 18.138, in dem Sie etliche Angaben zu dem neu zu erstellenden Workflow machen können:

  • Im ersten Abschnitt selektieren Sie das Auswahlfeld, das verwendet werden soll. Außerdem weisen Sie die beim Auswahlfeld festgelegten Werte den Workflow-Zuständen zu. Falls Sie bei den vier Feldern keine Eingabemöglichkeit haben, dürfte das daran liegen, dass die Liste bzw. Dokumentbibliothek keine als Auswahlfeld definierte Spalte enthält.
  • In den beiden übrigen Abschnitten definieren Sie, wie sich der Workflow verhalten soll, wenn der Workflow initiiert wird oder der »zwischenzeitliche Status« erreicht wird.

Dieses Formular zur Konfiguration des Workflows wird übrigens Association Form genannt.

Workflow starten

Gemäß den zuvor besprochenen Einstellungen kann ein Workflow entweder automatisch beim Erstellen und/oder beim Ändern eines Elements oder aber manuell durch den Benutzer gestartet werden. Das manuelle Starten des Workflows wird im Kontextmenü des Elements durchgeführt, für das der Workflow ausgeführt werden soll. Es erscheint ein Dialog, der die aktiven Workflows auflistet – durch Mausklick starten Sie den gewünschten (Abbildung 18.139).

Abbildung 18.139 Das manuelle Starten eines Workflows geschieht im Kontextmenü des Elements.

Drei-Status-Workflow mit einer Dokumentbibliothek

Sie haben weiter vorn bereits das Association Form des Drei-Status-Workflows gesehen – hier folgt nun in kurzer Form der Ablauf dieses Typs.

Der Drei-Status-Workflow basiert darauf, dass sich in den Eigeschaften eines Listeneintrags etwas ändert. Dieser Workflowtyp ist also eigentlich dafür prädestiniert, beispielsweise in Zusammenhang mit einer Aufgabenliste eingesetzt zu werden und zu überwachen, wie die Erledigung der Aufgabe vorangeht.

Ich zeige Ihnen aber ganz bewusst, dass dieser Workflowtyp auch durchaus mit einer Dokumentbibliothek angewendet werden kann. Der Drei-Status-Workflow ist, beispielsweise im Gegensatz zum Genehmigungsworkflow, in den Windows SharePoint Services und nicht nur im kostenpflichtigen SharePoint Server vorhanden. Falls Sie viele Dokumentworkflows haben, müssen Sie entscheiden, ob Sie mit dem Drei-Status-Workflow zurechtkommen oder ob Sie doch lieber zum SharePoint Server greifen und die für solcherlei Zwecke komfortablen Workflows verwenden möchten, die der SharePointServer bietet.

Wie weiter vorn gezeigt wurde, ist es aber notwendig, dass in den Metadaten (bzw. Listeneigenschaften) eine Spalte vom Typ Auswahl vorhanden ist.

Nach der Erstellung eines Dokuments können die Metadaten bzw. Listeneigenschaften beispielsweise so aussehen, wie in Abbildung 18.140 gezeigt.

Abbildung 18.140 Anfangs ist in den Dokumenteigenschaften der Status »Erstellt« vermerkt. Bei diesem Feld handelt es sich um eine selbst erstellte Spalte vom Typ »Auswahl«.

Wenn Sie den Workflow starten, ist dieser aktiv, ohne dass ein Initiation Form erscheint, wie es beispielsweise beim Genehmigungsworkflow des SharePoint Servers gezeigt wird. Der »Besitzer« des Workflows erhält eine etwas spartanische Meldung, die darauf hinweist, dass der Workflow initiiert ist (Abbildung 18.141). Erstellte Aufgaben finden sich wie gewohnt in der Aufgabenliste; Benutzer, denen Aufgaben zugeordnet werden, erhalten entsprechende E–Mails.

Beim Drei-Status-Workflow wird beim Durchlaufen der verschiedenen Schritte des Workflows eine Eigenschaft des Listenelements bzw. Dokuments geändert. Sie sehen das beispielsweise in Abbildung 18.142, wo der Status des Dokuments auf In Prüfung geändert ist.

Abbildung 18.141 Eine etwas spartanische Kontrollmitteilung informiert darüber, dass der Workflow initiiert worden ist.

Abbildung 18.142 Der Status des Dokuments wird direkt in den Eigenschaften des Listenelements modifiziert.

Der Workflow ist aktiv, bis der Status erreicht ist, der im Association Form als Endzustand festgelegte Werterreicht ist. Technisch bedeutet das, dass bei einer Änderung des Listeneintrags der Workflow aktiv wird und prüft, ob sich der Status verändert hat. Dies kann man einfach nachvollziehen, indem man den Workflowverlauf anschaut (Abbildung 18.143):

  • Sie erkennen, dass Workflowaufgaben erstellt worden sind.
  • Diese werden dadurch abgeschlossen, dass der Status des Listenelements wechselt.
  • Die jeweils neu erreichten Status werden im Workflowverlauf dokumentiert.

Wenn in einer Office 2007-Applikation ein Dokument geöffnet ist, zu dem für den aktuellen Benutzer eine Workflowaufgabe vorliegt, wird dies in der Anwendung angezeigt. Dies gilt natürlich auch, wenn die Workflowaufgabe aus einem Drei-Status-Workflow stammt. In diesem Fall wird allerdings beim Klick auf die Schaltfläche zum Bearbeiten das Webinterface gestartet. Eine in die Office-Applikation integrierte Bearbeitung (ohne Browser) wie beispielsweise beim Genehmigungsworkflow ist beim Drei-Status-Workflow nicht möglich.

Abbildung 18.143 Die Dialogseite »Workflowstatus« für einen Drei-Status-Workflow

Drei-Status-Workflow mit einer Liste vom Typ »Projektaufgaben«

In diesem Abschnitt möchte ich Ihnen gern einen wirklich »klassischen« Drei-Status-Workflow vorführen. In diesem Fall wird der Workflow für eine Liste vom Typ Projektaufgaben durchgeführt. Mit dem Workflow lässt sich überwachen, in welchem Status sich das Element (in diesem Fall die Aufgabe) momentan befindet. Die Personen, denen eine Aufgabe zugewiesen wird, erhalten eine Mail, die sie darüber informiert.

Abbildung 18.144 zeigt das Association Form des Drei-Status-Workflows. Auf zwei Aspekte möchte ich Sie gezielt hinweisen:

  • Als Auswahlwert für den Workflowstatus wird die Spalte Aufgabenstatus gewählt. Diese ist in der Listenvorlage Projektaufgaben standardmäßig vorhanden, hat dort allerdings fünf vordefinierte Werte. Drei davon (in diesem Fall: Nicht begonnen, In Bearbeitung und Abgeschlossen) können Sie dem Workflow zuweisen, die anderen beiden werden schlicht und ergreifend nicht berücksichtigt.
  • In den übrigen Abschnitten des Association Forms wird ebenfalls auf die in der Liste standardmäßig vorhandenen Spalten zugegriffen. Die Zuweisung von Aufgaben (und damit auch die Benachrichtigung per Mail) erfolgt an denjenigen, der in der Spalte Zugewiesen an der Liste eingetragen ist.

Abbildung 18.144 Das Association Form des Drei-Status-Workflows für die Verwendung mit einer Liste vom Typ »Projektaufgaben«

Damit Sie das hier gezeigte Beispiel einfacher nachvollziehen können, zeige ich Ihnen in Abbildung 18.145, wie Sie eine neue Projektaufgabe in der Liste anlegen. Zunächst befindet sich die Aufgabe im Status Nicht begonnen. Die Textbox Zugewiesen an muss unbedingt ausgefüllt werden; der hier eingetragene Benutzer wird auch darüber informiert, dass ihm eine Aufgabe zugewiesen worden ist.

Abbildung 18.145 Die Projektaufgabe

Ist die Projektaufgabe angelegt und der Workflow gestartet (was bei entsprechender Konfiguration automatisch geschehen kann), wird die Aufgabe als In Bearbeitung angezeigt (Abbildung 18.146, unterer Bereich). Ab jetzt »wandert« das Listenelement durch die drei Status des Drei-Status-Workflows. Es lässt sich so wunderbar nachverfolgen, welche Aufgaben bereits erledigt worden sind. Da der Workflowverlauf nebst ausführender Personen und genauer Zeiten protokolliert wird, werden Vorgänge nachvollziehbar.

Wenn ein Benutzer einen Arbeitsschritt ausgeführt hat, trägt er dies beim Listenelement ein. In Abbildung 18.147 ist zu sehen, wie der Status vom initialen Status Nicht begonnen auf In Bearbeitung gesetzt wird. Obwohl in der Dropdown-Liste fünf mögliche Zustände angezeigt werden (ich habe hier lediglich die unveränderte Listenvorlage verwendet), sind nur drei davon im Workflow verwendbar – schließlich ist es ein Drei-Status-Workflow. Sie sollten also die aus Vorlagen erzeugten Listen entsprechend überarbeiten, damit die Benutzer nicht ins Grübeln kommen.

Hat ein Benutzer den Aufgabenstatus geändert, wird dies direkt an den Workflow gemeldet. Sie können dies daran erkennen, dass dieses Ereignis direkt im Workflowverlauf eingetragen wird.

Abbildung 18.146 Für das Listenelement der Projektaufgabenliste wird ein Workflow ausgeführt; momentaner Status: »In Bearbeitung«.

Beachten Sie, dass in der »tabellarischen« Anzeige des Listenelements der Workflowstatus mit In Bearbeitung angegeben ist. Das heißt, dass der Workflow läuft, es lässt aber keine Rückschlüsse auf den Aufgabenstatus zu, der übrigens in der Tabellenansicht separat angegeben ist.

Abbildung 18.147 Die Änderung des »Aufgabenstatus« wird vom Workflow verarbeitet.

In Abbildung 18.148 ist die Dialogseite Workflowstatus eines abgeschlossenen Workflows zu sehen. Interessant ist insbesondere der Abschnitt Workflowverlauf, in dem Sie sehr detailliert nachvollziehen können, wer was wann geändert hat.

Abbildung 18.148 Der Workflowverlauf eines abgeschlossenen Drei-Status-Workflows eines Listenelements


Galileo Computing - Zum Seitenanfang

18.11.4 SharePoint Designer-Workflows Zur nächsten ÜberschriftZur vorigen Überschrift

Wenn Sie sich mit dem standardmäßigen Drei-Status-Workflow beschäftigt haben, den ich Ihnen auf den vorherigen Seiten vorgestellt habe, dann werden Sie – vermutlich – zwei Gedanken haben:

  • Die Möglichkeiten in puncto Workflow sind bei SharePoint sehr spannend.
  • Die eine vorhandene Workflowvorlage (im SharePoint Server sind es übrigens ein paar Vorlagen mehr) reicht nicht, um alle Bedürfnisse Ihres Unternehmens abzudecken.

Fazit ist, dass es Zeit wird, eigene Workflows zu erstellen. Wie Sie zu Beginn dieses Kapitels bereits gehört haben, gibt es die SharePoint Designer-Workflows und die Visual Studio-Workflows. Die diversen technischen Unterschiede sind weiter vorn tabellarisch aufgeführt; der wesentliche Unterschied bei der Implementierung ist, dass SharePoint Designer-Workflows ohne Kenntnis einer Programmiersprache (C#, VB.NET) erstellt werden können.

In diesem Abschnitt werden Sie sehen, wie sich mithilfe des SharePoint Designers auf recht einfache Art individuelle Workflows implementieren lassen.

Der SharePoint Designer

SharePoint Designer 2007, das übrigens aus FrontPage hervorgegangen ist, wird verwendet, um komplexere Anpassungen an SharePoint vorzunehmen, als es mit der Weboberfläche möglich ist. Auch die Erstellung einer bestimmten Art von Workflows wird aus SharePoint Designer heraus vorgenommen: der SharePoint Designer-Workflows. SharePoint Designer hat mit den anderen Workflow-Arten, also den »Standardworkflows« und den mit Visual Studio erstellten Workflows, keine Berührungspunkte.


Share Point Designer ist kostenpflichtig

Bevor Missverständnisse entstehen, sei darauf hingewiesen, dass SharePoint Designer ein separates und auch separat kostenpflichtiges Produkt ist. Wer sich mit SharePoint ernsthaft beschäftigt, wird aber nicht um dieses Werkzeug herumkommen.


Wenn Sie die Arbeit mit SharePoint Designer beginnen, öffnen Sie zunächst eine SharePoint-Site, wozu Sie den Menüpunkt DateiWebsite öffnen wählen. In dem sich öffnenden Dialog (Abbildung 18.149) geben Sie die URL der entsprechenden SharePoint-Website an.

Abbildung 18.149 Der erste Schritt in SharePoint Designer ist das Öffnen einer SharePoint Website. Hierbei wird deren URL angegeben.

SharePoint Designer wird nun auf seiner linken Seite die Ordnerliste anzeigen; dies ist eine baumartige Ansicht der SharePoint-Website. Sie sehen dort unter anderem die Dokumentbibliotheken und Listen, die innerhalb dieser SharePoint-Website vorhanden sind.

Rufen Sie nun den Menüpunkt DateiNeu auf. Mir geht es hier zunächst noch nicht um das Starten der ersten Aktion, sondern um die Überprüfung, ob die Arbeitsumgebung in allen Beziehungen »startklar« ist. Wenn das aufklappende Menü die in Abbildung 18.150 gezeigten Menüpunkte enthält, ist alles in Ordnung. Wenn Sie allerdings die in Abbildung 18.151 gezeigte Situation vorfinden, gibt es Handlungsbedarf. SharePoint Designer ermittelt, mit welchen Berechtigungen der aktuell angemeldete Benutzer auf die angegebene SharePoint-Website zugreift. In Abbildung 18.150 war ich als Mitglied der Gruppe der Designer angemeldet und hatte alle notwendigen Rechte, so dass mir SharePoint Designer folgerichtig die entsprechenden Menüpunkte angeboten hat. In Abbildung 18.151 hatte ich lediglich Leserechte, weshalb mir SharePoint Designer gar nicht erst die Menüpunkte angeboten hat, deren Funktionalität ich auf dem SharePoint Server ohnehin nicht hätte ausführen dürfen.

Abbildung 18.150 Wenn das »Neu«-Menü so aussieht, ist alles in Ordnung; insbesondere hat der angemeldete Benutzer die notwendigen Rechte, um beispielsweise Workflows anzulegen.

Etwas mehr Hintergrundwissen zu den Teilnehmereinstellungen in SharePoint Designer ist an dieser Stelle erforderlich: Welche Menüpunkte SharePoint Designer den jeweiligen Anwendern tatsächlich zeigt, hängt selbstverständlich von den Berechtigungen des aktuell angemeldeten Benutzers für die jeweilige SharePoint-Website ab. Was SharePoint Designer dem Benutzer an Menüpunkten präsentiert, lässt sich allerdings verändern.

Wenn Sie eine SharePoint-Website mit SharePoint Designer öffnen, wird auf der rechten Seite der Anwendung der Aufgabenbereich Teilnehmer angezeigt (Abbildung 18.152). Sollten Sie den Aufgabenbereich nicht sehen, können Sie mit dem Menüpunkt AufgabenbereicheTeilnehmer die Anzeige aktivieren. Im Bereich Ihr Teilnehmerstatus des Aufgabenbereichs wird aufgeführt, mit welchen Möglichkeiten Sie SharePoint Designer nutzen. Im Fall der Abbildung ist dies ohne Einschränkungen.

Abbildung 18.151 Erscheint das »Neu«-Menü so, wie hier gezeigt, hat der angemeldete Benutzer in der geöffneten SharePoint-Website zu wenige Rechte.

Abbildung 18.152 Im Aufgabenbereich »Teilnehmereinstellungen« wird angezeigt, welche Möglichkeiten dem Benutzer derzeit zur Verfügung stehen.

Die Möglichkeiten, die SharePoint Designer anbietet, orientieren sich zwar an den SharePoint-Berechtigungen (genauer gesagt an der SharePoint-Gruppenzugehörigkeit), können aber von einem Benutzer ohne Einschränkungen konfiguriert werden – wie das geht, sehen Sie jetzt. Wählen Sie dazu im Aufgabenbereich die Option Teilnehmereinstellungen für diese Website ändern.

Es öffnet sich ein Dialog, in dem zunächst drei Teilnehmergruppen angelegt sind (Abbildung 18.153). Um zu verstehen, was sich hinter diesen Teilnehmergruppen verbirgt, sollten Sie die Eigenschaften der Gruppe Inhaltsautoren öffnen. (Klicken Sie auf Ändern.)

Abbildung 18.153 Der zentrale Dialog der SharePoint Designer-Teilnehmereinstellungen

Die erste Karteikarte des Eigenschaftendialogs ist in Abbildung 18.154 zu sehen. Sie können auf den ersten Blick zwei wesentliche Aspekte erkennen:

  • Die Verknüpfung zwischen der SharePoint Designer-Teilnehmergruppe und den SharePoint-Siteberechtigungsstufen wird im unteren Teil des Dialogs vorgenommen. Mit dieser Teilnehmergruppe ist die SharePoint-Siteberechtigungsstufe Teilnehmen verknüpft.
  • Im oberen Bereich des Dialogs ist die Checkbox Uneingeschränkte Verwendung von SharePoint Designer zulassen nicht selektiert.

Abbildung 18.154 In diesem Dialog legen Sie unter anderem fest, wie die SharePoint Designer- Teilnehmergruppe mit SharePoint-Siteberechtigungsstufen verknüpft wird.

Da die hier gezeigte Gruppe als Standard festgelegt ist (siehe auch Abbildung 18.153), werden die Benutzer, die auf der geöffneten SharePoint-Website nicht eine der SharePoint-Siteberechtigungsstufen haben, die mit den Teilnehmergruppen Sitemanager und Webdesigners verknüpft sind, SharePoint Designer nicht uneingeschränkt verwenden können.

Erhält der Benutzer nicht die Möglichkeit, SharePoint Designer uneingeschränkt nutzen zu können (siehe die gleichnamige Checkbox), muss festgelegt werden, auf welche Features er Zugriff haben soll. Diese Konfiguration wird auf den übrigen Karteikarten des Dialogs erledigt, von denen ich Ihnen in Abbildung 18.155 diejenige mit der Bezeichnung SharePoint zeigen möchte: Sie sehen dort, dass der SharePoint Designer dem Benutzer zwar das Einfügen, Bearbeiten und Löschen von Webparts ermöglicht – mehr aber auch nicht. Daher findet sich in der Oberfläche auch nicht der Menüpunkt zum Erstellen eines neuen Workflows (vergleiche Abbildung 18.150 und Abbildung 18.151).

Abbildung 18.155 Hier können Sie die Optionen auswählen, die SharePoint Designer dem Benutzer anbietet.

Beachten Sie, dass die Teilnehmereinstellungen in SharePoint Designer kein Sicherheitsfeature sind. Sie sollen vielmehr Benutzern das Leben insofern leichter machen, als dass sie nur die Optionen sehen, mit denen sie tatsächlich arbeiten sollen. Welche Aktion der Anwender in letzter Konsequenz ausführen kann, entscheidet SharePoint. Mit anderen Worten: Selbst wenn Sie in SharePoint Designer das Erstellen eines Workflows auch für die SharePoint-Siteberechtigungsstufe Teilnehmer freischalten würden, hätten die Mitglieder dieser Gruppe nicht die Möglichkeit, den Vorgang zu Ende zu führen.

Den ersten SharePoint Designer-Workflow erstellen

Das Erstellen eines SharePoint Designer-Workflows beginnt mit dem Aufruf von DateiNeuWorkflow. Obgleich ein SharePoint Designer-Workflow stets einer bestimmten Liste bzw. Dokumentbibliothek zugeordnet ist, braucht diese beim Aufruf des Menüpunkts nicht ausgewählt zu sein – dies legen Sie im nun startenden Assistenten fest.

In der ersten Dialogseite des Assistenten zum Erstellen des Workflows legen Sie fest, wie der Workflow heißen soll und welcher Liste bzw. Dokumentbibliothek er zugeordnet werden soll, und bestimmen die Startoptionen (Abbildung 18.156).

Abbildung 18.156 Auf der ersten Dialogseite beim Erstellen eines neuen SharePoint Designer-Workflows werden einige grundlegenden Aspekte abgefragt.

Bei genauerer Betrachtung werden Sie feststellen, dass diese Angaben bei der Verwendung der »eingebauten« Standardworkflows oder von Visual Studio Workflows abgefragt werden, wenn Sie einen Workflow aus einer Workflowvorlage erstellen. Da es bei der Arbeit mit SharePoint Designer-Workflows keine Workflowvorlagen gibt, erstellen Sie hier in der Tat direkt den »arbeitenden« Workflow.

Nach diesen »Basiseinstellungen« wird nun der eigentliche Workflow erstellt. Dieser besteht aus beliebig vielen Schritten (mindestens einem!), in denen Aktionen ausgeführt werden. Die Ausführung dieser Aktionen kann an Bedingungen geknüpft werden.

Bedingungen und Aktionen

In Abbildung 18.157 sehen Sie den Dialog zur Definition des ersten Workflowschritts. In einem Workflowschritt wird eine Aktion ausgeführt. Bei Bedarf kann diese Ausführung an eine oder mehrere Bedingungen geknüpft werden. Definieren wir zunächst eine Bedingung.

Wenn Sie auf die Schaltfläche Bedingungen klicken, klappt eine Liste mit mehreren Bedingungen auf. Die größte Flexibilität haben Sie, wenn Sie sich für Jede Datenquelle vergleichen entscheiden. Man kann es allerdings auch negativ formulieren, denn bei dieser Option müssen Sie alles selbst konfigurieren.

Wenn Sie das Erstellen einer Bedingung ausgewählt haben, wird rechts neben dem Schalter ein Statement eingeblendet, das beim Bedingungstyp Jede Datenquelle vergleichen wie folgt lautet: Wenn Wert gleich Wert. Ihre Aufgabe ist es nun, die Platzhalter »Wert«, »gleich« und »Wert« mit Leben zu erfüllen.

Wenn Sie auf »das erste Wert« klicken, erscheint eine Textbox, neben dereine Schaltfläche mit dem Funktionssymbol (fx) steht. Da es immer eine gute Idee ist, sich das Leben möglichst einfach zu machen, sollten Sie auf das Funktionssymbol klicken, um den richtigen Ausdruck zu generieren.

Abbildung 18.157 Eine Bedingung definieren

Abbildung 18.158 In diesem Dialog können Sie auswählen, woher die Daten für die Überprüfung der Bedingung geholt werden sollen.

Der nun erscheinende Dialog besteht aus zwei Combobox-Steuerelementen (Abbildung 18.158):

  • Zunächst wählen Sie die Quelle aus. Wenn Sie auf Werte des Listenelements zugreifen möchten, für das der Workflow ausgeführt wird, ist Aktuelles Element die richtige Auswahl. Sie können bei Bedarf aber auch auf andere Listen innerhalb der SharePoint-Website oder auf Workflowdaten (die werden später erklärt) zurückgreifen.
  • Die zweite Combobox, bezeichnet mit Feld, dient dazu, aus der Quelle das benötigte Feld zu selektieren – das ging ja eigentlich bereits aus den Namen hervor.

Um festzulegen, wie die beiden Werte verglichen werden sollen, wird eine Liste eingeblendet, in der Sie aus ungefähr einem Dutzend Operatoren auswählen können (Abbildung 18.159). Welche Vergleichsoperatoren in dieser Liste vorhanden sind, hängt übrigens vom Datentyp des ersten Werts ab. In Fall der Abbildung (der erste Wert ist eine Person) werden Operatoren wie gleich, beginnt mit, endet mit, enthält etc. angeboten – letztendlich also String-Operatoren. Falls der erste Wert beispielsweise ein Datum oder eine Zahl ist, werden Operatoren wie ist größer als, ist kleiner als oder gleich etc. angeboten.

Abbildung 18.159 Welche Vergleichsoperatoren angeboten werden, hängt von dem Datentyp des ersten Werts ab.

Nun müssen Sie noch den zweiten Wert, also den Vergleichswert angeben. Auch hier passt SharePoint Designer die angebotenen Optionen dem ersten Wert an. In unserem Beispiel wird im ersten Wert eine Person gesucht. Dementsprechend wird bei der Eingabe des Vergleichswerts (klicken Sie einmal auf das rechte Wert) ein Dialog mit diversen Personen oder Gruppen angeboten. Teilweise werden »Platzhalter« wie Besitzer von Homepage ausgewählt; andere Varianten sind Active Directory-Gruppen, Benutzer aus dem Adressbuch oder SharePoint-Gruppen.

Sofern der erste Wert nicht ein Personenfeld ist, werden andere Eingabemöglichkeiten für den Vergleichswert zur Verfügung gestellt. Dies kann beispielsweise ein Freitext-Eingabefeld oder eine Optionsliste sein. SharePoint Designer macht es Ihnen recht einfach, Bedingungen zu formulieren (Abbildung 15.43).

Wenn Sie mögen, können Sie mehrere Bedingungen formulieren, die dann per UND verknüpft sind. Um eine weitere Bedingung für das Ausführen der Aktion hinzuzufügen, klicken Sie einfach auf die Schaltfläche Bedingungen und wählen den Bedingungstyp aus. Die Bedingungen können mithilfe eines Kontextmenüs gelöscht oder in der Reihenfolge geändert werden. Das Kontextmenü wird angezeigt, wenn Sie mit der Maus über die Bedingung fahren.

Abbildung 18.160 Auswahl einer Person oder Personengruppe als Vergleichswert

Ist die Bedingung bzw. sind die Bedingungen erfüllt, wird eine Aktion ausgeführt. Das Hinzufügen einer Aktion geschieht, wie in Abbildung 18.161 zu sehen ist, durch einen Klick auf die Schaltfläche Aktionen. In dem herunterklappenden Menü werden die meistverwendeten Aktionen angezeigt; der Eintrag Weitere Aktionen führt zu einer Auswahlliste, in der ungefähr zwei Dutzend Aktionen vorhanden sind.

Abbildung 18.161 Die Auswahl der durchzuführenden Aktionen

Wenn Sie eine Aktion hinzugefügt haben, muss diese konfiguriert werden. Genauso wie bei den Bedingungen wird eine Zeile erstellt, in der es einige auszufüllende Werte gibt; alternativ sind Links vorhanden, die zu weiteren Konfigurationsdialogen führen. Abbildung 18.162 zeigt den Konfigurationsdialog der Aktion E-Mail senden:

Abbildung 18.162 Konfiguration der Aktion »E-Mail senden«

  • Empfänger und CC-Empfänger können entweder statisch festgelegt werden oder es werden wie auf der Abbildung Platzhalter verwendet. Der Auswahldialog entspricht dem in 1Abbildung 18.160 gezeigten.
  • Im Betreff können ebenfalls statische Einträge und Platzhalter gemischt werden; dasselbe gilt für den Textkörper.

Die Konfiguration der übrigen Aktionen erfolgt analog – alles ist mit der Maus zu konfigurieren.

Zu dem Thema Aktionen sind noch folgende Anmerkungen zu machen:

  • Zu einer Bedingung können beliebig viele Aktionen definiert werden.
  • Die Aktionen können parallel oder sequenziell ausgeführt werden. Das Kontextmenü eines Bedingung/Aktionen-Abschnitts (das Sie über einen kleinen Pfeil am rechten oberen Rand des Abschnitts einblenden) bietet diese Einstellmöglichkeit.
  • Eigene Aktionen können Sie bei Bedarf mit Visual Studio erzeugen. Wie das gemacht wird, können Sie in Abschnitt 15.8 nachlesen.
  • Wenn eine Aktion auf jeden Fall ausgeführt werden soll, brauchen Sie keine Bedingung anzugeben.

Kommen wir noch einmal zum Thema Bedingungen zurück: In der realen Welt ist das Leben schon etwas komplizierter als in dem bisherigen Beispiel. Ein einfaches »Wenn dann« genügt im Allgemeinen nicht, sondern es müssen mehrere Verzweigungen (d. h. unterschiedliche Möglichkeiten) angeboten werden.

Um eine weitere Verzweigung hinzuzufügen, können Sie entweder wie in Abbildung 18.163 gezeigt auf das Kontextmenü zurückgreifen oder Sie klicken auf den Link Andernfalls wenn‘-Bedingungsverzweigung hinzufügen.

Abbildung 18.163 Das Hinzufügen einer Verzweigung

Hier einige Fakten zum Thema Verzweigungen:

  • Die hinzugefügte Verzweigung enthält wiederum eine oder mehrere Aktionen, die bei Bedarf von dem Erfüllen einer oder mehrerer Bedingungen abhängig sind.
  • Ein Workflowschritt kann beliebig viele Verzweigungen enthalten.
  • Sie können die Ausführungsreihenfolge der Verzweigungen verändern, indem Sie diese nach oben oder unten schieben (siehe auch das Kontextmenü in Abbildung 18.163).

Abbildung 18.164 zeigt einen Workflowschritt mit drei Verzweigungen. Der Workflowschritt wird von oben nach unten abgearbeitet.

Abbildung 18.164 Dieser Workflowschritt enthält drei Verzweigungen.

Wenn der Workflow fertig »zusammengeklickt« ist, klicken Sie einfach auf die Schaltfläche Fertig stellen – das war’s!

Grundsätzlich ist es aber eine ziemlich gute Idee, zunächst Workflow überprüfen zu wählen. Die erfreuliche Meldung, die Sie in Abbildung 18.165 sehen, garantiert zwar nicht, dass der Workflow auch inhaltlich genau das tut, was Sie wollen; zumindest können Sie sich aber sicher sein, dass keine groben Konfigurationsfehler bzw. Eingabefehler vorliegen.

Abbildung 18.165 Das Überprüfen des Workflows sollte zu diesem Resultat führen.

Der Workflow wird in der SharePoint-Website gespeichert. Die Ansicht der Ordnerliste zeigt, dass unser neuer Workflow unterhalb des Knotens Workflows gespeichert wird. Der Workflow besteht »physikalisch« aus drei XML-Dateien und einer ASPX-Datei (Abbildung 18.166). Wenn Sie wirklich ausführlich hinter die Kulissen schauen möchten, können Sie sich diese Dateien im Editor anschauen – ich denke aber, dass niemand auf die verwegene Idee kommen wird, SharePoint Designer-Workflows ohne SharePoint Designer erstellen zu wollen.

Abbildung 18.166 Der SharePoint Designer-Workflow wird in der SharePoint-Website gespeichert.

Dieser Speicherort für Workflows ist übrigens den SharePoint Designer-Workflows vorbehalten. Die mitgelieferten Standard-Workflows und auch Visual Studio-Workflows benutzen diese Speichermöglichkeit nicht.

Der Workflow kann nun direkt getestet werden. Falls Sie nicht das automatische Starten des Workflows konfiguriert haben, können Sie im Kontextmenü des Listenelements das Starten des Workflows aufrufen. Unser SharePoint Designer-Workflow erscheint »ganz normal« bei den aus Standard-Workflowvorlagen erzeugten Workflows.

Wenn der Workflow manuell gestartet wird, erscheint zunächst ein Initiation Form (Abbildung 18.167). Bei einem automatischen Start erscheint es nicht; stattdessen werden Standardwerte eingesetzt. Zur Anzeige des Formular wird übrigens die ASPX-Datei verwendet, die beim Workflow gespeichert ist (siehe Abbildung 18.166).

Da in diesem ersten SharePoint Designer-Workflow-Beispiel keine weiteren Daten erfragt werden müssen, hat das Formular lediglich eine Starten- und eine Abbrechen-Schaltfläche (Abbildung 18.167).

Abbildung 18.167 Wenn der Workflow manuell gestartet wird, erscheint ein Initiation Form.

Der Workflow wird nun starten, die in den drei Verzweigungen vorhandenen Bedingungen prüfen und gegebenenfalls die definierten Aktionen, in diesem Fall das Versenden von E–Mails, ausführen. Danach endet der Workflow. Dies wird in der Ansicht des Listenelements angezeigt werden – zumindest wenn diese dementsprechend konfiguriert ist.

Ändern und (das leider nicht vorhandene) Debuggen

Vermutlich werden Sie einen bestehenden Workflow irgendwann ändern oder zumindest ansehen wollen. Suchen Sie hierzu in der Ordnerliste der SharePoint-Website den Eintrag des Workflows. Im Kontextmenü der .xoml-Datei (das ist übrigens die einzige Datei, die mit dem Workflow-Symbol gezeigt wird) befindet sich der Menüpunkt Öffnen mitSharePoint Designer (als Workflow öffnen). Sie erhalten dann dieselbe Ansicht wie beim Erstellen des Workflows (Abbildung 18.168).

Wer von Ihnen mit Visual Studio programmiert, ist an komfortables Debugging gewöhnt. Im weiteren Verlauf dieses Kapitels werden Sie sehen, dass diese mächtigen Debugging-Möglichkeiten auch vor SharePoint-Workflows nicht Halt machen – solange es Visual Studio-Workflows sind. Die wirklich schlechte Nachricht an dieser Stelle ist, dass es für SharePoint Designer-Workflows keinerlei Debugging-Möglichkeiten gibt. Gut, Sie können Aktionen einfügen, die beim Erreichen bestimmter Betriebszustände ins Ereignisprotokoll schreiben und dergleichen mehr. Andere Debugging- und Monitoring-Möglichkeiten gibt es aber leider nicht.

Abbildung 18.168 Wenn ein bereits vorhandener Workflow bearbeitet werden soll, kann Sie ihn so aufrufen.

Obwohl man grundsätzlich mit SharePoint Designer auch komplexeste Workflows bauen kann, ist das fehlende Debugging meiner Ansicht nach eine »natürliche Grenze« für diese Komplexität.

Auf der anderen Seite muss man aber auch ganz klar sagen, dass die Möglichkeit, recht intuitiv Workflows in SharePoint Designer zu erstellen, die meisten anderen auf dem Markt vorhandenen Lösungen in den Schatten stellt. Die fehlenden Debugging-Möglichkeiten sollten Sie also nicht davon abhalten, sich mit SharePoint Designer-Workflows zu beschäftigen. Denken Sie aber an dieses Manko, bevor Sie ein wirklich komplexes Workflow-Projekt auf Basis von SharePoint Designer beginnen.

SharePoint Designer-Workflow mit Aufgaben

Sie haben bereits im Abschnitt über Standard-Workflows gesehen, dass Aufgaben eine wichtige Rolle bei SharePoint-Workflows spielen. Aus diesem Grunde beschäftigen wir uns in diesem Abschnitt mit dem Erstellen von SharePoint Designer-Workflows, in denen Benutzern Aufgaben zugewiesen werden.

Initiierung

Falls die Workflowaufgabe nicht derselben Person zugewiesen werden soll, sondern diese zur Laufzeit, also beim Start des Workflows, auswählbar sein muss, wird ein entsprechendes Initiation Form benötigt – das kennen Sie ja bereits von den zuvor besprochenen Standardworkflows.

Wenn Sie mit SharePoint Designer einen Workflow entwerfen, finden Sie am unteren Rand des Dialogs eine Schaltfläche Initiierung. Diese öffnet einen Dialog, in dem die beim Start des Workflows abzufragenden Parameter festgelegt werden können. Wie Sie in Abbildung 18.169 sehen können, müssen Sie lediglich einen Feldnamen vergeben und den Informationstyp festlegen.

Nach der Eingabe von Feldname und Informationstyp erscheint ein weiterer Dialog, der den Standardwert abfragt (Abbildung 18.170). Zu beachten ist, dass dieser Wert verwendet wird, wenn der Workflow automatisch gestartet wird. Andersherum gesagt, erscheint ein Initiation Form, das Parameter vom Benutzer erfragt, nur dann, wenn der Workflow manuell, also im Kontextmenü des Elements, gestartet wurde. Der hier konfigurierte Standardwert ist in dem Initiation Form, das beim manuellen Workflowstart gezeigt wird, bereits im entsprechenden Steuerelement eingetragen.

Abbildung 18.169 Sie können beliebig viele Initiierungsparameter definieren.

Abbildung 18.170 Wenn ein Workflow automatisch gestartet wird, wird das Feld mit dem hier eingetragenen Wert verwendet.

Aktionen hinzufügen

Wenn die Initiierung konfiguriert ist, werden dem Workflowschritt Aktionen hinzugefügt – dies kennen Sie ja bereits. In diesem Fall bietet sich die Aktion Aufgabe zuordnen an (Abbildung 18.171). Die Aktion erstellt für einen angegebenen Benutzer eine Aufgabe und hält den Workflow an, bis der Anwender die ihm zugewiesene Aufgabe erledigt hat.

Abbildung 18.171 Die Aktion »Aufgabe zuordnen« erstellt eine Aufgabe für einen Benutzer und wartet darauf, dass sie erledigt wird.

Die Konfiguration der Aktion Aufgabe zuordnen verläuft im Prinzip wie die Konfiguration einer beliebigen anderen Aufgabe: Es wird eine Textzeile angezeigt, in der einige Variablen mit Werten gefüllt werden müssen. Im Fall der hier besprochenen Aktion müssen Sie die Aufgabe spezifizieren und die Benutzer auswählen (Abbildung 18.172).

Sie konfigurieren die Aufgabe mithilfe eines Assistenten, den Sie durch einen Klick auf den Begriff eine Aufgabe starten (Abbildung 18.173 und Abbildung 18.174):

  • Zunächst zeigt der Assistent eine kurze Erläuterung der Funktion der Aktion (Abbildung 18.173): Der Workflow wird angehalten, bis jeder angegebene Benutzer die ihm zugewiesene Aufgabe erledigt hat. Die Aktion ist also sowohl flexibel (beliebig viele Benutzer) als auch »intelligent« – zumindest müssen Sie so gut wie nichts »von Hand dranprogrammieren«.
  • Die eigentliche Konfigurationsarbeit ist schnell erledigt, denn sie besteht letztendlich nur darin, einen Titel und eine Beschreibung einzugeben (Abbildung 18.174).

Abbildung 18.172 Die Konfiguration der Aktion »Aufgabe zuordnen«

Abbildung 18.173 Die Startseite des Assistenten zum Erstellen einer Aufgabe

Abbildung 18.174 Zur Definition einer Aufgabe müssen Sie lediglich einen Namen und eine Beschreibung eingeben.

Der zweite zu konfigurierende Parameter ist die Liste der Benutzer, an die die Aufgabe gesendet werden soll. In diesem Beispiel wird die Person, der die Workflowaufgabe zugewiesen ist, bei der Initiierung des Workflows abgefragt. Demnach muss der Workflow auch die Variable auslesen, in der diese Information abgelegt ist. In dem Dialog zur Benutzerauswahl, den Sie bereits zuvor gesehen haben, gehen Sie folgendermaßen vor (Abbildung 18.175):

  • Sie wählen den Eintrag Workflow-Nachschlagevorgang aus.
  • In dem sich nun öffnenden Dialog Workflow-Nachschlagevorgang definieren wählen Sie als Quelle den Eintrag Workflowdaten aus.
  • Im Listenfeld Feld sollte nun Initiierung:Genehmiger angezeigt werden.

Abbildung 18.175 Die Workflowaufgabe soll für den Benutzer erstellt werden, dessen Name bei der Initiierung des Workflows angegeben wurde. Das wird so konfiguriert, wie Sie hier sehen.

Testen

Der einfache Aufgabenworkflow mit SharePoint Designer ist damit fertig. Nun muss er noch überprüft und gespeichert werden (Schaltflächen Workflow überprüfen und Fertig stellen). Anschließend können Sie testen, ob er funktioniert. Das habe ich auch getan, und Sie sehen die Ergebnisse im Folgenden (Abbildung 18.176 und Abbildung 18.177):

  • Bei manuellem Start des Workflows wird bei der Initiierung abgefragt, wer der Genehmiger sein soll. Das Textfeld wird mit dem eingegebenen Standardwert vorbelegt (Abbildung 18.176).
  • Wenn der Benutzer, dem die Aufgabe zugewiesen worden ist, die Bearbeitung derselben auswählt, wird ein Formular angezeigt, in dem der Titel und die Beschreibung der Aufgabe angezeigt werden und in dem der Benutzer durch einen Mausklick die Aufgabe erledigen lassen kann (Abbildung 18.177).

Abbildung 18.176 Das Initiation Form unseres SharePoint Designer-Workflows

Abbildung 18.177 So sieht der Dialog aus, mit dem der Benutzer die »Aufgabe erledigen« kann.

Woher kommen die Formulare?

Der selbst erstellte Workflow funktioniert erfreulicherweise – und auch mit der Erstellung der Formulare hatten Sie nichts zu tun, denn sie waren »irgendwie einfach da«. Was zunächst sehr angenehm ist, könnte im real existierenden Arbeitsalltag ein wenig hinderlich sein, denn gegebenenfalls müssen die Formulare ein wenig angepasst und ergänzt werden, beispielsweise durch zusätzlichen Text.

Wenn Sie Abbildung 18.178 betrachten, können Sie leicht erkennen, wie die Aufgabe zu lösen ist:

  • In der Ordnerliste ist der soeben erstellte Workflow zu erkennen. Die beiden ASPX-Dateien sind das Initiation Form (SPDesigner Wf mit Aufgabe.aspx) und das Eingabeformular für den Benutzer (Wf-Aufgabe.aspx).
  • Wenn Sie eines dieser Formulare öffnen, können Sie es in SharePoint Designer bearbeiten. Die Abbildung zeigt ein geteiltes Fenster mit Entwurfs- und Codeansicht.

Zugegebenermaßen sind einige ASP.NET-Kenntnisse zum Modifizieren der Formulare notwendig – das sollte allerdings kein wirklich unlösbares Problem sein. Wenn Sie keine ASP.NET-Programmierkenntnisse haben (und solche auch nicht erwerben möchten), können Sie mit SharePoint Designer zumindest Text hinzufügen oder verändern.

Viele, viele Aktionen

Wie Sie in Abbildung 18.179 sehen können, stehen für SharePoint Designer-Workflows standardmäßig zwei Dutzend Aktionen zur Verfügung. Da sich Sinn und Funktion der jeweiligen Aktion meistens bereits aus der Bezeichnung erschließen und Sie spätestens beim testweisen Konfigurieren schnell herausfinden können, wozu sich die jeweilige Aktion eignet, verzichte ich an dieser Stelle darauf, jede einzelne individuell »durchzukauen«.

Abbildung 18.178 Modifikation der automatisch erstellten Formulare mit SharePoint Designer

Abbildung 18.179 Es gibt in SharePoint Designer standardmäßig zwei Dutzend Aktionen.

Was ist zu tun, wenn Sie eine Aktion benötigen, die es standardmäßig nicht in SharePoint Designer gibt? Sie werden beispielsweise feststellen, dass Sie mit den vorhandenen Aktionen keine Workflows entwerfen können, die auf externe Daten zugreifen. Je nach Aufgabenstellung, die Sie derzeit lösen möchten, könnte das aber notwendig sein.

An dieser Stelle habe ich eine gute Nachrichten für Sie: Sie können in Visual Studio eigene Aktionen entwerfen und innerhalb von SharePoint Designer-Workflows verwenden. Dann gilt auch für den Funktionsumfang und die Flexibilität Ihrer SharePoint Designer-Workflows: »The sky is the limit.«

Wenn Sie eigene Aktionen entwerfen (im Windows Workflow Foundation-Umfeld werden die Aktionen übrigens als Aktivitäten bezeichnet), müssen Sie allerdings mehr oder weniger fließend C# oder VB.NET sprechen!

Mit Variablen arbeiten

In vielen Anwendungsfällen wird es erforderlich sein, dass Sie Daten »aktionsübergreifend« verwenden. Einen solchen Anwendungsfall haben Sie weiter vorn bereits mit den Initiierungsdaten kennengelernt: In einem beim Start des Workflows gezeigten Formular wird dort der Name des Genehmigers abgefragt und gespeichert, um dann in der Aktion verwendet zu werden, die die Workflowaufgabe erstellt. Bei der Initiierung werden prinzipiell auch »nur« Variablen verwendet; allerdings mit der Besonderheit, dass deren Werte beim manuellen Start des Workflows vom Benutzer erfragt werden.

In der unteren Zeile des SharePoint Designer-Workflow-Assistenten finden Sie die Schaltfläche Variablen. Diese führt zu einem Dialog, mit dem Sie beliebig viele Variablen definieren können, die im Workflow verwendet werden sollen (Abbildung 18.180).

Abbildung 18.180 Sie können beliebig viele Variablen für einen Workflow definieren.

Das Verwenden der Variablen funktioniert so wie auch der Zugriff auf die Daten, die bei der Initiierung eines Workflows gesammelt werden. Sie definieren einen Workflow-Nachschlagevorgang, und in der Quelle Workflowdaten finden sich die angelegten Variablen (Abbildung 18.181).

Abbildung 18.181 Zugriff auf die Variablen erhalten Sie über die Quelle »Workflowdaten«.

Abschlussbemerkung zu SharePoint Designer-Workflows

Da dieses Buch eine allgemeine Einführung bieten soll, haben wir nicht im Detail jeden Aspekt jeder einzelnen Aktion besprechen können. Gleichwohl denke ich, dass Sie erkannt haben, wie einfach man sowohl individuelle als auch komplexe Workflows mit SharePoint Designer erstellen kann – ganz ohne Programmierkenntnisse. SharePoint Designer enthält zwar kein grafisches Design-Werkzeug, mit dem Sie per Drag & Drop Workflows bauen können, trotzdem ist die Arbeit recht übersichtlich.

Wenn bei sehr komplexen Aufgabenstellungen die Möglichkeiten von SharePoint Designer-Workflows nicht mehr ausreichen, sehen Sie in den folgenden Abschnitten, wie man mit Visual Studio SharePoint-Workflows erstellen kann – dann sind allerdings Programmierkenntnisse in C# oder VB.NET erforderlich.


Galileo Computing - Zum Seitenanfang

18.11.5 Visual Studio-Workflows topZur vorigen Überschrift

Wenn Ihre Aufgabenstellung zu individuell für einen Standardworkflow und zu komplex für einen SharePoint Designer-Workflow ist, bleibt noch der Griff zu einem Visual Studio-Workflow.

Visual Studio-Workflows bieten die »totale Flexibilität«, erfordern aber eine ziemlich intensive Auseinandersetzung mit der Materie – und sie sind ein beinhartes Entwicklerthema, also Programmierung. Dieses Buch ist erstens kein Entwicklerbuch, und zweitens sind Visual Studio-Workflows zu speziell für eine allgemeine Abhandlung zu Windows Server 2008, so dass es bei dieser Erwähnung bleibt. Sollten Sie Interesse an der Entwicklung von Visual Studio-Workflows haben, verweise ich gern auf mein bei Galileo Press erschienenes SharePoint-Buch.



Ihr Kommentar

Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.






<< zurück
  Zum Katalog
Zum Katalog: Windows Server 2008 R2

Windows Server 2008 R2
Jetzt bestellen


 Ihre Meinung?
Wie hat Ihnen das <openbook> gefallen?
Ihre Meinung

 Buchempfehlungen
Zum Katalog: Windows 7 für Administratoren






 Windows 7 für
 Administratoren


Zum Katalog: Konzepte und Lösungen für Microsoft-Netzwerke






 Konzepte und
 Lösungen für
 Microsoft-Netzwerke


Zum Katalog: Office SharePoint Server 2007 und Windows SharePoint Services 3.0






 Office SharePoint
 Server 2007 und
 Windows SharePoint
 Services 3.0


Zum Katalog: Exchange Server 2007 und Office Communications Server 2007






 Exchange Server 2007
 und Office
 Communications
 Server 2007


Zum Katalog: Citrix XenApp 5






 Citrix XenApp 5


Zum Katalog: PC-Netzwerke






 PC-Netzwerke


Zum Katalog: VMware vSphere 4






 VMware vSphere 4


Zum Katalog: VMware vSphere 4 - Videotraining






 VMware vSphere 4
 - Videotraining


Zum Katalog: VirtualBox






 VirtualBox


 Shopping
Versandkostenfrei bestellen in Deutschland und Österreich
InfoInfo




Copyright © Galileo Press 2010
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das <openbook> denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.


[Galileo Computing]

Galileo Press, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, info@galileo-press.de