Adding Activities to SPD

Adding Activities to SPD

Rate This
  • Comments 42

GabeEilene Hey everyone,

Eilene Hao and Gabe Hall here, a program manager and developer on the SPD workflow team; nice to meet you! Today we’d like to answer one of our most frequently asked questions: adding activities into the SPD workflow designer. There’s a more detailed whitepaper describing this in the MOSS SDK’s ECM Starter Kit, but we thought it might be good to give you guys a quick summary, show you another example and give you some tips and tricks to help solve common issues.:)

How does it work?

Before we start with the walkthrough, let’s do a quick rundown of how the SPD workflow designer interacts with actions in SharePoint, so that what we do might make a little more sense.;)

All the actions you see in the SPD workflow designer are activities that live in a DLL on the SharePoint box (e.g. Microsoft.SharePoint.WorkflowActions.dll). There’s a .ACTIONS XML file in the SharePoint TEMPLATE directory on the local file system that describes how to display each of that DLL's activities in a sentence form and bind parameters to the activity’s properties. SPD reads all .ACTIONS files in the directory, then shows all the activities in the designer and pushes the data you enter down into the activity’s properties.

So how do you “import” the activity?

  1. Create an activity with promoted properties in Visual Studio 2005 called CreateACLTask. This activity is similar to the “Assign a ToDo item” action, except it only assigns to one user, and it restricts permissions on the task so that only the user it’s assigned to can see or edit it.
  2. Deploy the activity DLL to the Global Assembly Cache (GAC). This will allow SharePoint to load the activity code you wrote.
  3. Add the DLL to the web.config files. I.e. tell SharePoint that your new activity is safe to use. :)
  4. Create and deploy a .ACTIONS file for the activity to describe the sentence. SPD can read this to know what sentence to create and how to link that sentence into the activity.

Step 1: Creating the activity

This’ll be a pretty basic activity. In Visual Studio, hit File->New->Project and select a workflow activity library. For this action, we’re going to create a task, wait for user to edit the task, and then complete the task. So just 3 activities in sequence: CreateTaskWithContentType, OnTaskChanged, and CompleteTask. Fill out the properties like you normally in a VS workflow.

What’s special about the activity we’re building is that it uses the SpecialPermissions property on CreateTaskWithContentType. This property takes a hashtable of user-permission pairs (e.g. “DOMAIN\john”, SPRoleType). If you bind a hashtable to SpecialPermissions, CreateTaskWithContentType will strip out all existing permissions and only add permissions for each pair you add to the hashtable (if you don’t bind anything to it, it inherits permissions from the task list). So if you wanted only the user the task was ‘assigned to’ to see or edit, you would just say: hashtable.Add(“DOMAIN\john”, SPRoleType.Contributor).

Of course, in this case, we don’t know who this assignee is; he’s specified in SPD, so how do we get that property from the designer?

Enter promoted properties. Promoted properties are properties that are exposed externally to a parent workflow or activity. When SPD generates the parent workflow, the parent workflow passes values through this property into the child activity. Here, we want to get the assignee of the task, so we create a “Dependency Property” with a handy code snippet and name it “Assignee”.

So we bind all the properties on our activity, and now in the CreateTask handler, we’ll use the following code:

private void CreateTask(object sender, EventArgs e)
{
    taskId = Guid.NewGuid();
    taskProperties.AssignedTo = Assignee; //Assignee demoted from SPD!
    taskProperties.Description = "Complete the task";
    taskProperties.Title = "You have a new task";
    specialPermissions.Add(Assignee, SPRoleType.Administrator);
}

The last piece of info we need in this activity is the content type for the task. A content type for a workflow tasks is what determine which aspx form to use for editing a task. Have you ever seen the New Task dialog that pops up in SPD when you add an “Assign a Todo” action? This dialog actually creates a new task content type along with an .aspx form to go with it.

So to get the content type, we just need to bind CreateTaskWithContentType’s ContentTypeId property to a promoted property. Rather than use a snippet, this time we can just select create a new property directly from the property binding dialog:

http://blogs.msdn.com/blogfiles/sharepointdesigner/WindowsLiveWriter/AddingActivitiestoSPD_FE79/clip_image002.jpg

Next, add whatever code you want, and with Assignee and ContentTypeId promoted, we can now deploy it so that you can use it in SPD.

Step 2 and 3: Deploying the DLL and adding it to the authorized types list

Once we’re done with our code, we can compile it and get our DLL. Our DLL should go into the server/web front end’s GAC (%windir%\assembly) so that SharePoint can find and load the activity.

But before SharePoint will run the activity, it has to know that our new dll’s types are safe and trusted so we need to add it to the web.config file. Updating the config file’s authorized types means this activity can be used in declarative workflows in WSS (the workflow equivalent of ‘safe for scripting’). To open this file:

  1. Open the IIS console.
  2. Find the web site that is your SharePoint web under the "Web sites" node and select it.
  3. Right click and choose "Open".
  4. In the folder window, open the web.config file.

In web.config, browse to the bottom section and look for <System.Workflow.ComponentModel.WorkflowCompiler>. Inside that tag there should be an <authorizedTypes> section and an entry for each set of types. Add your type with the following line of XML:

<authorizedType Assembly="CreateACLTask, Version=1.0.0.0, Culture=neutral, PublicKeyToken=7114224e81918c16" Namespace="CreateACLTask" TypeName="Activity1" Authorized="True" />

Step 4: Creating and adding a .ACTIONS file

Now that our activity can be used by WSS, we have to add it to the actions that SPD can author by adding an entry in a .ACTIONS file. It’s a relatively straightforward XML file; however it has a few moving parts so we will just highlight the important aspects today.

Go to your WSS install directory (typically Program Files/Common Files/Microsoft Shared/web server extensions/12), and find the template/1033/workflow folder. (replace 1033 with the proper language ID if it’s not an English server). Place the following in a new file with the name ‘CreateACLTask.actions’:

<?xml version="1.0" encoding="utf-8"?>
<WorkflowInfo>
  <Actions Sequential="then" Parallel="and">
    <Action Name="Assign To-do Item with restricted permissions" ClassName="CreateACLTask.Activity1" Assembly="CreateACLTask, Version=1.0.0.0, Culture=neutral, PublicKeyToken=7114224e81918c16" AppliesTo="all" CreatesTask="true" Category="Task Actions">
      <RuleDesigner Sentence="Assign %1 to %2 with restricted permissions">
        <FieldBind Field="Title,ContentTypeId" DesignerType="Survey" Text="a to-do item" Id="1"/>
        <FieldBind Field="Assignee" DesignerType="SinglePerson" Text="this user" Id="2"/>
      </RuleDesigner>
      <Parameters>
        <Parameter Name="ContentTypeId" Type="System.String, mscorlib" Direction="In" />
        <Parameter Name="Assignee" Type="System.String, mscorlib" Direction="In" />
      </Parameters>
    </Action>
  </Actions>
</WorkflowInfo>

Essentially, this is a copy of the “Assign To-do item” entry in WSS.ACTIONS with a couple minor changes to the sentence, assembly, and bindings. Now, just do one IISReset and open SPD to create your new locked-task workflows! :)

Tip: the most common pitfall is adding a .ACTIONS or web.config entry which doesn’t exactly match your custom DLL. If you find that the action shows up in SPD, but nothing appears when it is selected, verify that the entries you’ve made match the activity class exactly. If a particular binding won’t change, make sure your .ACTIONS field bindings match the promoted properties in your DLL.

In Office 2007, building actions for SPD can be easier and faster than authoring a workflow in Visual Studio. We’ve attached the sample files if you’re interested in taking a closer look.

Good luck and we hope this helps :)!

Eilene and Gabe

