SharePoint-Entwicklung

Entwicklung von Workflowprojektmappen für SharePoint Online

Chris Mayo

Viele Organisationen setzen SharePoint mittlerweile für die Zusammenarbeit ihrer Information Worker ein. In diesen Organisationen wird SharePoint häufig zum Speichern von Informationen in Listen und Dokumentbibliotheken verwendet, um einen manuellen Geschäftsprozess zu unterstützen. Das Speichern dieser Informationen in SharePoint sorgt bereits für eine erheblich effektivere Zusammenarbeit mit diesen Informationen. Die Produktivität der Information Worker kann jedoch noch beträchtlich gesteigert werden, indem diese Geschäftsprozesse in SharePoint in Form von SharePoint-Workflows automatisiert werden. 

Mit der Veröffentlichung von Office 365 können Organisationen mit SharePoint Online wie bei SharePoint viele Vorteile für die Zusammenarbeit und zusätzlich die Vorteile eines cloudbasierten Software-as-a-Service-Modells nutzen. SharePoint Online unterstützt Workflows mithilfe von deklarativen Workflows, die in SharePoint Designer 2010 integriert sind und über Sandbox-Lösungen bereitgestellt werden. Falls die integrierten Workflowaktionen die Anforderungen der Workflowprojektmappe nicht unterstützen, können Sie mithilfe von Visual Studio 2010 benutzerdefinierte Workflowaktionen erstellen und unter SharePoint Online über Sandbox-Lösungen bereitstellen.

In diesem Artikel gebe ich einen Überblick über die Workflowunterstützung in SharePoint Online, erstelle mit SharePoint Designer 2010 einen deklarativen Workflow, erweitere den Workflow mithilfe einer benutzerdefinierten Aktion und stelle ihn dann zur Ausführung in der Cloud als Sandbox-Lösung unter SharePoint Online bereit.

Informationen zu den Gemeinsamkeiten und Unterschieden der SharePoint Online-Entwicklung und der SharePoint 2010-Entwicklung finden Sie in meinem Artikel mit dem Titel "Cloudbasierte Zusammenarbeit mit SharePoint Online" in der März 2011-Ausgabe des MSDN-Magazins (bit.ly/spodevmsdn). Weitere Informationen zu SharePoint Online und Office 365, z. B. zur Anmeldung für ein Testkonto, finden Sie unter office365.com.  

SharePoint Online-Entwicklung – Überblick

In SharePoint Online können Sie mithilfe der gleichen Fähigkeiten und Tools Zusammenarbeitslösungen erstellen, die Sie bereits jetzt für die SharePoint 2010-Entwicklung verwenden, einschließlich Visual Studio 2010, SharePoint Designer 2010, C# oder Visual Basic und der SharePoint-APIs und -SDKs. Es gibt fraglos eine Reihe von Ähnlichkeiten zwischen der Entwicklung von Lösungen für SharePoint 2010 und SharePoint Online, aber auch Unterschiede, die sich darauf auswirken, welche Lösungen erstellt und wie diese Lösungen erstellt werden können.

SharePoint Online unterstützt nur Sandbox-Lösungen. Das bedeutet, dass Sie keine codebasierten Workflows bereitstellen können, z. B. mit sequenziellen Workflows und Statusmechanismusworkflows erstellte Lösungen. Mit SharePoint Designer 2010 erstellte Workflows werden jedoch unterstützt, weil diese Workflows nicht codebasiert, sondern deklarativ sind, und entweder direkt unter SharePoint Online oder unter Verwendung von Paketdateien über den Lösungskatalog bereitgestellt werden können. Außerdem können Sie diese deklarativen Workflows mithilfe von Sandbox-Lösungen erweitern, die mit Visual Studio 2010 erstellt wurden. Auf diese Weise können Sie benutzerdefinierte Workflowaktionen als Unterstützung für Szenarios bereitstellen, für die im Lieferumfang von SharePoint Designer 2010 keine Unterstützung vorhanden ist.

