How To... Create and debug a state machine workflow in SharePoint 2010 using Visual Studio 2010 and c#

Estimated time to complete 60 minutes


Welcome

Hello and welcome to this 4 part series of How to create and debug a state machine workflow in SharePoint 2010 using Visual studio 2010 and C#.

Do you ever find yourself learning something new but not use the technology for a while, then when you come back to use that technology you need a refresher ? Well that was my inspiration for this post. I hope you find the post useful and please feel free to include a link to this blog! I may even try to crack the odd joke or put in a silly remark to remove you momentarily from the many steps in the post.

Pre Requisites
This post assumes a few pre-requisites;

• You can code in C#


• You can create sites and document libraries in SharePoint 2010


• You can use Visual Studio 2010 comfortably.
  

This post is a full step by step guide, so be sure to let me know if you think I’ve missed something out that’s worthy of noting.

As most of you probably already know there are two types of workflow; state machine and sequential.

• State machine workflows transition from state to state


• A sequential workflow transfers from activity to activity
  

This post will cover the basic operations of a simple state machine workflow. Right before we get started I have assumed the following:

• You have a SharePoint TEAM site that has been created especially for this demo. You will need to note the URL of the site.


• Also , you have created a document library called ‘DEVJobs’ within the site, here is how my site looks:

Before we get all technical we will quickly run through our fake business requirements, but hopefully you will be able to relate to this fake business scenario.

Business Scenario

Business Agility - A Microsoft Gold Partner wishes to provide a business process for its product development arm of the business. Project managers wish to file a development QA status report, which a developer needs to complete and then a tester needs to complete for each SharePoint web part that is developed.

A developer will mark a web part development as complete when it has been coded and unit tested. The tester will review the web part and will usually mark the web part QA as complete, in the unlikely event that the web part fails some kind of compliance; the tester will reject the Web part passing it back to a developer for some rework.

Click Here for PART 1