Attachment: CreateACLTask.zip
  • SharePoint Designer Team Blog に、Visual Studio 2005 で開発したワークフローのカスタムアクティビティを、SharePoint Designerのワークフローに登録する方法が公開されました。

  • FWIW, there's an extremely small typo in the article.  When you say "find the templates/1033/workflow folder", "templates" should be "TEMPLATE".  At least on my box.  :-)

    Other than that, this article is the best.

  • Ahh good catch, thanks!

  • Hi folks, it's Gabe Hall again with a quick tip you can use when developing workflow activities on WSS

  • Maybe you can reference the post of Todd Baginski (and me ofcourse ;)) on how-to simply add a custom workflow activity to SPD?

    Todd's post : http://www.sharepointblogs.com/tbaginski/archive/2007/03/08/HOW-TO_3A00_-Create-a-custom-Windows-Workflow-Activity-and-make-it-available-in-SharePoint-Designer.aspx

    My posts : http://glorix.blogspot.com/2007/03/spd-workflow-activity-copying-listitem.html and http://glorix.blogspot.com/2007/03/spd-workflow-activity-creating-document.html

  • Three good references to get you started: HOW TO: Create a custom Windows Workflow Activity and make

  • Great! This helps a lot...

    Could you please post a list of all available Designertypes and a little "howto" of how to build a custom designertype?

    Bye

    Stefan

  • Q: In .xoml file of workflow I've found some intresting line:

    <ns0:FindActivity ListId="{}{DD89B2BF-CB7D-4E2E-BF0A-5883D63B442C}" x:Name="ID83" FieldName="Author" ......cut...../>

    Parameter ListID - it's public property of FindActivity class (I'm thinck so).

    And questions is: the first pair of {} - that is? Does this the WebID or not?

    If that is'nt WebID then what is?

    PS Sorry for my English.

  • Freeman,

    WebID is implied by the workflow's web.  It isnt passed into the FindActivity.  ListID can be a name of a list or a GUID.  The first pair of {} is not used to determine web or list.

    Stefan,

    That is a great topic for future posts.  I'll add it to the list.

    -Gabe Hall

  • spdblog,

    Thanks. Why i'am ask for - i'm want to use linked List for FindActivity from another Web (but same Site scope)

  • Is there a way to deploy your new "authorizedType" to the Web.config (similar to adding a safe controls entry) using a SharePoint Solution?

    I would like to allow deployment of new SPD Actions via SharePoint Solution deployment.

    Thanks!

  • Excellent, well though there are number of other articles on custom activity but i was stuck in an issue which ur "pitfall" section took care.

    Thanks,

    http://metahat.blogspot.com

  • Cool, with every new article there is one new detail... ;-)

    But as stefan allready asked. Is there a list with all available designer types? Would be a great insight...

    And if there is a way to extend or buid custom ones, even better.

  • こんにちは。 方法を掲載しようと思いましたが、既にチュートリアルとサンプルのダウンロードが可能なページがありますのでご紹介します。(下記リンク) Adding Activities to SPD (Microsoft

  • Hi all,

    I have found the wssacions.xsd at http://johnholliday.net/download/wssactions.xsd. There you can find all available Designertypes:

     <xs:enumeration value="ChooseDocLibItem" />

     <xs:enumeration value="ChooseListItem" />

     <xs:enumeration value="CreateListItem" />

     <xs:enumeration value="Date" />

     <xs:enumeration value="Dropdown" />

     <xs:enumeration value="Email" />

     <xs:enumeration value="Integer" />

     <xs:enumeration value="FieldNames" />

     <xs:enumeration value="ListNames" />

     <xs:enumeration value="Operator" />

     <xs:enumeration value="ParameterNames" />

     <xs:enumeration value="Person" />

     <xs:enumeration value="SinglePerson" />

     <xs:enumeration value="StringBuilder" />

     <xs:enumeration value="Survey" />

     <xs:enumeration value="TextArea" />

     <xs:enumeration value="UpdateListItem" />

     <xs:enumeration value="WritableFieldNames" />

    But i still need help for designing custom designertypes.

    HELP!!

    Bye

    Stefan

Page 1 of 3 (42 items) 123
Leave a Comment
  • Please add 7 and 2 and type the answer here:
  • Post