Since this is our second post to this blog, I thought we should start with something very simple. I am aware that most of you probably know the answer to the question in the title, but this post could help those who don’t know the answer or are not totally sure about it.
What could a state machine (workflow) be? Here’s the definition from Wikipedia:
State machine is a model of behavior composed of a finite number of states, transitions between those states, and actions. (from http://wikipedia/wiki/State_machine).
Let's explain that definition in a practical, easier to understand and to remember way. When you wake up in the morning you are hungry (or you just want some coffee very badly). We could call this state a "Hungry" state. Then, after you had something to eat you transition from the "Hungry" state to another state called "Full". And that's the whole 'science' of state machines. If you think about it, every one of us is always in either one of those states :). You could also add some more states like "Half-full", "A little hungry", etc.
So, what can you use state machine workflows for? You can use them for basically every business process that consists of states. Take for example a simple Word document and its lifecycle. You upload the document to SharePoint document library and the 'state' of the document at that point could be "Submitted". After document is submitted you can assign it to a user to approve or reject it and you get two more states: "Approved"/"Rejected”.
Norm Estabrook mentions an even better example of state machine workflows in his podcast about VSTO SharePoint workflow. Here is except from the recording:
"On the other hand, the steps in your solution may be random in nature and never really have a clear ending. For example, the participants in an HR workflow might move an employment resume from state to state. The resume might be in a state of being considered, interviewing, or archiving for future. The resume might be re-activated or updated at any time. Because there is no linear path of steps for the resume, it would be excessively hard to produce conditional rules to capture all possible paths. In these situations, you would want to manage your workflow as a series of states and transitions. Use the state machine workflow template to get started there."
When should you use state machine workflows? This is kind of a hard question to answer. You could use state machine workflow when for example a document requires multiple reviewers (legal, marketing, etc.) that may sign off on the document in any order. More complex state machines may open up different workflow paths depending on intermediate state.
How about sequential workflow? Sequential workflows are definitely much easier to design and maintain than state machine workflows. The only difference between a state machine workflow and sequential workflow is that in sequential workflow the flow goes from first activity to the next until end of the workflow is reached. In between you can branch the workflow, for example use IfElse or While activity, etc.
What type of workflows are you using more frequently - state or sequential? Are there any rules on when to use specific type of workflows?
Before we get into any technical details, I just wanted to give you the background on how we came up with the idea of having this team blog, what this blog is about, as well as who will be contributing to the blog.
Some of you may have read Peter Jausovec's VSTO blog. One day, while I was brainstorming with Peter on what we could do to get more involved in helping our customers. The goal was to be helpful to our customers but also something fun to do away from our day to day jobs - this doesn't mean our jobs are not fun. :)
We had so many different options, but after weighing on the pros and cons of each, we locked onto the idea of creating a team blog focused on SharePoint Workflows and some of the Office client features. With this team blog, each team member has the opportunity to share his or her insightful knowledge from years of experiences by building the product. We also hope through this blog, we will learn from our customers.
About us? Well, we are a group of Software Design Engineers in Test. The majority of contributors to this blog have been working on VSTO related product or features for quite a few years. From time to time, we will also invite our Program Managers and Developers to be guest contributors. (They may have a few good thoughts to share too!) We currently plan to make 2 to 3 posts on a monthly basis; topics will be mainly on the released products or features. If there is anything specific you want to see us blogging, we would love to hear your feedback.
The types of content you will probably see here include but not limited to:
We plan to make this a fun team activity. There are many incredible creative people on the team. The odds of seeing completely unexpected posts here is pretty high. Check back often! You never know what you may discover! You can subscribe to email alerts or use your favorite blog reader to follow our posts. Please feel free to contact us or post comments too. We love hearing and seeing the creativity of customers as well!
Jing Lou & Brent Williams
On behalf of the Visual Studio Business Applications SharePoint Tools QA team