Till this point we have been working with sequential workflows. Sequential workflows are suitable for all processes where all the "arrows" seem to be pointing in one direction. If you have processes where you may be repeating previously completed steps then you may need what are called state machine workflows. The state machine workflows follow the state machine model which has a number of states linked by transitions. A transition represents an event that triggers the change of state. For any given state there may be N number of transitions resulting in any one of the available states.
This workflow type requires prior understanding of the state machine concept, which I cannot describe in detail here. Let's create a project called LightBulb which has two states, you guessed it right, On and Off. Naturally then we need a "toggle" event for the button which changes the state from one to another. Once the project is created you will see something like this.
This is the initial condition of a state. It allows you to drop a number of activities in it as visible from the diagram. Lets change the name of this state to BulbOff and create another state called BulbOn. Right click on the BulbOff activity and add an EventDriven activity to it. Double click and it should look something like this:
Here lets add a code activity to display a custome message and a SetState activity to change state. The EventDriven activity represents the transition and you can perform whatever actions necessary here during it. At the start you should drop a HandleExternalEvent to catch the transition event. At the end you should do a SetState to change the state to some other activity, otherwise it will stay in the same one.
Lets do the same for the other activity and its SetState should bring us back to this state. Now we need to implement the event that drives both these states. Coincidently in this case its the same event for both on and off, which is the toggle of the switch. Following the previuos post lets define an interface to generate that event.
With this event we set the parameters for both the HandleExternalEvent activities in each state. We can set the same event for both of them because at any given time the workflow will be in one state, hence we can give them difference behaviour. The worflow now looks like the following:
The event properties of the HandleExternalEvent like:
Once this has been taken care of lets write the code to trigger the event and set our workflow rolling. First we need to add this as a service and the write the code to deliver the message to the workflow instance.
The the event delivery code with a bit of twist.
Now when we run it, we see the workflow changing state and executing the code activity. Press escape and it exits.
Before we end this post lets just look at one more thing, initialization and finalization code. These activities you can add to each state and they will be executed once you enter or leave the state. Lets add both and it should look like this:
Add a code activity to each and put a relevant message in there.
In the next post we will look at how to call external web services and expose workflows as web services.