Dieser Artikel baut auf den Konzepten und Lösungen des vorherigen Artikels auf. Ich rate Ihnen, den Artikel zu lesen, die Anleitung zum Einrichten der SharePoint Online-Entwicklungsumgebung zu befolgen und die Beispiele der Purchasing-Lösung zu erstellen, damit Sie eingehend mit den Entwicklungskonzepten für SharePoint Online vertraut sind. Um die Workflowunterstützung von SharePoint Online zu veranschaulichen, wird die Purchasing-Lösung in diesem Artikel um eine Workflowprojektmappe erweitert.

SharePoint Designer 2010 – Überblick

Mithilfe von SharePoint Designer 2010 können Poweruser und Entwickler SharePoint 2010 ohne Verwendung von Code anpassen. Außerdem bietet SharePoint Designer 2010 Unterstützung für SharePoint Online. Die einzigen Abweichungen sind die Funktionsunterschiede zwischen SharePoint 2010 und SharePoint Online, z. B. die Unterstützung von BCS und externen Listen. SharePoint Designer 2010 ist ein hervorragendes Tool für die Navigation und die Verwaltung von Artefakten in SharePoint, zum Arbeiten mit Daten und zum Anpassen des Erscheinungsbilds von SharePoint-Sites. Außerdem können Sie damit benutzerdefinierte Workflows erstellen, die im Rahmen einer Gesamtlösung für die Zusammenarbeit bereitgestellt werden können. Weitere Informationen zu SharePoint Designer 2010-Funktionen erhalten Sie im Video "Einführung in SharePoint Designer 2010 für SharePoint Online" (bit.ly/spdspointro). SharePoint Designer 2010 ist als kostenloser Download verfügbar und unterstützt sowohl 32-Bit-Versionen (bit.ly/spd201032) als auch 64-Bit-Versionen (bit.ly/spd201064).

Purchasing-Lösung

In den Beispielen dieses Artikels erweitere ich den Purchasing-Prozess der fiktiven Contoso Corp., der im vorherigen Artikel vorgestellt wurde, indem ich einen SharePoint-Workflow zum Automatisieren der Genehmigung von Bestellanforderungen hinzufüge. Wenn eine Bestellanforderung genehmigt werden muss, startet der Benutzer den Workflow und gibt eine geschäftliche Begründung für die Bestellung an. Der Workflow initiiert einen Genehmigungsprozess und erstellt eine Aufgabe mit den Details der Bestellung für die Gruppe der genehmigenden Personen. Nach der Genehmigung bzw. der Ablehnung wird der Benutzer, der die Anforderung eingereicht hat, per E-Mail über die Entscheidung zur Anforderung informiert. Anschließend untersucht der Workflow den Typ der Anforderung, und im Falle eines genehmigten Reiseantrags (z. B. der Besuch einer technischen Konferenz) erstellt der Workflow eine untergeordnete Site, auf der der Benutzer einen Reisebericht ausfüllen und Folien hochladen kann. Zu diesem Zweck werde ich der Liste "Non-Standard Business Purchase Requests" ein "RequestType"-Feld für den Anforderungstyp hinzufügen. 

