NoCode Workflows are first class citizen (Part3 : What are the possible scopes for a Workflow Action ?)

In a previous post, I mentionned that is possible to create Workflow Actions for SharePoint Designer 2010 and deploy them in a Sandbox environnement.
To do this, you have to create a Feature which references a WorkflowActions element file. You can find a typical walkthrough at http://msdn.microsoft.com/en-us/library/ff798499.aspx

The problem is that a Feature is targeted at a specfied scope and in the context of a Sandboxed deployment, the two possible scopes available are Site (you target all sites in a given Site Collection) and Web ( you target a specific Web Site inside the Site Collection).

When you google around, the scope is fixed at Site with no explanation. Even on MSDN and in the SDK you are told to set the scope at Site!

As usual, any source of information found on the web should be partially trusted !

This post is the result of another journey in the SharePoint Galaxy.

So where is the information that could be trusted about the possible WorkflowActions scope ?
Of course in the SharePoint API.

So I asked Sir Reflector to assist me in this journey. As usual Sir Reflector always gives an anwser.
Inside the SharePoint API, you have a method called Validate on a SPElementDefinition class:

   1:    if ((((type == typeof(SPContentTypeBindingElement)) || (type == typeof(SPEventElement))) || ((type == typeof(SPListInstanceElement)) || (type == typeof(SPListTemplateElement)))) || (((type == typeof(SPModuleElement)) || (type == typeof(SPFieldElement))) || (((type == typeof(SPPropertyBagElement)) || (type == typeof(SPWorkflowActionsElement))) || (type == typeof(SPContentTypeElement)))))

   2:      {

   3:          flag = (scope == SPFeatureScope.Web) || (scope == SPFeatureScope.Site);

   4:      }

The above code (from the SharePoint API) is very clear : a Workflow Action can be deployed at two possible levels : Site or Web.

End of the story.

NoCode Workflows are first class citizen (Part2 : How SharePoint Designer knows about the Actions you can use to build a Workflow ?)

I have discovered in the SharePoint Galaxy that a SharePoint developer can create Workflow Activities in Visual Studio and deploy these as Actions for SharePoint Designer.

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 :

1. 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. 
2. 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 !

NoCode Workflows are first class citizen (Part1)

Act I :
What a surprise when you discover that SharePoint Designer 2010 can duplicate a workflow like the Approval Workflow enabling you to create your own approval workflow, not starting from scratch, but just by customizing  an OOB workflow !
This means you are able to create a very complex Approval Workflow with just a few clicks !  Ouah!
End of Act I.

Act II :
SharePoint Designer 2010, like SharePoint Designer 2007,handles only declarative workflows (also called NoCode workflows).
So what ?
The OOB workflows that are available in MOSS 2007 have been moved from a .Net assembly  form  (MSIL format) to a NoCode form (XAML format) in SharePoint 2010.

This shift is quite impressive and the message that is pushed to Visual Studio Developers is the following : be careful - sooner or later - you MUST master the NoCode way of life otherwise ...

So, if you are, like me, on the Visual Studio side for SharePoint Customization, then you have to shift to the NoCode world in order to survive!
End of Act II.

Act III :
Take a journey to explore the NoCode world in SharePoint !
There is no End to this Act.