SharePoint workflow is powered by Windows Workflow Foundation, and custom WF activities can be used in a SharePoint workflow. Here is how to add SharePoint context to your custom activities, allowing you to perform SharePoint functions or make use of information about the item under workflow.
SharePoint context is provided through three Dependency Properties (Dependency Properties are a XAML concept, both important to Windows Workflow Foundation). You can have one to store the Id of the item the workflow is running on, the Id of the list that the item exists in and one for a SharePoint context object (Microsoft.SharePoint.WorkflowActions.WorkflowContext). The code to add the List Item Id property looks like:
public partial class MyActivity : Activity
{
public static DependencyProperty ListItemProperty;
static MyActivity()
{
MyActivity.ListItemProperty = DependencyProperty.Register("ListItem", typeof(int), typeof(MyActivity));
}
[ValidationOption(ValidationOption.Required), Browsable(true), DesignerSerializationVisibility(DesignerSerializationVisibility.Visible)]
public int ListItem
{
set {
base.SetValue(MyActivity.ListItemProperty, value);
}
get {
return (int)base.GetValue(MyActivity.ListItemProperty);
}
}
…
}
The property 'ListItem' can then be accessed within your code. The pattern can be repeated for the List Id and WorkflowContext properties, usually called __List and __Context respectively (using existing SharePoint activities as a guide).
So what can you do with these properties? The List Id and List Item properties are self explanatory; it’s the Context object that has some interesting functionality. First off it exposes the Web and Site that the workflow is running in (Within the activity, SPContext.Current returns null), and with those two objects the SharePoint world is yours.
The second use of the Context object is to pass it on to the helper static methods in Microsoft.SharePoint.WorkflowActions.Helper. This class provides a number of static methods for interacting with SharePoint, most of them requiring a WorkflowContext object.
Independent of the above concept, there are also four SharePoint specific service providers that can be instantiated within a SharePoint workflow activity. These provide additional methods for interacting with SharePoint. They are IListService, ITaskService, ISharePointService and IWorkflowModificationService (in the Microsoft.SharePoint.Workflow namespace). You can access an instance of them in the Execute method of your Activity:
protected override ActivityExecutionStatus Execute(ActivityExecutionContext executionContext) {
IListItemService service = (IListItemService)executionContext.GetService(typeof(IListItemService));
…
Deployment
There are three steps to make your custom activities SharePoint Designer ready.
First, install your activity assembly into the GAC on the server.
Second, register the type as a Safe Action in web.config. For example:
<System.Workflow.ComponentModel.WorkflowCompiler>
<authorizedTypes>
<authorizedType Assembly="System.Workflow.Activities, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" Namespace="System.Workflow.*" TypeName="*" Authorized="True" />
</authorizedTypes>
</System.Workflow.ComponentModel.WorkflowCompiler>
The third step is to add your Activity to the WSS.Actions file. This xml file is used to tell SharePoint Designer how to handle and configure the available activities. You can copy the format of an existing Activity (find one that can operate on the workflow'ed list item) and modify it to suit your needs. I haven’t come across an xsd to assist in WSS.Actions editing.
WSS.Actions is found at <SharePoint dir>\template\1033\Workflow\Wss.Actions
Restart IIS, load up SharePoint Designer and your activity should be in the list.