I said that I would cover this topic and so I will. However, this one is just going to be mostly links to other resources as the topic has been pretty well covered already. If you’re uncertain what I’m talking about here, the general idea is that SPD ships with about 20 Actions and a handful of Conditions out of the box. These are literally the building blocks with which you build a custom SPD workflow by stitching them together to meet your business requirements. The ability to add custom Actions or Conditions to the SPD toolbox is likely the single most important feature of SPD with regard to building workflows. Without it, you would be limited to only the capabilities Microsoft provides. The ability to add your own Actions and Conditions makes the tool eminently more useful.
As I said, this topic has been well covered elsewhere, so here are the links to the information:
· Creating custom Actions:
o Some documentation from MSDN: http://msdn2.microsoft.com/en-us/library/ms465980.aspx
o John Holliday’s write up: http://www.johnholliday.net/archive/2007/03/27/Add-Your-Own-Custom-Workflow-Activities-to-SharePoint-Designer-2007.aspx
o Carlos Segura Sanz’s write up that John refers to: http://www.ideseg.com/AddCustomWorkflowActivitiesToSharePointDesignerPart1.aspx
o Some common problems covered by Edin Kapic: http://edinkapic.blogspot.com/2007/07/common-pitfalls-in-sharepoint-designer.html
o A write up from Frode Sorhoy: http://sharepointbergen.blogspot.com/2007/04/creating-custom-actions.html
o Eilene Hao and Gabe Hall’s entry on the topic: http://blogs.msdn.com/sharepointdesigner/archive/2007/03/15/adding-activities-to-spd.aspx
There are others, but you should be able to do whatever you need from these write ups.
Now, the one thing that is interesting is that none of these (or any others that I’ve come across) covers adding a new Condition to the SPD toolbox, so I’ll cover that here with an excerpt from my book:
A condition is used to determine which steps of our workflow will execute. As we discussed in Chapter 4, the SharePoint Designer ships with a number of default conditions that will be sufficient in many situations. However, we can add our own if the defaults do not fit the bill. Adding a custom condition is pretty much as easy as the custom action. A custom condition is simply a class that contains one or more public, static methods. There is nothing that would stop the class from containing other things as well, like, perhaps, our custom action that we just created. The static method called by the SharePoint Designer to evaluate our condition must return a Boolean value. In order to demonstrate this functionality, we can either create a new class library or simply add the static method to our custom action assembly. The benefit to this latter option right now is that part of our configuration will then already be done—the entry in the web.config file will be exactly the same as what we entered for the custom action. In the interest of time, I am going to choose the latter route and add my condition method to my custom action assembly.
The entire contents of my condition method are shown in Listing 9-26. Obviously this is extremely simple—I always return true. In your custom condition, you can perform whatever actions you need to in order to determine your return value. Calling web services, instantiating and using other objects, interacting with the SharePoint object model—these are all fair game for your condition.
Listing 9-26. A Simple Condition Method but Complete Nonetheless
public static bool ReturnTrue()
{
return true;
}
As before, we need to register our condition assembly as an authorizedType in our web.config. The entry for this will follow exactly the same model as the entry for our custom action. We also need to register our condition with WSS. Again, we do this in a very similar manner—adding more text to our .actions file. The options for parameters and fields are the same as for the action, with one notable exception—any fields passed in to our method must be declared parameters of the method we wrote. So, for example, if we wanted to pass in the name of the current user, we would need to code our condition method to accept a string parameter. This makes a certain amount of sense—if we’re going to declare a parameter, our method is going to have to be able to accept it. My sample code for the .actions file is shown in Listing 9-27. This code would go right above the opening <Actions> element but below the <WorkflowInfo> element. The end result is shown in Figure 9-16.
Listing 9-27. Adding a Custom Condition to the .actions File
<Conditions>
<Condition Name="AlwaysTrue"
FunctionName="ReturnTrue"
ClassName="WorkDayDate.GetWorkDayDate"
Assembly="WorkDayDate, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=16837ed8463a28fd"
AppliesTo="list"
UsesCurrentItem="true">
<RuleDesigner Sentence="True">
</RuleDesigner>
<Parameters>
</Parameters>
</Condition>
</Conditions>
That’s it. Between the links above and the book excerpt you should have everything you need to add custom Actions and Conditions to SPD.
Enjoy!
-Dave
PS: Perhaps the Conditions part is a little confusing because it references the custom Action I build in the book, which I did not include here. If it doesn’t work for you, post a comment and I’ll add the rest.