Update (4/4/2007): I've just learned that another SharePoint blogger has written about this very topic 3 months ago. The weird part is that the custom action he created also writes to the event log. In all honesty, this was sheer coincidence (I really should learn to do a search before posting!). In the interest of fairness and in the spirit of giving credit where it is due, you should check out the following articles by fellow SharePoint MVP Carlos Segura Sanz:
http://www.ideseg.com/AddCustomWorkflowActivitiesToSharePointDesignerPart1.aspx
http://www.ideseg.com/AddCustomWorkflowActivitiesToSharePointDesignerPart2.aspx
If you've used SharePoint Designer 2007 to create custom workflows for SharePoint lists, then you know it's a powerful tool for automating business processes. The built-in workflow designer lets you construct fairly sophisticated workflows without writing any code at all. Using this tool to create a workflow is about as easy as setting up a custom rule using the Outlook rules wizard.
Out of the box, you get about two dozen or so activities that you can use to construct your workflows. These activities are pretty comprehensive and let you do things like create and modify list items, send emails, create todo items, etc. But what if you need to do other things? What if you've written some custom activities that, for example, talk to your back-end systems or perform some highly specialized operation?
Well, there's good news. You can extend SharePoint Designer 2007 so you can reference your own custom activities directly from the workflow designer. What's nice about this is that it gives you a tool that both developers and business analysts can use when designing a business process automation solution. The developer can focus on creating libraries of custom activities while the business analyst or administrator focuses on the high-level logic that invokes the activities to do the actual work.
WSS.ACTIONS
What makes this work is a file on the SharePoint server named WSS.ACTIONS. This file is located in the 12\TEMPLATE\1033\Workflow folder. Whenever you open or create a workflow in SharePoint Designer, this file is downloaded to configure the workflow designer interface. It describes the kinds of activities that can be used in a declarative workflow, along with detailed information about how to present the rules you will use to build conditions, specify actions and interact with each activity. By editing the information in this file, you can completely customize the user interface presented in the workflow designer.
The steps to add a simple activity to the SharePoint Designer interface are:
-
Create a custom activity assembly,
-
Sign and deploy the activity assembly to the GAC,
-
Configure SharePoint to recognize the custom activity,
-
Create a .ACTIONS file to be used by SharePoint Designer
Creating a Custom Activity
The first step is to identify or create the custom activity you want to surface in the designer. The following code gives an example of a simple activity that writes a message to the system event log.
using System;
using System.ComponentModel;
using System.ComponentModel.Design;
using System.Collections;
using System.Diagnostics;
using System.Drawing;
using System.Workflow.ComponentModel.Compiler;
using System.Workflow.ComponentModel.Serialization;
using System.Workflow.ComponentModel;
using System.Workflow.ComponentModel.Design;
using System.Workflow.Runtime;
using System.Workflow.Activities;
using System.Workflow.Activities.Rules;
namespace MyCustomActivity
{
public partial class EventLogger: Activity
{
public EventLogger()
{
InitializeComponent();
}
public static DependencyProperty MessageProperty
= System.Workflow.ComponentModel.DependencyProperty.Register(
"Message", typeof(string), typeof(EventLogger));
[Category("MyCustomActivity"), Browsable(true)]
[DesignerSerializationVisibility(DesignerSerializationVisibility.Visible)]
public string Message
{
get
{
return ((string)(base.GetValue(EventLogger.MessageProperty)));
}
set
{
base.SetValue(EventLogger.MessageProperty, value);
}
}
protected override ActivityExecutionStatus
Execute(ActivityExecutionContext executionContext)
{
using (EventLog log = new EventLog("MyCustomActivity"))
{
try
{
log.Source = "EventLogger Activity";
log.WriteEntry(this.Message, EventLogEntryType.Information);
}
catch
{
}
}
return ActivityExecutionStatus.Closed;
}
}
}
In this code, the Message property is used to specify the text that will be displayed in the event log, and we use a dependency property to enable the workflow to bind data to it. As with all workflow activities, the Execute method performs the action.
Deploying and Registering the Activity
After you build the custom activity assembly, sign it and copy it to the GAC. You then have to tell SharePoint to trust the assembly. This is similar to configuring a web part as a safe control, but instead of adding an entry to the <SafeControls> section, you add an entry to the <System.Workflow.ComponentModel.WorkflowCompiler> section. Edit the web.config file for your SharePoint web application and add an <authorizedType> element as in the following example:
<authorizedType Assembly="JohnHolliday.Workflow.EventLoggerActivity, Version=1.0.0.0,
Culture=neutral, PublicKeyToken=0b97b340d4a71524"
Namespace="MyCustomActivity" TypeName="*" Authorized="True" />
Creating the .ACTIONS File
The final step is to create the .ACTIONS file that describes the activity to SharePoint Designer. Since this is an XML file, you can create it using Visual Studio or any XML editor. Unfortunately, the XML schema for this file is not part of the SharePoint SDK. So I have created a WSSACTIONS.XSD schema file which you can download here. (Thanks to Scot Hillier for helping to uncover some of the more elusive enumerations like DesignerType and OperatorTypeFrom, etc.) Using the schema file in Visual Studio lets you use intellisense when creating the .ACTIONS file and makes the job of declaring custom activities much easier.
This file describes the public properties exposed by the activity and tells SharePoint Designer how to map those properties into rules that can be displayed to the user. The following code shows a custom .ACTIONS file for the custom EventLogger activity.
<?xml version="1.0" encoding="utf-8" ?>
<WorkflowInfo>
<Actions Sequential="then" Parallel="and">
<Action Name="Write Message To Event Log"
ClassName="JohnHolliday.Workflow.EventLogger"
Assembly="JohnHolliday.Workflow.EventLoggerActivity, Version=1.0.0.0, Culture=neutral, PublicKeyToken=0b97b340d4a71524"
AppliesTo="all" Category="MyCustomActivities">
<RuleDesigner Sentence="Write '%1' to the event log">
<FieldBind Field="Message" DesignerType="TextArea" Id="1"/>
</RuleDesigner>
<Parameters>
<Parameter Name="Message" Type="System.String, mscorlib" Direction="In"/>
</Parameters>
</Action>
</Actions>
</WorkflowInfo>
The Actions tag tells SharePoint Designer what to display for each action in the set. Within that, the Action tag describes the individual action. The Name attribute is what gets displayed in the designer. The ClassName and Assembly attributes are used in the generated XAML for the workflow. The interesting part is the way the RuleDesigner and Parameter tags work. The RuleDesigner tag lets you setup a sentence that gets displayed in the designer as you build up the workflow. The Sentence attribute allows you to bind to the activity properties and then substitute their values when the activity is executed.
Remember the Message property of the custom activity? The FieldBind tag includes a Field attribute that specifies this property by name. The DesignerType attribute specifies which kind of control to use to gather the data, and the Id property specifies the substitution id to use when building the sentence. Now look at the Parameter tag. This specifies the activity side of the contract and is used when calling the Execute method of the activity on the server.
You can declare as many actions as you want in the file. A good rule of thumb is to use a separate .ACTIONS file for each logical group of custom activities you wish to deploy. Once you've created your .ACTIONS file and copied it to the server, you can refresh the site in SharePoint Designer and your custom activity will appear in the workflow designer as shown below.
Summary
Workflow activities are a lot like web parts. The richer your collection of activities, the more powerful workflows you can build. You can leverage the power of Visual Studio to create specialized custom workflow activities and take advantage of the flexibility built into SharePoint Designer 2007 to create declarative workflows that incorporate your custom activities but require no coding. This is a great way to surface customized functionality to a wider audience of administrators, developers and business analysts.
Technorati : moss, sharepoint, sharepoint designer, workflow
Del.icio.us : moss, sharepoint, sharepoint designer, workflow
