If you have been following any of the news about SharePoint 2013, you already know that the workflow capability has been enhanced significantly. The most important change is that workflows now execute outside SharePoint. Please refer to the diagram below. (This diagram is taken from MSDN with some annotations.) As you can see, workflows are hosted externally. The external host for workflows can either be Windows Azure or customer-provided infrastructure.  Why is this change so important?  Recall all the knobs and switches we had to turn as SharePoint developers to prevent workflow execution from overwhelming the SharePoint farm.

Examples include throttle settings to limit the number of active workflow instances, and batch limit to determine the number of waiting workflow items that can be executed in a single run. As you can imagine, moving workflows out of SharePoint provides for much more scalability and robustness in execution. At the same time, it is important to note that workflow metadata, associations and scope are still stored within the SharePoint content database. This way the end user is oblivious to the actual location where workflows are being hosted.

Also notice the SP Application Proxy in the diagram. It provides the connectivity between SharePoint and Workflow Manager Client. The communication itself is more scalable as it is based on a more scalable pub/sub pattern (as opposed to a direct communication).

Additionally, there is a much larger block of the SharePoint OM dedicated to workflow. This is depicted as “Workflow Services Manager” in the diagram above. Workflows can not only call out to external systems via new messaging functions, but, in turn, are available to external systems via the Workflow Services Manager. It is also worth mentioning that a whole host of new activities is available with SharePoint 2013.

Finally, the externalization of workflow execution allows for full parity between on-premises and Office 365 environments. When the workflows were co-located with SharePoint 2010, installing workflows (with custom activities) required admin privileges. As a result, custom workflows were out of bounds for SharePoint online environments.

Perhaps you knew about the new workflows features already. But if not, hopefully this quick primer motivates you to look at workflows in SharePoint 2013.

[pullquote]The biggest underlying change is the fact that the workflow engine powering SharePoint workflow has itself changed.[/pullquote]My main objective for this post is to point that while these features are very cool, the biggest underlying change is the fact that the workflow engine powering SharePoint workflow has itself changed. Technically, SharePoint 2013 is based on Windows Workflow Foundation (WF) 4.5+. SharePoint 2010 was based WF 3.5. While this change may seem like an incremental change to maintain parity with the latest .NET version of the WF, the truth is that WF 4.0 is a major rewrite of Windows Workflow Foundation.

.Net developers working with WCF / WF (in conjunction with AppFabric) have already realized these benefits since the release of .NET 4.0. For SharePoint developers, however, this is the first chance to leverage the benefits of this major rewrite to WF.

Here are few highlights of the changes brought about by WF 4.0:

  • WF 4.0 gives you much better control over persistence. There is no need to persistent the entire state of the workflow. You don’t even have to unload the workflow to persist them. Additionally, workflows are based on the Activity class (rather than SequentialWorkflowActivity or StateMachineActivity). These changes make workflow instance much more lightweight, resulting in 10-100X improvement in performance.
  • Workflows can be fully declarative, thus removing the need for messy code beside assemblies.
  • Better integration with WCF. This includes the ability to wire up a web service invocation declaratively, ultimately enhancing the richness of the SharePoint designer in SharePoint 2013.
  • Flowchart-style workflows that map much more easily to business processes that SharePoint developers are trying to implement.
  • Ability to declare variables and parameters within a workflow program.
  • Ability to improve testability by providing the ability to invoke workflows as methods using WorkflowInvoker.

If you are interested in diving deeper into WF fundamentals, I recommend reading this chapter from my book. (Wrox and Jim Minatel were kind enough to make the chapter (“The WF Programming Language”) available for free.  In this chapter, I present WF as a programming language in its simplest form, devoid of Visual Studio designers or starter projects.

On a personal note: This chapter is my very humble attempt to emulate my favorite book of all time – the famous K&R book. That is the book that introduced me to ‘C’ 25 years back. While there is no chance for me to come even remotely close to simplicity of the K&R book, I think of my effort as homage to Dennis Ritchie, who passed away in 2011. (By the way, don’t forget to check out the rest of the chapters in the book written by experts including  Christian Weyer, Bill Evegen, Christian Nagle.)