Redesigning a SharePoint 2010 Workflow Project for SharePoint 2013

Workflow in SharePoint 2013 has undergone quite the architectural change from its SharePoint 2010 ancestor.  I documented many of the major changes in a previous blog post, “What Changed in SharePoint 2013 Workflow? Pretty Much Everything.”  While SharePoint 2013 is backwards-compatible with SharePoint 2010 workflows, you may decide that the benefits of the new design are needed.  The purpose of this post is to illustrate the new considerations you’ll need to keep in mind when targeting SharePoint 2013 workflows. The SharePoint 2010 project we’ll use for this example is the one from my very first AIS blog post, “Developing Multi-Tiered Solutions for SharePoint.”

Web API Methods Mockup screen shot

Figure 1 - Sample WebAPI methods for Section Document Merge and Post-Merge Actions.

In our example project there are actually two workflows, SectionDocumentApprovalState (SDAS) and MasterDocumentApproval (MDA). The MDA checks if the various SDAS-related sections have been merged and finalized, then notifies specific users for approval of the final document. An instance of SDAS is created for each section, created from the Master Document that monitors the editing and approval of the specific section. We’ll focus on just the SDAS workflow. In the previous post, I referred to the workflows as being part of the Presentation Layer and the custom code called into the Business Layer.  Both of these layers will change in a SharePoint 2013 workflow solution.

Business Layer

Our Business Layer consisted of the Project, ProjectFileBase, and the various file type classes. Since the new workflow model doesn’t allow custom code to be written, we’ll convert these classes to web services.  We have a few options for where these services could be hosted.

Build Dynamic Value Variable mockup screen shot

Figure 2 - Example of a DynamicValue object that uses the WorkflowTaskList item template for path recognition. This could be passed to create a new task via SharePoint's web services.

First, we could keep them in the SharePoint farm so we would be able to reuse nearly all of the code, since we can utilize the SharePoint Server Object Model.  The only changes we would need is a reference to the document, its location, and response data, if required.  Figure 1 displays the mocked-up web methods that will replace the old project class methods in the Business Layer.

Second, we could host it on a Windows server in IIS, either on-premises or in a cloud environment like Windows Azure. This would make the services easier to use outside of SharePoint should the client want to use them in other types of applications (i.e. Windows 8, iOS, web, etc.).  However, in addition to the changes for hosting in the SharePoint farm, we would need to establish a trust between the environments, likely using some established or custom claims provider that both recognizes and can relate to the SharePoint user.  Also, interaction with the SharePoint objects would need to be done differently. The SharePoint Server Object Model can’t be used on a server that’s not part of the SharePoint farm. While we could use the managed SharePoint Client Object Model to manipulate the SharePoint artifacts from the web service, it might be better to pass the necessary information back as a JavaScript Object Notation (JSON) object and let the workflows manipulate the SharePoint objects.  This obviously is a far more involved process since there would be a lot of code changes, but would allow for the load to be taken off of a SharePoint farm.

Sequence activity with BuildDynamicValue and HttpSend activities.

Figure 3 - BuildDynamicValue creates a data object to pass to the service for use in the method. HttpSend makes the service call.

Finally, the services could be written in another language and/or hosted on another server operating system, like Linux. This would allow the client to utilize potentially less expensive licenses or more experienced developers to build and maintain the solution. While this would require a complete re-write of the layer from C# to whichever language, the client may find that, for instance, a Node implementation on Ubuntu is easier and less expensive for them to maintain than C# on Windows Server because they have the infrastructure and development experience to support it. All of the considerations from the first two options would be part of this hosting option in addition to the complete re-write of the code base.

Presentation Layer

Once we have the Business Layer converted to web services, we need to address the workflows. In our project, we have a custom activity that the SDAS uses to process section merging and post merge logic. These method calls would become part of the web services and the workflow would replace the custom activity with a sequence that builds the web service headers, request content, calls the web service, and — if necessary — captures the response content. The headers and content variable would be of a new type called DynamicValue.  This new type is a collection of name/value pairs that Workflow Manager can interpret and pass it the service in the appropriate format (i.e. XML, JSON).  Figure 2 shows an example of building a DynamicValue variable to pass data to a web service.

Properties window for the HttpSend Activity.

Figure 4 - The new HttpSend activity has several properties that can be configured. Method and Uri are required.

If the web services managed changes to the SharePoint artifacts like updating the task status, then there would be little extra the workflow would need to do outside of managing state. However, if the object manipulation were to be handled by the workflow, there are many activities available to manipulate SharePoint as well as using SharePoint’s web services to modify related artifacts. Figure 3 and 4 illustrate the sequence to build a DynamicValue object for web service request content and the HttpSend activity.


While the architectural changes to SharePoint 2013 Workflow and Workflow Foundation 4.0 are a big shift from SharePoint 2010, this project wouldn’t be extremely difficult to migrate to a SharePoint 2013 workflow solution if the new web service Business Layer ran on the SharePoint farm. There would be some code changes for SharePoint context and artifact manipulation, but the majority of the code would work since the server Object Model would still be in use. Since SharePoint 2013 runs older workflows, it may not make sense to upgrade every workflow in your environment so you’ll need analyze your environment.