Custom Workflow Actions für SharePoint Designer

Es war nun ein langer und mühsamer Weg, bis ich endlich eigene Workflow Actions für den SharePoint Designer 2010, entwickeln konnte. Deshalb stelle ich hier kurz vor, wie man vorgehen kann.

Der SharePoint Designer, bzw. SharePoint selbst bietet ja schon einige Aktionen für das zusammen klicken von Workflows für das Microsoft SharePoint 2010.

Doch manchmal gibt es Szenarien bei denen man nicht um Programmierung herum kommt. Damit man nun nicht den ganzen Designer mit all seinen Vorteilen über Bord werfen muss, kann man sich eine eigene Workflow Action programmieren, welche dann im SharePoint Designer verfügbar ist.

Kurz noch zum Inhalt dieses Beitrages:

  1. Tools installieren und einstellen
  2. Visual Studio Solution erstellen
  3. Anwendung Programmieren
  4. Anwendung auf dem Server eintragen
  5. Anwendung über die Webclient.config freigeben
  6. Testen

Reqiuerments

Zuerst nun aber einmal eine Aufzählung der benötigten Software und Kits:

  • Microsoft Visual Studio 2010
  • Microsoft  .Net Framework 3.5
  • Visual Studio 2010 Tools for SharePoint Development
  • Zugriff auf einen Microsoft SharePoint Foundation Server 2010 oder höher

 

Visual Studio Solution

Als erstes erstellen wir nun eine Visual Studio Solution mit einem leeren SharePoint-Projekt. Ich arbeite mit C#, sollte mit VB aber auch funktionieren.

Das ganze kann man als Sandkastenlösung oder auch als Farmlösung bereitstellen. Ich habe Farmlösung genommen.

Danach müssen wir zwei Verweise dem Projekt hinzufügen:

  • Microsoft.SharePoint.WorkflowActions
    C:Program FilesCommon FilesMicrosoft SharedWeb Server Extensions14ISAPImicrosoft.sharepoint.WorkflowActions.dll
  • System.Workflow.ComponentModel
    C:Program Files (x86)Reference AssembliesMicrosoftFrameworkv3.0System.Workflow.ComponentModel.dll

Dazu erstellen wir auch noch eine neue Klasse für unsere Custom Action, welche vom Typ Activtiy erbt.

System.Workflow.ComponentModel.Activity

Zuletzt trägt man noch die using Direktiven nach:

using System.Workflow.ComponentModel; using System.ComponentModel; using Microsoft.SharePoint; using System.Diagnostics;

Erstellen der Activity

Eine Activtiy besitzt eine virtuelle Execute Methode welche man überschreiben kann und mit eigenem Code füllen. Darin wird alles Programmiert, was während der Ausführung verarbeitet werden soll (Items verändern, Listen hinzufügen usw.).

protected override ActivityExecutionStatus Execute(ActivityExecutionContext executionContext) { try { } catch (Exception ex) { EventLog.WriteEntry("MyCustomActivity", ex.ToString()); } return ActivityExecutionStatus.Closed; }

Ich habe in die Funktion, direkt ein try-catch eingefügt um einen Fehler in der Logik abzufangen. Mit dem EventLog Objekt kann ich loggen, was vor sich geht.

Wirklich machen tut diese Action momentan noch nicht, aber man könnte Sie nun schon bereitstellen und verwenden.

Da es aber interessant sein könnte, eine Eingabe des Benutzers zu bekommen, müssen wir noch Properties dafür programmieren. Da die Activity von diesen Eingenschaften abhängig ist, werden sie DependencyProperty genannt.

public static DependencyProperty InformationProperty = DependencyProperty.Register( "Information", typeof(string), typeof(MyCustomWorkflow));

Dies ist nun eine DependencyProperty Namens “Information” vom Typ string.  Dies ist aber nur eine Definition und deshalb müssen wir noch eine “richtige” Property für “Information” erstellen. Diese Property besitzt das Attribut DesignerSerialization.Visible.

[DesignerSerializationVisibility (DesignerSerializationVisibility.Visible)] public string Information { get { return ((string) (base.GetValue(MyCustomWorkflow.InformationProperty))); } set { base.SetValue(MyCustomWorkflow.InformationProperty, value); } }

Nun können wir unser Projekt builden und haben den Teil im Visual Studio abgeschlossen.

Assembly freigeben

Damit man die Assembly verwenden kann muss man Sie aber noch auf dem Server im globalen Assembly Cache registrieren und in der IIS Webkonfiguration eintragen.

