This means that the list of Actions you can use in SharePoint Designer to build a workflow is extensible.
Great Feature indeed!
But how Workflow Actions are dynamically injected into SharePoint Designer UI ?
As usual, I asked this same question to Sir Google but nothing came out.
So, once again, a new expedition has to be launched in the SharePoint Galaxy !
When Google is of no help, I have always found that the SharePoint 2010 SDK could be of great help (and vice-versa) !
So I started my journey in the SharePoint Galaxy by searching the exact term "Workflow Actions" in SharePoint 2010 Foundation SDK.
The first topic that came was : "Creating Declarative, No-Code Workflow Editors".
OK this topic title about NoCode is exactly what I am looking for. So lets double click on that topic and then ... bingo ! (Yes, dear Reader, the SharePoint 2010 SDK is sometimes more powerful than Google !)
SharePoint Designer contacts a so called websvcWebPartPages Web Service and invoke the method FetchLegalWorkflowActions on this Web Service.
It sounds to be a good start !
The problem is : there is no Web Service called websvcWebPartPages in SharePoint Foundation 2010 !
By looking around in the Galaxy, I found that many of the available SharePoint Web Services are exposed through the _vti_bin url.
Fortunately I know a little bit of IIS : I loaded the inetmgr.exe (the IIS managment console) and looked at my SharePoint Web Sites; _vti_bin is a virtual directory that is mapped to the physical directory :
- "C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\ISAPI".
Inside that folder I found a Web Service called WebPartPages.asmx.
Next step was to load this Web Service in the browser :
- http://<sharepoint web site url>/_vtin_bin/webpartpages.asmx
Do you think there is some logic in burring Workflow features inside a Web Service that essentially manages Web Part?
So know I know that Workflow Actions are dynmically injected within SharePoint designer by calling this Web Service and invoking the FetchLegalWorkflowActions on it.
At that point the journey is not finished.
What happens, on the SharePoint server side, when the FetchLegalWorkflowActions method is called?
I asked this same question to Sir Reflector. I discovered that Workflow Actions may come from two sources on the SharePoint Server :
- The first source is the folder 14\TEMPLATE\LCID\Workflow. In that folder, all files with .ACTIONS extension are merged and sent back to SharePoint Designer. The LCID value is dynamically read at runtime from the Language property of the current SPWeb object.
- The second source are Features. This second source is a great discovery for me. Why ? because it means you might extend the Workflow Actions for SharePoint Designer in the context of a Sandbox Deployment (which is required for SharePoint Online). The method called in the SharePoint API to get those Features is GetWorkflowActionsFromFeatureElements(). This method is looking for elements that are deployed declaratively through the <WorkflowActions> xml section. The problem is that I found no concrete example neither in the SharePoint SDK nor in the 14\TEMPLATE\FEATURES folder. Each search for a WorkFlowActions xml element in the SDK inevitably refers .ACTIONS files in the 14\TEMPLATE\LCID\Workflow. Argh ! A new expedition in the Features Galaxy has to be launched after this journey !
At that point the original question - how Workflow Actions are dynamically injected into SharePoint designer UI ? - is partly answered.
As usual, every journey in the SharePoint Galaxy is incomplete. So dear Reader be patient !