Handling State Machine Workflow – Part 1

Hi All,

Today we are going to discuss about state machine workflow. First question arises is what is state machine workflow and when to use state machine workflow. I will explain this entire handling of state machine in series.

Ok coming back to our question, the answer is really very simple. If your process doesn’t have sequence of activity that needs to be followed and if you have something which has specific start and ending point, then better that you go with sequential workflow else go for state machine workflow.

Let me give you an simple example where you have different statuses defines and on each status you have to perform certain actions and those statuses can be changed from time to time from different page of Sharepoint or even from any other application which uses the state machine workflow.

Other example where you have bug tracking application which doesn’t have specific ending point as far as bug is concern. Bug can be in open state then it can be in In-Progress State, it can be in submitted state, it can be re-Opened state as many states as we define, which can be in any state and can change to any state.

Changing of state is called transition between states. Transition can happen from any state to any other state which is not fixed defined. In these kinds of scenarios you can use the state machine workflow.

In this article I am not going to show you how to create state machine workflow. I will talk about how to manage state machine workflow. By manage what I mean is how you can call the state machine workflow and change the state of workflow.

State machine workflow is very different story than sequential workflow. It has got many other things.

Now assume that you have created state machine workflow and hosted on one server and your applications for Sharepoint is running on the same server. Now all applications will use this workflow for an instance. So what we have here is every application will start workflow from code let’s say depending on condition and then maintain the instance of it. You need to maintain the instance of the workflow because you also need to change the state of the same instance to the different state.

So here is a full story how you can achieve all these.

First and for most, when you are designing your state machine workflow, do not forget to add persistence service to the workflow runtime. So that you can preserve the workflow instance in the database. Persistence service helps to store the workflow instance in the database when workflow goes idle.

Go to this location. Location may differ from machine to machine depending on framework.

C:\WINDOWS\Microsoft.NET\Framework\v3.0\Windows Workflow Foundation\SQL\EN.

Here you will find four SQL scripts that you need to run against your SQL server database which you want to connect your application with. One is for tracking service and the other is for persistence service.

So Create one database for workflow store because you need to preserve the instances of your state machine workflow in this database and later you need to retrieve this same instance back to the application for further application.

Now run those scripts against the database. First run Schema files and then run logic files.

This way you are ready with the database that can store the workflow instances. The mail reason to store the workflow instances in the database is that it is not a good practice to store long running workflows in memory. Better that we unload that instance and store it in database so it free the memory and when required, load that instance from the database again and then perform the operation and then again unload it.

Now you also have to add ExternalDataExchangeService service if you are familier with State machine workflow, because this services handles the call between client application and workflow host application for data exchange.

Now once you have the database setup for it, it’s time to add the persistence service to the workflow runtime and data exchange service.

WorkflowRuntime workflowRuntime = null;

workflowRuntime = new WorkflowRuntime();
string strWorkflowConnectionString = string.Empty;
strWorkflowConnectionString =
ConfigurationManager.ConnectionStrings[“connectionstringname”].ConnectionString;

workflowRuntime.AddService(new SqlWorkflowPersistenceService(strWorkflowConnectionString));
ExternalDataExchangeService dataExchange;
dataExchange = new ExternalDataExchangeService();

workflowRuntime.AddService(dataExchange);

objService = new SupplierService();

dataExchange.AddService(objService);

workflowRuntime.StartRuntime();

This way we can add both services to the workflow runtime. In my second part i will continue explaining how we can go ahead with taking instances on hand and move state machine workflow ahead.