Dies erfolgt über die Visual Studio Eingabeaufforderung mittels folgendem Command:

gacutil -i MyCustomAction.dll gacutil -l MyCustomAction

Um direkt noch die Informationen über die Assembly zu bekommen, geben wird noch den Parameter -l für den Namen der Assembly an.

Microsoft (R) .NET Global Assembly Cache Utility. Version 4.0.30319.1 Copyright (c) Microsoft Corporation. Alle Rechte vorbehalten. Der globale Assemblycache enth„lt die folgenden Assemblys: MyCustomAction, Version=1.0.0.0, Culture=neutral, PublicKeyToken=fe651b0ea77c4813, processorArchitecture=MSIL Anzahl der Elemente = 1

Nun besitzen wir alle Informationen die wir für das eintragen in die IIS Konfiguration benötigen. In die  web.config gelangt man über den IIS Manager (.Net-Authorisierungsregeln).

C:inetpubwwwrootwssVirtualDirectories80web.config

Dort tragen wir nun einen neuen authorizedType ein, damit unsere Assembly auch vom SharePoint verwendet werden darf.

<authorizedType Assembly="MyCustomAction, Version=1.0.0.0, Culture=neutral, PublicKeyToken=fe651b0ea77c4813" Namespace="MyCustomAction" TypeName="*" Authorized="True" />

SharePoint Designer Actions

Nach dem dieser Schritt getan ist, müssen wir nur noch unsere Action für den SharePoint Designer ersichtlich machen. Dazu erweitern wir die WSS.ACTIONS Datei um eine weitere Action.

Die WSS.ACTIONS Datei befindet sich auch auf dem SharePoint Frontend Server.  Da wir eine zweisprachige Installation haben, besitzen wir diese Datei zweimal. Die Dateien sind durch den Ländercode zu unterscheiden.

C:Program FilesCommon FilesMicrosoft SharedWeb Server Extensions14TEMPLATE1033WorkflowWSS.ACTIONS C:Program FilesCommon FilesMicrosoft SharedWeb Server Extensions14TEMPLATE1031WorkflowWSS.ACTIONS

Ich verändere hier im Beispiel die Englische Sprachdatei, also diese mit dem Code 1033.

Im Xml Element Actions tragen wir ein neues Element ein mit folgenden Eingenschaften:

<Action Name="MyTestActivity" ClassName="MyCustomAction.MyCustomWorkflow" Assembly="MyCustomAction, Version=1.0.0.0, Culture=neutral, PublicKeyToken=fe651b0ea77c4813" AppliesTo="all" Category="Cross Site Actions"> <RuleDesigner Sentence="I %1 this"> <FieldBind Field="Information" DesignerType="TextArea" Text="do" Id="1"/> </RuleDesigner> <Parameters> <Parameter Name="Information" Type="System.String, mscorlib" Direction="In" /> </Parameters> </Action>

Hier definieren wir den Namen der Activtiy, die Programmierte Klasse (mit Namespace), die Assembly in der die Klasse hinterlegt ist und die Kategorie, in der die Activity dann gelistet wird. Des weiteren kann man hier auch den Zugriff auf die Activity steuern.

Danach wird im Xml Element  RuleDesigner der Ausdruck gewählt, der im Designer später angezeigt werden soll, sowie die Felder die ausgefüllt werden müssen. Diese müssen natürlich mit den Properties aus der Klasse übereinstimmen.

Im Abschnitt Parameters definieren wir, was für ein Typ von Daten darin abgefüllt werden. Hier müssen die Parameter natürlich auch mit den Fields von der programmierten Klasse übereinstimmen.

Testen

Nun haben wir alles erstellt was wir brauchen und können einen ersten Test wagen! Am besten restatet ihr kurz den IIS, damit die Konfiguration vom Designer auch neu geladen wird.

Beim mir steht leider ein Falscher Name, da ich meine Action schon wieder umgeschrieben habe.

Das war ein kurzes und hoffentlich nicht zu ausschweifendes Tutorial.

Gruss Florian

Quellen:

  • http://msdn.microsoft.com/en-us/library/bb629922(v=office.12).aspx
  • http://blogs.msdn.com/b/tolong/archive/2006/11/16/how-to-get-your-publickeytoken.aspx

Retrace:

  • http://sharepointcommunity.de/blogs/mgreth/archive/2011/05/25/sharepoint-designer-2010-custom-workflow-actions.aspx