Ich habe das "RequestType"-Feld dem Projekt "PurchaseMgr" aus dem letzten Artikel bereits hinzugefügt. Falls Sie den Artikel gelesen haben, können Sie das vorherige Paket entfernen und das für diesen Artikel angegebene Paket bereitstellen oder der Liste "Non-Standard Purchase Requests" das erforderliche "RequestType"-Feld mit den Auswahlmöglichkeiten "Travel", "Equipment" und "Service Request" hinzufügen. Ich beginne mit dem Code aus diesem Artikel (bit.ly/spoworkmsdncode) und extrahiere ihn in das Verzeichnis "Documents\Visual Studio 2010\Projects\SPOMSDN_Workflow" auf meinem lokalen Computer. Anschließend stelle ich die Datei "PurchasingMgr.wsp" im Lösungskatalog der Sitesammlung in meiner lokalen SharePoint 2010-Entwicklungsumgebung bereit (bei mir ist dies "http://o365dpe.contoso.com/sites/spomsdnmag") und aktiviere die Funktion "Purchasing Manager - Content Types and Lists" auf meiner Purchasing-Website (http://o365dpe.contoso.com/sites/spomsdnmag/purchasing). 

Erstellen des Workflows

Zu Beginn der Workflowentwicklung öffne ich die Purchasing-Site auf meiner lokalen Website der SharePoint 2010-Entwicklungsumgebung, indem ich SharePoint Designer 2010 öffne, die Option "Datei | Sites | Website öffnen" wähle und die URL meiner Site eingebe (http://o365dpe.contoso.com/sites/spomsdnmag/purchasing). Im Navigationsbereich wähle ich "Workflows" aus, um den derzeit veröffentlichten Workflow und das Menüband "Workflows" anzuzeigen. Dies ist in Abbildung 1 dargestellt.

(Zum Vergrößern auf das Bild klicken)

Abbildung 1: Workflows in SharePoint Designer 2010

SharePoint Online unterstützt Listenworkflows für eine bestimmte Liste, Siteworkflows für bestimmte Sites sowie wieder verwendbare Workflows, die zu einem späteren Zeitpunkt an eine Liste oder einen bestimmten Inhaltstyp gebunden werden können. Da es möglich sein soll, den Workflow im Rahmen einer Gesamtlösung zu verteilen, erstelle ich einen wieder verwendbaren Workflow. Dies ist der einzige Workflowtyp, der die Verteilung unterstützt.

Beim Erstellen eines Workflows in SharePoint Designer habe ich verschiedene Möglichkeiten. Ich kann meinen Workflow basierend auf einem der integrierten Workflows erstellen (z. B. "Approval", "Collect Feedback" oder "Collection Signatures"), indem ich die Schaltfläche "Kopieren und ändern" verwende, ein Visio 2010-Diagramm basierend auf der Microsoft SharePoint-Workflowvorlage über die Schaltfläche "Aus Visio importieren" importiere oder den Workflow ganz neu erstelle. Für die Neuerstellung verwende ich im Menüband auf der Registerkarte "Workflows" die Gruppe "Neu". In der Gruppe "Neu" des Menübands klicke ich auf die Schaltfläche "Wieder verwendbarer Workflow". Im Dialogfeld "Wieder verwendbaren Workflow erstellen" gebe ich dem Workflow den Namen "Non-Standard Business Purchase Request Approval" und wähle "Purchasing Manager – Non-Standard Business Purchase Request Content Type" aus, damit der Workflow an meinen Inhaltstyp gebunden ist. Dies ist in Abbildung 2 dargestellt.

(Zum Vergrößern auf das Bild klicken)

Abbildung 2: An Inhaltstyp gebundener wieder verwendbarer Workflow

Als Nächstes greife ich auf die Seite mit den Einstellungen des Workflows "Non-Standard Business Purchase Request Approval" zu, indem ich auf der Registerkarte "Workflows" in der Gruppe "Verwalten" auf "Workfloweinstellungen" klicke.

In der Gruppe "Einstellungen" aktiviere ich das Kontrollkästchen "Workflowvisualisierung auf der Statusseite anzeigen", um meinen Benutzern die Echtzeitvisualisierung des Status der einzelnen Workflowinstanzen zu ermöglichen. Ich verwende die Gruppe "Startoptionen", um dies zu einem vom Menschen gesteuerten Workflow zu machen, indem ich das Kontrollkästchen "Option für manuellen Start deaktivieren" deaktiviere und das Kontrollkästchen "Option für automatischen Start bei Erstellung/Änderung von Elementen deaktivieren" aktiviere. Gehen Sie umgekehrt vor, um einen vom Computer gesteuerten Workflow zu erstellen.

In vielen Fällen sind die Informationen, die ich zum Fertigstellen des Workflows benötige, nicht in der Liste oder der Bibliothek gespeichert. Ich kann diese Informationen in workflowspezifischen Variablen und Spalten erfassen und speichern. Dies ist mithilfe der Gruppe "Variablen" im Menüband "Workflows" möglich, wie in Abbildung 3 beschrieben.

Abbildung 3: Workflowvariablen

In diesem Fall möchte ich die geschäftliche Begründung für die Bestellung erfassen, wenn der Workflow gestartet wird, um diese Informationen als Entscheidungshilfe bereitstellen zu können. Dazu klicke ich auf "Variablen | Initiierungsformularparameter | Hinzufügen…" und erstelle im Dialogfeld "Feld hinzufügen" den Parameter "Business Rationale". Anschließend klicke ich auf "Weiter" und "Fertig stellen".

Implementieren des Workflows in SharePoint Designer

Nun kann ich mit dem Implementieren des Workflows beginnen. Also klicke ich auf der Registerkarte "Workfloweinstellungen" in der Gruppe "Bearbeiten" auf die Workflowschaltfläche "Editor". Ich befinde mich jetzt im SharePoint Designer 2010-Workflowdesigner, in dem ich meinen Workflow mithilfe der Optionen "Bedingung", "Aktion" und "Schritt"implementieren kann, die im Menüband "Workflow" in der Gruppe "Einfügen" angeordnet sind (siehe Abbildung 4).

(Zum Vergrößern auf das Bild klicken)

Abbildung 4: Workflowdesigner – Gruppe "Einfügen"

Schritte werden zum Organisieren der Bedingungen und Aktionen in einem Workflow und zum Steuern der Ausführung dieser Bedingungen und Aktionen verwendet. Dies ist in Abbildung 5 beschrieben.

Abbildung 5: Schritttypen

 In der Darstellung in Abbildung 6 wird Schritt 2 z. B. mit den Berechtigungen des Workflowentwicklers ausgeführt, während Schritt 1 im Namen des Benutzers ausgeführt wird, der den Workflow gestartet hat (entweder manuell oder automatisch). Die Schritte 5 und 6 werden parallel ausgeführt, während die Schritte 3 und 4 nacheinander ausgeführt werden.

Abbildung 6: Schritte – Auswirkung auf die Workflowausführung

In meinem Workflow verwende ich nur einen Schritt. Um zu dokumentieren, welchen Zweck die Bedingungen und Aktionen in diesem Schritt haben, ändere ich den Titel. Dazu klicke ich auf "Schritt 1" und gebe "Request Purchase Approval" ein. Anschließend klicke ich in den Schritt, damit der Cursor sich an der richtigen Stelle zum Hinzufügen von Aktionen und Bedingungen befindet.

Aktionen funktionieren im Workflow und können z. B. das Starten eines Genehmigungsprozesses, das Ändern eines Listeneintrags, das Senden einer E-Mail und andere Dinge bewirken. Eine vollständige Liste der unterstützten Aktionen finden Sie in der Referenz zu SharePoint Designer 2010 (bit.ly/spd2010act). Für dieses Szenario möchte ich einen Genehmigungsprozess für die Bestellanforderung starten. Also wähle ich im Menüband unter "Einfügen" die Dropdownliste "Aktion" und dann die Option "Genehmigungsprozess starten" aus. Dem Designer wird ein Satz mit Hyperlinks hinzugefügt, sodass ich die Aktion abschließen kann, indem ich die einzelnen Links auswähle und mehr Informationen angebe. Dies ist in Abbildung 7 dargestellt.

Abbildung 7: Hinzufügen der Aktion "Genehmigungsprozess starten"

Wenn ich auf den Link "Genehmigung" klicke, kann ich die Genehmigungsaufgabe anpassen. Es ist z. B. auch möglich, die Verarbeitungsweise und die Ergebnisse der Aufgabe zu ändern. Per Klick auf die Schaltfläche "Zurück" kehre ich zum Editor zurück. Als Nächstes klicke ich auf den Link "diesen Benutzern" (in Abbildung 7: "these users"), um die Aufgabe anzupassen und anzugeben, wer am Genehmigungsprozess beteiligt sein soll. Im Dialogfeld "Aufgabenprozessteilnehmer auswählen" wähle ich als Teilnehmer die Gruppe "Genehmigende Personen" aus und lege den Titel der Aufgabe fest. Dies ist in Abbildung 8 dargestellt. Unter "Anweisungen" werden Details zum Eintrag und die geschäftliche Begründung als Entscheidungshilfe für die genehmigenden Personen angegeben. Um beispielsweise den Titel des Listenelements einzubeziehen, klicke ich auf die Schaltfläche "Nachschlagevorgang hinzufügen oder ändern" und wähle unter "Datenquelle" die Option "Aktuelles Element" und unter "Quellenfeld" die Option "Titel" aus.

Abbildung 8: Anpassen der Genehmigungsaufgabe

Die fertige Aufgabe sollte wie in Abbildung 9 aussehen.

Abbildung 9: Angepasste Genehmigungsaufgabe

An diesem Punkt wird die Workflowausführung angehalten, bis die Aufgabe genehmigt oder abgelehnt wurde oder, falls ein Fälligkeitsdatum angegeben wurde, abgelaufen ist. Zum Steuern des Flusses verwende ich "Bedingungen".

Mit Bedingungen wird die Logik des Workflows anhand der Werte in Workflowvariablen oder –feldern gesteuert. Falls das Element genehmigt wird, soll z. B. eine E-Mail an die anfordernde Person gesendet und beim Anforderungstyp "Reise" eine Site erstellt werden. Falls das Element abgelehnt wird, soll eine E-Mail gesendet und das Element gelöscht werden. Dazu positioniere ich den Cursor unterhalb des Genehmigungsprozesses, klicke auf die Dropdownliste "Bedingung" und wähle "Wenn ein beliebiger Wert gleich Wert ist". Ich klicke auf den Hyperlink "Wert" und dann auf die angezeigte Schaltfläche, um das Dialogfeld "Workflow-Nachschlagevorgang definieren" zu öffnen. Unter "Datenquelle" wähle ich die Option "Workflowvariablen und –parameter", und unter "Quellenfeld" wähle ich die Option "Variable: IsItemApproved". Diese Variable wird dem Workflow hinzugefügt, wenn die Aufgabe "Genehmigungsprozess starten" hinzugefügt wird.

Anschließend klicke ich auf den Link für "ist gleich" und wähle in der angezeigten Dropdownliste die Option für "ist gleich" aus. Dann klicke ich auf den Link "Wert" und wähle in der Dropdownliste die Option "Ja". Unterhalb dieser Bedingung ordne ich einen Else-If-Block an, damit Aktionen ausgeführt werden können, falls das Element abgelehnt wird. Ich füge jeder Verzweigung Aktionen zum Senden einer E-Mail hinzu und verwende den Zeichenfolgengenerator, um den E-Mail-Titel festzulegen. Dies ist in Abbildung 10 dargestellt.

Abbildung 10: Genehmigungs-E-Mail

Als Nächstes füge ich unter der If-Bedingung die Bedingung "Wenn das aktuelle Elementfeld gleich Wert ist" hinzu und verknüpfe sie mit dem "RequestType"-Feld, damit bei einem Reiseantrag eine neue untergeordnete Site erstellt werden kann. Der Designer sieht jetzt wie in Abbildung 11 dargestellt aus.

Abbildung 11: Bedingungsfluss des Workflows

Für die Erstellung der Site für Reiseanträge muss ich eine benutzerdefinierte Workflowaktion erstellen, weil diese Aktion nicht in SharePoint Designer 2010 integriert ist. Dazu speichere ich den Workflow, schließe SharePoint Designer 2010 und öffne dann Visual Studio 2010.

Erstellen einer benutzerdefinierten Workflowaktion in Visual Studio 2010

Sie können SharePoint Designer 2010 mithilfe von Visual Studio 2010 und Sandbox-Lösungen benutzerdefinierte Workflowaktionen hinzufügen. Mit diesen Aktionen können alle Aufgaben ausgeführt werden, die auch in einer Sandbox-Lösung möglich sind, was SharePoint Online-Workflows einen hohen Grad an Flexibilität verleiht.

In Visual Studio 2010 wähle ich "Datei | Neues Projekt" und im Dialogfeld "Neues Projekt" dann SharePoint 2010-Vorlagen und eine leere SharePoint-Vorlage. Als Name gebe ich "PurchasingMgrActions" und als Speicherort "Documents\Visual Studio 2010\Projects\SPOMSDN_Workflow\" an und klicke auf "OK". Im SharePoint Customization Wizard gebe ich meine lokale Entwicklungswebsite (http://o365dpe.contoso.com/sites/spomsdnmag/purchasing) als lokale Site ein, wähle die Option "Als Sandkastenlösung bereitstellen" aus und klicke auf "Fertig stellen".

Im Projektmappen-Explorer klicke ich mit der rechten Maustaste auf das Projekt "PurchasingMgrActions", wähle die Option "Hinzufügen | Klasse…", gebe der Klasse den Namen "CreateSiteAction" und klicke dann auf "OK". Die "CreateSiteAction"-Klasse stellt die Methode bereit, die der Workflow zum Erstellen der Site aufruft. Ich füge die erforderlichen Anweisungen hinzu und implementiere die "CreateSite"-Methode, wie in Abbildung 12 definiert.

Abbildung 12: Implementieren der "CreateSite"-Methode

using System;

using System.Collections;



using Microsoft.SharePoint;

using Microsoft.SharePoint.UserCode;



namespace SPDCustomWorkflowActions

{

  public class CreateSiteActivity

  {

    public Hashtable CreateSite(SPUserCodeWorkflowContext context, string siteName)

    {

      Hashtable results = new Hashtable();

      try

      {

        using (SPSite site = new SPSite(context.CurrentWebUrl))

        {

          using (SPWeb web = site.OpenWeb())

          {

            web.Webs.Add(

              siteName,

              "Trip Report: " + siteName,

              string.Empty,

              1033,

              "STS",

              false,

              false);

          }

        }

                

        results["success"] = true;

        results["exception"] = string.Empty;

      }

      catch (Exception e)

      {

        results = new Hashtable();

        results["exception"] = e.ToString();

        results["success"] = false;

      }



      return results;

    }

  }

}

Die "CreateSite"-Methode beruht auf der Methodensignatur für benutzerdefinierte Aktionen. "SPUserCodeWorkflowContext" wird übergeben, um den Zugriff auf den Kontext zu ermöglichen, in dem der Workflow ausgeführt wird, und um die anderen erforderlichen Parameter bereitzustellen (hier der Name der zu erstellenden Site). Die Methode erhält über den Kontext Zugriff auf die Websitesammlung (SPSite) und die Website (SPWeb) und erstellt die neue Website mithilfe der "SPWeb.Webs.Add"-Methode. Ergebnisse werden über die "Results Hashtable"-Variable zurückgegeben.

Damit "CreateSiteAction" der Dropdownliste "Aktionen" hinzugefügt wird, muss ich mit der Funktion "Eigene" (My) eine Datei "Elements.xml" bereitstellen, um die Aktion für SharePoint Designer 2010 zu beschreiben. Ich füge dem Projekt diese Datei hinzu, indem ich im Projektmappen-Explorer das Projekt "PurchasingMgrActions" auswähle, mit der rechten Maustaste darauf klicke und "Hinzufügen | Neues Element…" wähle und unter "Installierte Vorlagen" die Option "SharePoint 2010" und dann die Vorlage "Leeres Element" wähle. Ich gebe dem Element den Namen "CreateSiteActionDefinition" und klicke auf "OK". Diese Definition wird ermöglicht, indem unter den WorkflowActions-Elementen ein Element vom Typ "Aktion" implementiert wird, wie in Abbildung 13 dargestellt.

Abbildung 13: Definieren der Aktion "Create Site" per "Elements.xml"

<?xml version="1.0" encoding="utf-8"?>

<Elements xmlns="https://schemas.microsoft.com/sharepoint/">

  <WorkflowActions>

    <Action Name="Create Site"

                      SandboxedFunction="true"

                      Assembly="$SharePoint.Project.AssemblyFullName$"

                      ClassName="PurchasingMgrActions.CreateSiteAction"

                      FunctionName="CreateSite"

                      AppliesTo="all"

                      UsesCurrentItem="true"

                      Category="Purchasing Manager Workflow Actions">

      <RuleDesigner Sentence="Create Site with name %1 (exceptions logged to %2)">

        <FieldBind Field="siteName" Text="Site Name" Id="1" DesignerType="TextBox" />

        <FieldBind Field="exception" Text="Exception" Id="2" 

          DesignerType="ParameterNames" />

      </RuleDesigner>

      <Parameters>

        <Parameter Name="__Context"

                      Type="Microsoft.SharePoint.WorkflowActions.WorkflowContext,

                        Microsoft.SharePoint.WorkflowActions"

                      Direction="In"

                      DesignerType="Hide" />

        <Parameter Name="siteName"

                      Type="System.String, mscorlib"

                      Direction="In"

                      DesignerType="TextBox"

                      Description="Name of the site to create" />

        <Parameter Name="exception"

                      Type="System.String, mscorlib"

                      Direction="Out"

                      DesignerType="ParameterNames"

                      Description="Exception encountered"/>

      </Parameters>

    </Action>

  </WorkflowActions>

</Elements>

Das "Action"-Element und seine Attribute beschreiben die Assembly, Klasse und Methode, die aufgerufen wird, wenn die Aktion im Workflow ausgeführt wird. Hier wird die "CreateSiteAction.CreateSite"-Methode aufgerufen. Das "RuleDesigner"-Element und die dazugehörigen "FieldBind"-Elemente definieren den Satz, der im Workflowdesigner angezeigt wird, sowie Name und Typ der Felder, die in diesem Satz als Hyperlinks angezeigt werden. Das "Parameters"-Element und die dazugehörigen "Parameter"-Unterelemente definieren die Übergabe der "RuleDesigner\FieldBind"-Elemente in und aus dem Aufruf von "CreateSiteAction.CreateSite". Der Parameter "__Context" ist z. B. vom Typ "WorkflowContext" und wird verwendet, um diesen Kontext in den Aufruf zu übergeben, ohne dass dies im Designer angezeigt wird (indem das "DesignerType"-Attribut auf "Hide" festgelegt wird). Der Parameter "siteName" empfängt den Wert über die Bindung des "siteName"-Felds. Dies wird erreicht, indem das Feld und der Parameter auf den gleichen Namen festgelegt werden. Ausnahmen werden aus dem gleichen Grund über den Parameter "exception" in das Feld "Exception" übergeben.

Vor dem Testen meiner benutzerdefinierten Aktion öffne ich "Feature1" und lege dafür den aussagekräftigeren Titel "Purchasing Manager Workflow Actions" fest. Den Umfang ändere ich in "Site as required by custom workflow actions" (Site je nach Bedarf von benutzerdefinierten Workflowaktionen).

Bereitstellen der Workflowprojektmappe für SharePoint Online

Zum Testen meiner benutzerdefinierten Workflowaktion klicke ich im Projektmappen-Explorer mit der rechten Maustaste auf das Projekt "PurchasingMgrActions" und wähle die Option "Paket" aus, um die Projektmappe zu verpacken. Anschließend lade ich die Datei "PurchasingMgrActions.wsp" in den Lösungskatalog meiner lokalen Websitesammlung für die Entwicklung (http://o365dpe.contoso.com/sites/spomsdnmag) hoch, um die benutzerdefinierte Workflowaktion bereitzustellen.

Wenn ich jetzt SharePoint Designer 2010 und meinen Workflow "Non-Standard Business Purchase Request Workflow Approval" im Workflow-Editor öffne, wird meine benutzerdefinierte Workflowaktion in der Dropdownliste "Aktion" in der Kategorie "Purchasing Manager Workflow Actions" angezeigt. Dies ist in Abbildung 14 dargestellt.

Abbildung 14: Benutzerdefinierte Aktion "Create Site" im Workflowdesigner

Nachdem ich die Variable "Site Name" auf "Current Item:Title" gesetzt habe, ist mein Workflow fertig und bereit zum Testen (siehe Abbildung 15).

Abbildung 15: Fertiger Workflow

Als Vorbereitung für das Testen muss ich den Workflow auf meiner lokalen Entwicklungssite veröffentlichen und meiner Liste zuordnen. Zum Veröffentlichen wähle ich im Abschnitt "Speichern" die Option "Veröffentlichen". Nachdem die Veröffentlichung durchgeführt wurde, greife ich auf meiner lokalen Entwicklungssite auf die Liste "Non-Standard Business Purchase Requests" zu, klicke auf die Registerkarte "Liste" und wähle im Abschnitt "Einstellungen" des Menübands die Option "Workfloweinstellungen". Unter "Diese Workflows sind für die Ausführung für Elemente dieses Typs konfiguriert" wähle ich "Purchasing Manager – Non-Standard Business Purchase Requests" und dann den Link "Workflow hinzufügen" aus. Ich wähle meinen Workflow "Non-Standard Business Purchase Request Approval" als Vorlage aus, gebe dem Workflow den Namen "Non-Standard Business Purchase Approval" und klicke dann auf "Weiter" und "Speichern".

Nun kann ich meinen Workflow ausführen. Ich wähle das erste Element in meiner Liste aus, wähle im Menüband im Abschnitt "Workflows" die Option "Workflows" und klicke auf den Workflow "Non-Standard Business Purchase Approval", um diesen zu starten. Ich werde zum Eingeben einer geschäftlichen Begründung aufgefordert, wie ich dies im Initiierungsformularparameter "Business Rationale" angegeben habe.

Ich gebe wie in der Darstellung gezeigt eine Begründung an und klicke auf "Start", um den Workflow zu starten. Dann kann ich auf die Seite "Workflows" für das Element zugreifen und den in Ausführung befindlichen Workflow auswählen, um die Seite "Workflowinformationen" anzuzeigen, die eine Visualisierung des Workflows enthält. Nachdem die Aufgabe genehmigt wurde, wird das Diagramm aktualisiert. Dies ist in Abbildung 16 dargestellt.

(Zum Vergrößern auf das Bild klicken)

Abbildung 16: Seite "Workflowinformationen" mit Visualisierung

Ich kann dann auf "Websiteaktionen | Alle Websiteinhalte einblenden" zugreifen und die Site anzeigen, die mithilfe der benutzerdefinierten Workflowaktion erstellt wurde.

An diesem Punkt kann die Workflowprojektmappe unter SharePoint Online bereitgestellt werden. Um die Paketdatei für meinen Workflow "Non-Standard Business Purchase Request"abzurufen, öffne ich den Workflow in SharePoint Designer 2010 und wähle im Abschnitt "Verwalten" des Menübands die Option "Als Vorlage speichern" aus. Der Workflow wird in der Websiteobjektbibliothek gespeichert. Nun kann ich die Paketdateien "PurchasingMgr.wsp" (falls schon bereitgestellt, kann ich die vorhandene Liste ändern), "PurchasingMgrActions.wsp" und "Non-Standard Business Purchase Request Approval.wsp" aus der Websiteobjektbibliothek in den Lösungskatalog meiner SharePoint Online-Websitesammlung hochladen. Beachten Sie, dass die Funktionen basierend auf den Abhängigkeiten zwischen den Funktionen in dieser Reihenfolge aktiviert sein müssen (dies kann über die Abhängigkeiten der Funktionsaktivierung automatisiert werden). Nach dem Aktivieren der Workflowfunktion auf meiner Site und dem Zuordnen des Workflows zu meiner Liste kann ich die gleichen Schritte ausführen, um meinen Workflow unter SharePoint Online zu testen.

Zusammenfassung

Das Automatisieren von Geschäftsprozessen mithilfe von Workflows in SharePoint Online kann die Zusammenarbeit über das einfache Speichern von Informationen unter SharePoint Online hinaus noch effektiver machen. In diesem Artikel habe ich gezeigt, wie Sie einen Workflow in SharePoint Designer 2010 implementieren, diesen Workflow mithilfe einer benutzerdefinierten Workflowaktion, die mit Visual Studio erstellt wurde, erweitern und den Workflow dann über Paketdateien verteilen, die mit SharePoint Designer 2010 und Visual Studio 2010 erstellt werden. Ich möchte Sie ermutigen, sich eingehend mit der Workflowentwicklung in SharePoint Online vertraut zu machen. Ihre Benutzer werden beeindruckt sein, wie sich die Effizienz ihrer manuellen, fehleranfälligen Geschäftsprozesse erhöht und dabei weniger Aufwand anfällt, wenn die Automatisierung mit SharePoint Online-Workflows verwendet wird.

Chris Mayo ist Technologiespezialist mit dem Spezialgebiet SharePoint Online und schon seit zehn Jahren bei Microsoft tätig. Er ist Mitautor von "Programming for Unified Communications with Microsoft Office Communications Server 2007 R2" (Microsoft Press, 2009). Bevor er zu Microsoft kam, arbeitete er als Entwickler und Architekt in den IT-Abteilungen von Fortune 500-Unternehmen in der Einzelhandels- und der Finanzbranche. Verfolgen Sie Mayos Blog unter blogs.msdn.com/b/cmayo.

Unser Dank gilt den folgenden technischen Experten für die Durchsicht dieses Artikels: Mark Kashman, Keenan Newton, AJ May und George Durzi