Workflow, as far as I can tell at this point, is one of the most overhauled functionalities from SharePoint 2010 to SharePoint 2013. The first major difference is that it’s no longer contained within SharePoint. Workflow is now handled by Windows Azure Workflow (WAW).

“Whoa, whoa, whoa! Does that mean I’m going to have to pay Microsoft some hefty usage fees to have Workflow in my 2013 environment? I really don’t see how that’s going to fly with the bosses,” you say.

Fortunately, no, that’s not the case. While I’m sure there will be a model for this, it’s not the only one. You can host WAW on-premises just like SharePoint. We’ll delve into that momentarily. Windows Azure Workflow is built on Windows Workflow Foundation 4.5 (WF4.5). WF4.5 introduces several new features as detailed in the MSDN article “What’s New in Windows Workflow Foundation.” This will require a separate install that can run on a SharePoint server or its own environment. We’ll also look at the architectural implications in a bit.

The “meat” of this post is going to focus on three areas: Architecture, Development, and how these would affect the design of an existing SharePoint 2010 Workflow project. The architecture changes only start with WAW and WF4.5. We’ll discuss the installation requirements, how it’s hosted, security, and the Pros and Cons of WAW. The development story has changed, at least to me, far more. I’ll explain the changes to coding (Hint: You can’t…directly), how web services can remedy the last statement, and custom actions. Finally, we’ll take a look at the project I discussed in my last post “Developing Multi-Tiered Solutions in SharePoint” and how that design would be changed for a SharePoint 2013 environment.

Architecture

As I mentioned above, Workflow runs under Windows Azure Workflow. By taking workflow processing out of SharePoint and creating a Workflow “farm,” several improvements become available. First, the SharePoint farm(s) now have less processing to do. The WAW environment will manage the workload and update SharePoint via web service connections. SharePoint has plenty of loads to manage and SharePoint 2013 introduces multiple features that are, or can be, offloaded to other environments outside of SharePoint. Second, it’ll help simplify the upgrade process to SharePoint version 16 (SharePoint 2016??). Microsoft has said essentially that there should be little to no server-side development. We all know the upgrade nightmares caused by a plethora of custom solutions.

Another improvement is the ability to use WAW for multi- and cross-platform workflow. This will allow you to host all your .NET workflows, regardless of if they’re SharePoint, for Windows applications, or Web applications. There’s also the ability to reuse the same workflow for multiple platforms. For example, Contoso has a proprietary Windows application that processes IS equipment requests. A .NET workflow was created to manage the approval process for these requests. They decided to also create a SharePoint App that is accessible via Contoso’s intranet and allows users to monitor their requests as well as IS to update requests’ statuses from their mobile device. By hosting this in WAW, both of these applications can access the workflow.

Windows Azure Workflow, despite its name, can be hosted on premises. As of this writing, I could not find any cloud model offered by Microsoft, but I doubt that’ll be the case for long. When hosting locally, there are a couple of things to note. First, the install is a separate executable from SharePoint Server so you’ll need to download it. Second, installing on a Domain Controller is not supported. However, despite claims to the contrary, it seems MVP Liam Cleary has proven that it’s possible in his post “SharePoint 2013 – Install Windows Azure Workflow Service on a Domain Controller” Remember, this is not supported and could possibly be broken further down the road. Don’t do this in anything but a development environment and be prepared to scrap or fix it should it break in future releases.

Speaking of installing, it’s actually pretty painless. The instructions on MSDN are easy to follow and are accurate. When configuring there are a few things to watch out for, though. Andrew Connell posted some of these. The SharePoint Designer 2013 tip in the article is a great way to test successful configuration, too. I’ll admit, I used the configuration wizard to set it up, but if you’re a PowerShell fan, there are notes on that as well. However, you’ll still need some PowerShell to create the relationship between your WAW farm and SharePoint farm.

Finally, if you’re not working with an SSL certificate, be sure to check the configuration setting for “Allow Workflow Management over HTTP on this computer.”  For a full tutorial, please watch my video, “SharePoint 2013 Workflow: Installation and Configuration,” below:

Sounds great, right? Sure, being able to offload workflow processing to another server farm sounds great, but I have two major concerns. First, I remember the introduction of Forefront Identity Manager (FIM) in SharePoint 2010 for the User Profile Service. There are thousands of posts on forums and blogs concerning the pain points of properly configuring it. I have to wonder if Windows Azure Workflow will just be another potential fail point. I haven’t seen much so far, so hopefully it’s more stable than the User Profile pair.

Second, additional costs for hardware and software could come into play. Spinning up more servers means more Windows Server licenses, virtual machine resources, and/or physical server hardware. If you don’t use workflow much, you might be fine running on one of your SharePoint web front-ends, but as your usage grows, so will the amount of resources it’ll use. Don’t forget to take these into consideration during your upgrade planning.

Development

I’m hoping there are a few developers reading this. If there are and you’re still reading, some of you might be saying something to the effect of:

“Blah, blah, blah. All this architecture stuff is boring. Let me start breaking it with some code!”

Don’t worry, fellow code minions, I’m getting to that now. However, the code you’re wanting to sling probably isn’t quite what you’d expect.

That whole “code” part of “code minions” doesn’t come into play in Workflow 2013. Sorry to burst your bubble, but Workflow is all declarative. You get a pretty little designer and the properties window in Visual Studio, instead. Here’s a silver lining, though: There are activities for interacting with web services. If you need custom logic, create a web service and use the activities to access the web service.

To contain the data, there’s a new object called DynamicValue. It allows you to store data structures and can store other DynamicValues. No, you can’t “back-door” your way into developing native Workflow by inheriting an activity class. I’ve tried that at several levels and they’re all non-public. Custom Actions can still be created in SharePoint 2013 for SharePoint Designer workflows. These will also be subject to declarative development and web services for custom code, though.

Speaking of SharePoint Designer, among various updates, Workflow creation gets some nice updates. It introduces the idea of Stages. Stages allow for workflows that are very similar to state-machine workflows. Loops finally make an appearance, in the forms of “Loop N Times” (think indexed for loops) and “Loop with Condition” (think while loops). There are a few restrictions with loops, but I’m not sure they’re very limiting. First, loops must be contained in a stage and you can’t add a stage inside a loop. Also, they have only one entry and one exit point. However, you can nest loops. They are introducing the Dictionary Type variable in this edition, as well. A Dictionary object is an array of an array of key/value pairs. Think of it as an Excel Worksheet. Each row represents a record in the Dictionary and each row is made up of multiple cells. Each column has a data type associated with it so you can have more than just strings stored.

Architectural Example

As I mentioned above, this example is based on my previous blog post.  However, I’ll give a quick recap of the project. The client needed two workflows that were assigned to Content Types derived from the Document type. The solution ended up becoming a multi-tiered implementation (thus, the title). However, to move this into SharePoint 2013 workflows, some things needed to change.

Since workflows can’t contain code, we have to strip the Data and Business layers out of the project and implement in a Web Service. With the way they’re structured, creating a web service with return values to be consumed by DynamicValues should be straight forward. The client should also be able to host the services, as the current solution already calls into custom services.

In the actual workflows, the custom activities would access this new web service with the HTTP activity objects and load the DynamicValues. One of the considerations that would need to still be worked out is how would we pass the actual documents to the web service to be merged or split? Could we pass the URL and the service access the file directly or can we even just pass the byte array? The byte array would be more universal in the event that the workflows are accessed outside of SharePoint in future client offerings (because the workflow would have the needed access to the store in SharePoint, file share or other location while the web service may not), or configurations would need to be made.

Conclusion

While Workflow has changed drastically from what we were used to in SharePoint 2010, it promises to be a powerful change. The ability to offload the processing from SharePoint will allow for Workflow farms that can benefit the enterprise and will reduce load on the SharePoint servers. Developers have a radical new strategy to learn, the simple integration with web services should provide fast integration with existing data structures. Even business users are given valuable updates in SharePoint Designer Workflow, including the much needed loops.