Wir bieten Microsoft SharePoint und .NET Projekt- und Produkt-Know-how, Kompetenz und Erfahrung für Entwicklung, Architektur, Beratung, Schulung, Training und Kurse in Zürich, Bern, Basel, Schweiz sowie Deutschland und Östereich.
1stQuad Solutions - Ihr Partner für Microsoft SharePoint und .NET Beratung, Architektur, Entwicklung und Schulung.
info@1stquad.com - http:/www.1stquad.com
Druckansicht - Quelle: http://www.1stquad.com/sharepoint-kompetenz-erfahrung-know-how/blog/default/Marz-2010/Workflows-fur-SharePoint-entwickeln-Teil1.aspx

Blog > März 2010

Workflows für SharePoint entwickeln – Teil1

Workflow ist in den meisten SharePoint Installationen ein Thema. Eine kleine Serie zeigt, wie man hier für MOSS 2007 und SharePoint 2010, vor allem für Formular basierte Workflows, vorgehen kann.

Veröffentlicht am 08.03.2010 22:44:58 von Reiner Ganser mit 0 Kommentar(en)

Ich bin in letzter Zeit wieder vermehrt in Workflow Projekten involviert und möchte die Gelegenheit nutzen, eine kleine Blogserie zum Thema Workflows und SharePoint zu verfassen. Ich stelle in Workflow Projekten immer wieder fest, dass die Dinge zu umständlich, zu planlos oder schlichtweg falsch angegangen werden. In ein paar Blogeinträgen möchte ich einige Hinweise dazu geben und an einem Beispiel zeigen, wie man einen formularbasierten Workflow recht einfach in SharePoint umsetzen kann.
Ich werde dabei zuerst die Erstellung von Workflows für die aktuelle Plattform beschreiben (MOSS 2007), denn schließlich dauert es ja noch ein bisschen, bis SharePoint 2010 in der fertigen Version verfügbar ist. Danach werde ich zeigen, wie man den Workflow mit SharePoint 2010 umsetzt.
 

Die Vorbereitungen
 

Nichts ist einfacher als ein Workflow Projekt scheitern zu lassen, indem man es zu überhastet anfängt. Die Vorbereitungen sind deshalb gerade für ein Workflow Projekt enorm wichtig. Die nachfolgenden Ausführungen gelten dabei sowohl für die aktuelle Plattform (WSS 3.0/MOSS 2007), als auch für SharePoint 2010 (SharePoint Foundation 2010/SharePoint Server 2010).

