Part 1 – Pattern for Building Stateful Workflows with SharePoint Designer 2010

· Part 1 - Pattern for Building Stateful Workflows with SharePoint Designer 2010
· Part 2 - Custom Action for Workflow Initiation
· Part 3 - Delays for Workflow Initiation Action
· Part 4 - Using Business Connectivity Services (BCS) with SharePoint 2010 Workflow
· Part 5 - Custom Visio Services Reports with SharePoint 2010 Workflow

Introduction
In the SharePoint 2007 days moderately complex workflow could not be achieved with SharePoint Designer 2007. Individuals would then try to build those workflows using Visual Studio 2007 and then run into a whole new set of complexities. In many cases individuals wanted to use visual tools to build automation inside of SharePoint 2007 only to find out that there were limitations. The end result was developers reverting back to adding event handlers to lists or writing web parts with a custom database.

With SharePoint 2010 workflow tools have matured allowing us to do more complex business process automation. Most notably:

1. Visio 2010 is now a tool that can be used to visually design workflows definitions that can be pulled into SharePoint. It also provides the ability to do reporting and data visualization where graphics can be mapped to data. Then based on the value of that data, conditional logic can be applied to change visual element in Visio (like change something from green to red, or change the shape completely).

2. SharePoint Designer 2010 workflow design tool has significantly improved tremendously. There is Visio integration, InfoPath form integration (initiation, association and task forms), better workflow designer, more workflow fields to interact with, etc. It is almost night and day versus the previous version of SharePoint Designer.

3. Visual Studio 2010 has changed tremendously providing workflow project templates which drastically reduce the level of effort to create workflow process.

4. Workflow definitions can be moved between tools fairly easily only a few limitations.

5. Workflow can be easily redeployed between dev, test and production.

6. Workflow can now run at the site level instead of only being associated to a list item.

One Big Hurdle Left

At the end of the day this is all well and good but there still some holes. Specifically you cannot do state workflows in Visio and SharePoint Designer 2010. SharePoint Designer only supports sequential works. This basically means the flow goes top to down and cannot loop back within the workflow. Not having this capability can be limiting even for a simple workflow process.

The Resolution

Have some assumptions you must take think about with this solution:

1. Let me state first that my solution is pretty clean and simple. But I really only recommend this as a solution for those simple to moderately complex workflows where you just want to be able to achieve stateful workflows without having to do a bunch of custom code.

2. Much of this solution is based on leveraging the OOB capabilities of SharePoint 2010.

3. There is a lot room for improvement of this solution so please use this as a framework to start trying to build some stateful workflows. I will NOT be supporting this solution moving forward. This is just a demonstration of showing you how you can achieve a great solution by using the SharePoint 2010 toolset.

After do some brainstorming the following two things dawned on me:

1. State is relative to the business process instance data; not the business process definition itself. What does that mean? It means you do not have to create a single process definition to manage an entire business process state. Still does not make sense? What I am saying is you do not have to create a single workflow diagram to automate a business process. Instead you can create multiple workflows and chain them together. All of these workflows will manage a single stateful item (record); like a SharePoint list item or document. I like this idea because in actuality state workflows are chained together sequential processes when it comes down to it. My goal is to come up with a pattern that will allow me to daisy chain together many sequential workflows that manage the state of a single item to go through a workflow. Doing this this will allow me to achieve my vision of building workflow in SharePoint Designer 2010 and Visio 2010.

2. The workflow diagram never looks the same as the automation workflow diagram. Visual workflow designer tools are positioned to allow business users to take their process diagrams (box, diamond and arrow diagrams) and quickly transform it into an executable that can run in some system. That is not really easy. The reality is that business person’s workflow diagram never, ever looks like the automation workflow diagram created in a workflow tool. This is because there will be tons of steps added into the diagram to support the actual automation. Using Visio Services in SharePoint 2010, I will be able to come up with a visual report.

I believe I have actually come up with a pretty simple solution change solves these challenges. The following are the elements of this solution.

· Use Visio 2010 to build up the initial workflow definition and then use the SharePoint Designer 2010 to connect the workflow to SharePoint 2010.
· Create custom workflow activity with Visual Studio 2010 that can initiate another workflow. Basically we need to create a simple .NET function that can take some parameters and then initiate a workflow. This will allow for us to chain workflows together.
· Use Visio 2010 for reporting by using its new capability to map to data. We can create a picture that the business user can understand and have it “light up” and report to a user about the current state of a business process execution.

Ok – Show Me What You Are Talking About

Is this still too complicated? Have I gotten a little nerdy on the workflow? Let’s put this into context. Below is a pretty simple review workflow by most standards.

· There is a review step.
· If the item being reviewed is greater than $20K, a manager needs to review it.
· If a request is rejected by the reviewer or manager, the request should go back to the originator for resubmission.
· Only the requestor has the ability to cancel the request.

So you may say what is the big deal? Why did you write all that esoteric stuff about workflow for something as simple as this? Really? Look at the diagram below, the stuff I highlighted in red could not be achieved in a tool that only supports sequential workflow. Because there is a loop back to the initiator to allow them to resubmit this immediately becomes a state workflow.

As well, notice anything else about either of these diagrams? They are simple and what the business users understands. There is nothing in these diagrams that show emails being sent, task items being created, permissions being set, item metadata being updated, data being sent to a database for reporting, etc. If I were to take this diagram and try to model all those steps I can assure you it will become a clutter mess!!!

Solution Design

I am excited to say my solution solves both of these problems!!! First I will be able to break this up into a bunch of connected workflows. Second I will be able to take the original diagram we draw and light it up based on where the workflow is.

So how does the solution work? I will get to the real “how does this work in SharePoint 2010” shortly. First we need to break this workflow into multiple workflows. In the screenshot below you will see that I have broken the business process into five somewhat smaller workflows.

· Initiate – This process will have the responsibility of starting the workflow and performing any activities need to get it going.
· Review – This is the part where the main reviewer reviews the request.
· Manager Review – Workflow that manages the workflow for the manager to review.
· Resubmit – Consolidates the logic for either resubmitting the request or canceling it.
· Complete – Will handle any operations needed to complete the workflow.

When I was designing this solution I was able to test approach with many other more sophisticated workflow patterns (i.e. complex parallel processing or a spider diagram). I was always able to break up the workflow into a set of sequential workflows that could be coordinated with each other.

Building the SharePoint Workflows with Visio 2010

Many of the readers of this blog are aware that they can build SharePoint workflow in Visio 2010. For this solution I will use it to initially build the workflows above however I will not use it for the long term. One limitation is that I will have to build two custom actions in Visual Studio 2010. Custom actions are not supported in Visio 2010 but they are supported in SharePoint Designer 2010.

Initiate Process

Below is the initiate process. Not much going on here other than an email is being sent.

However there are several other things we will need to add when we move this into SharePoint Designer. For instance check to see if any of the other processes are currently running. We have to use a custom action to achieve this which cannot be modeled in Visio.

Review Process

Below is the review process. As you can see I have added some steps to update the state of the Review list item and send an email. Like before, I could not add the actions to initiate the other workflows but I have put in placeholders.

Manager Review

Next I have the manager review. Again I have added some steps to update the review item state, send some emails and put in a placeholder to initiate other workflows.

Resubmit Process

Below is the resubmit process. Again I have added actions that send emails and update the state of the record.

Complete Workflow

Finally we have the complete workflow; pretty self-explanatory.

What’s Next?

Well what we now need to do is bring these workflows into SharePoint Designer 2010 and use some custom actions that can initiate each workflow. In the next part of the series I am going to focus on how these custom actions were built.