Fundamentally, this is a MAJOR architectural change from previous versions of SharePoint. Previously SharePoint hosted the .NET Workflow Foundation Runtime. This mean that workflow was a native part of SharePoint. Many customers experienced issues with scale and some workflows simply being dropped. For me workflows were always a bit of a pain and the story was convoluted before SharePoint 2013… but everything changes now!
Microsoft has taken a completely new approach that is very friendly to the cloud and on-premises in a uniform story. In this post I want to highlight a few things that are important to note.
Introducing Windows Azure Workflow
The biggest sweeping change is workflow is no longer hosted by SharePoint. Now all new SharePoint 2013 style workflows are hosted by a new product, Windows Azure Workflow. This product is a separate install from SharePoint 2013 (and there’s a hosted version of it as well already set up for Office 365). It scales well because you can install a Windows Azure Workflow (WAW) farm of multiple servers and then connect your SharePoint farm to your WAW farm.
This isn’t exactly true… SharePoint still has the .NET Framework 3.5 SP1 workflow runtime, but this is only to host & execute the old pre-SharePoint 2010 workflows. You can also have WAW new SharePoint 2013 style workflows call into .NET 3.5 SP1 workflows using a new interop activity.
When you create a new workflow & publish it to SharePoint 2013, SharePoint retains the “truth” but also publishes it to the WAW server. When you do something in SharePoint that triggers the workflow, SharePoint tells WAW to start the workflow & passes some context to it. WAW then uses the SharePoint client side object model (CSOM) to get more information and run the workflow.
One thing that’s pretty cool about this new set up is that it is super easy to debug the SharePoint to/from WAW communication using Fiddler. I’ll show how to set this up in a future post.
Before you start wondering about reliability and transparency, let me relieve a few things. There is a built-in retry that is inherent in both SP2013 & WAW where they will each keep trying to call the other if there’s an interruption of service. If there is an interruption, things are queued up for later processing. As for transparency, there’s a bunch of APIs in the CSOM to view & interact with workflows from off the SP2013 box, but you can also use some of the REST APIs in WAW to get access to what’s going on.
Building Workflows
A big change from previous workflow frameworks is that we no longer create coded workflows, or those workflows that we created with Visual Studio 2010 in SharePoint 2010. All workflows are declarative, even those created with SharePoint Designer 2013 (SPD2013) or Visual Studio 2012 (VS2012)! The first question people have about this is “what about custom code?” The guidance is that you should create a WCF service for that custom code and move the code outside of SharePoint with this new service. So how to call the custom code? Ah… a beautiful new thing called the HTTP activities / actions! We can now call services and get the responses from our workflows in both SPD2013 & VS2012!
Some other random but big improvements are the ability to have loops in SPD2013 authored workflows as well as using Office-like controls like COPY/PASTE/CUT/MOVE for actions & activities.
Workflow Stages
One really cool thing is a new concept called stages. This gets around the loss of state machine workflows in this version. Basically a workflow is consisted of one or more stages. Each stage has a gate at the end which determines where the workflow should go next. Should it end or should it transition to another stage, or should it move to another stage based on some condition? Very cool stuff!
Tooling: SharePoint Designer 2013
What’s new with SPD2013? Aside from the fact we get loops, stages and common Office-like controls, if you have Visio installed Microsoft also added a visual designer right into SPD2013. Not only do you get the designer, but you also get a fantastic ability to edit the properties of activities you add to the workflow.
Tooling: Visual Studio 2012
The biggest change here is that workflows you create with VS2012 are declarative in nature. If you need custom code, you use the HTTP activities and call out custom WCF services. How do you use the data returned by them? With the new data type: DynamicValue… which brings me to…
Dynamic Value Data Type
This is a new data type in WAW. There’s a more technical and complicated explanation to this data type but I think it’s easier to understand in the context of how it’s used. Basically it understands JSON. So when you call a WCF service with an HTTP activity, it returns an object of type DynamicValue. You then use another activity to pull data out of this variables of this data type using an XPATH like notation. I’ll show how to use this in the next post. I’m a HUGE fan of this!
Workflows & Apps
There’s one more very cool concept here: using workflow as the business logic to your apps. Say you want to create a SharePoint-Hosted App. Your business logic must be baked in client-side code. Some people don’t care for that… maybe you have specific business logic to protect, maybe something more complicated, maybe you want to send an email? What you could do is build a workflow and include it in your app. When deployed, the workflow will be deployed to the WAW servers. Then from the WAW you can call Web services, send emails or do whatever! Pretty cool way to secure and make a more robust app!