Bevor man an die Umsetzung eines Workflows geht, sollte man zuerst die folgenden Punkte klären:
  1. Klare Definition des Prozesses: Es sollte klar sein, wie der Prozess genau aussieht. Es ist dabei sehr hilfreich, den Prozess grafisch aufzuzeichnen (z.B. mit Visio). Wichtig ist, dass alle am Prozess Beteiligten das gleiche Verständnis für den Prozess haben und diesen abnicken. Solange es unter den Beteiligten noch Diskussionen gibt, sollte man mit der Umsetzung des Workflows nicht anfangen. Alle Projekte, die ich miterlebt habe und die sich nicht an diese rudimentäre Regel gehalten haben, sind aus dem Aufwand gelaufen oder mussten sogar gestoppt werden, weil man an die Grenzen der gewählten Technologie/Umsetzung kam!!!
  2. Aus der Definition des Prozesses kann man ableiten, um welche Art von Workflow es sich handelt:
    • Serieller oder State Machine Workflow? Vor allem wenn es innerhalb des Prozesses sehr oft zu Rück- oder Quersprüngen kommt, sollte man zu einem State Machine Workflow greifen. Komischerweise zeigt Microsoft in seinen Demos hauptsächlich serielle Workflows, obwohl diese für Business Prozesse am wenigsten geeignet sind. Im Zweifel sollte man zu einem State Machine Workflow greifen. Dieser ist deutlich flexibler, wenn es um Erweiterungen und Änderungen geht. Wie man diesen umsetzen kann später mehr.
    • Ist es überhaupt notwendig, einen Workflow ablaufen zu lassen? Oft genügt es, alles in einem Formular umzusetzen (z.B. InfoPath) und mit Statusänderungen zu arbeiten. Damit lässt sich quasi auch eine beliebige Abfolge erzielen.
    • Handelt es sich um einen Formular- oder Dokument basierten Workflow? Wenn Dokumente erstellt werden, die man zur Genehmigung herumschickt, hat man zumeist ein einfaches Formular mit einem Link auf ein Dokument. So funktionieren auch die mitgelieferten Genehmigungs-Workflows in SharePoint. Oft benötigt man aber gar kein Dokument, sondern möchte alles innerhalb eines Formulars erledigen (Daten eingeben, weiterschicken, Genehmigen/Ablehnen, Daten erweitern usw.). Beispiele sind Anträge (z.B. Investitionsantrag, Reisantrag, Projektzeiten, Zeitabrechnung, Bewerberformular). In einem solchen Fall sollte man nicht versuchen, zwanghaft mit einem Dokument basierten Workflow zu arbeiten, nur weil man das in einer Demo von Microsoft gesehen hat. Auch die Umsetzung des Formulars mit Hilfe der Standarddialoge einer Liste ist meistens keine gute Idee, da die Benutzer meistens gut bedienbare Formulare benötigen, die entsprechende Hilfen beim Ausfüllen und bei Fehlern anbieten. Die Anpassung der Dialoge kann zwar anhand von CAML (Collaborative Application Markup Language) erfolgen. Diese Möglichkeit sollte man aber nicht mal seinem schlimmsten Feind zumuten, da es keinerlei Debug Unterstützung gibt und man deshalb im Fehlerfall sehr viel an Zeit und vor allem Nerven verbraten kann.
    • Wenn Sie Formular basierte Workflows erstellen wollen, dann verwenden Sie am Besten auch entsprechende Tools wie InfoPath oder ASP.NET.
  3. Handelt es sich bei der Definition um einen sehr komplexen Workflow, sollte man sich überlegen, ob man Drittprodukte (z.B. Nintex Workflow) verwendet, die auf die Erstellung von Workflows für SharePoint spezialisiert sind und zumeist eine deutliche höhere Produktivität als die Standardprodukte aus dem Hause Microsoft (SharePoint Designer oder Visual Studio.NET).
  4. Wie soll die Interaktion mit dem Benutzer erfolgen? Hier kann man sich die Frage stellen, ob man überhaupt eine Benutzerschnittstelle bauen muss, oder ob der Workflow im Hintergrund abläuft. Im einfachsten Fall kann man auch etwas genehmigen, indem man einen Status umsetzt, auf den dann ein Workflow reagiert und z.B. eine E-Mail versendet. Zugegebener Massen wird dies in den seltensten Fällen ausreichen und die Benutzer werden eine bessere Benutzerführung fordern. Bei minimalem Budget kann man sich diese Möglichkeit aber durchaus mal durch den Kopf gehen lassen.
  5. Werden Formulare benötigt, ist es extrem wichtig, diese gemeinsam mit den am Prozess beteiligten Benutzern zu erstellen. Hier leistet beispielsweise InfoPath sehr gute Dienste, da man das Formular schnell erstellen kann und die Benutzer sehen sehr früh, wie das Formular später aussehen wird. Im Idealfall kann man das erstellte Formular sogar im Workflow weiterverwenden. Man kann natürlich auch jedes andere Malprogramm verwenden oder auch einfach auf ein Flipchart malen. Wichtig ist nur, dass man das gut abstimmt. Im Idealfall setzt man sich mit der/den Person/Personen zusammen, die den Prozess genau kennen und wissen, welche Dinge im jeweiligen Prozessschritt getan werden müssen
  6. Anhand der Komplexität der Formulare muss man dann die Entscheidung treffen, wie die Formulare umgesetzt werden sollen:
    • Man kann InfoPath für die Erstellung der Formulare verwenden und diese dann im Browser anhand der sog. Forms Services von SharePoint nutzen. Die Forms Services sind jedoch nicht Bestandteil der WSS 3.0 bzw. SharePoint Foundation 2010. In der aktuellen Version von SharePoint (MOSS 2007) haben die Browser basierten Formulare gegenüber den Formularen, die das Client Programm InfoPath benötigen noch einige Einschränkungen. Wie das in SharePoint 2010 aussieht, später mehr. Handelt es sich um sehr komplexe Formulare ist allerdings mit InfoPath Vorsicht geboten. Einige Dinge lassen sich nur mit sehr großem Aufwand in InfoPath abbilden. Bevor man also die Entscheidung für InfoPath für die Umsetzung fällt, sollte man genau evaluieren, ob die Anforderungen umsetzbar sind. Viele der Problematiken lassen umgehen, indem man entsprechenden Webdienste im Hintergrund bereitstellt.
    • Bei komplexen Formularen, die z.B. spezielle Darstellungsformen (z.B. TreeView, dynamische Tabellen usw.) erfordern ist die Wahl von ASP.NET Formularen oftmals nicht die schlechteste. Gerade wenn man sehr erfahrene ASP.NET Programmierer im Unternehmen hat, ist diese Art der Formularerstellung oftmals genauso schnell oder sogar schneller als mit InfoPath. Bei der Wahl von ASP.NET kann man sich ziemlich sicher sein, dass man deutlich später ans Ende des Machbaren kommt, als mit InfoPath basierten Formularen. Zudem steht einem das gesamt .NET Framework zur Verfügung.
       
Damit endet der erste Teil dieser Serie. In den nächsten Teilen geht es mit der Umsetzung eines Beispiels weiter.

Kommentar
Dieser Blog-Eintrag wurde noch nicht kommentiert.
Kommentar hinterlassen



 Security code