State machine is a well-known model for event-driven workflows and a highly requested feature from our WF4 users, especially those looking to move their WF3 State Machine workflows to WF4. We are very pleased to provide a new, fully-supported, WF4 State Machine including runtime and designer in the .Net Framework Platform Update 1 release (KB2495638). This release enables customers to model their event-driven processes as a state machine using a simplified API and designer experience. Thanks to all who evaluated the CodePlex preview of the WF4 State Machine. We incorporated much of your feedback in this final release.
State Machine Activity in WF4 is the encapsulating entity for a state machine execution model. The basic elements of a state machine are:
· States – A finite list of the possible states the state machine can be in
· Transitions – A list of a possible state changes
· Final State – A State which upon reaching it will terminate the StateMachine
A state machine can have multiple states. It must have only one initial state but can have zero to multiple final states.
A very basic scenario that can demonstrate a state machine is a stop watch, as described in the WF4 StateMachine modeled in the State Machine Activity Designer below:
This state machine has four possible states:
On- initial state of the stopwatch, no data is displayed
Started - the stopwatch internal clock is started and the display is updated every 10 milliseconds.
Stopped - the stopwatch internal clock is stopped and the display shows its last value.
Off - the stopwatch is powered off. It is a final state in this stop watch model.
Each State supports execution of Activities modeled as Entry and Exit actions which allow Activities to be scheduled upon entering or exiting the state. It should be noted that, State itself in WF4 is not an Activity.
Let’s look at the State designer for “On” State.
The user can drag and drop any activity into the Entry and/or Exit action.
To improve navigation, the State designer also provides an aggregated view of all the Transitions originating from the State as well as the destination State for that Transition.
States include a collection of Transitions. A Transition defines the movement from a source State to a destination State. Each Transition is configured with a Trigger Activity, typically an event driven Activity such as Receive Message or Delay. A user can also specify an expression as the condition of a transition. Additionally, an optional Transition Activity may be included. The Transition designer below shows the “Start Clock” Transition.
In the example here, the Transition event is “StartTheWatch” Activity. The Stop Watch will only transition to “Started” State after “StartTheWatch” Activity completes representing the Transition Trigger event reflecting the watch has started successfully.
Upon the StartTheWatch event, the StartedSuccessful condition is evaluated. If false, the Transition won’t be executed and the Trigger Activity will be rescheduled.
A transition can contain a Transition Action which will be executed after exiting the source State and before entering the destination State.
Many States simply need to automatically transition after the Entry Action is completed. In WF4, we support a default Trigger using a “Null” Trigger Action. A Trigger configured without a Trigger Activity will be fired by default upon entering the State, after the State’s Entry Action has been completed. Transition Conditions will still be evaluated.
You can also have multiple Transitions share the same Trigger. This type Trigger is called Shared Trigger. In the case of a shared Trigger, all the Transitions must have a condition specified.
In the Stop Watch example, when the user presses the “start” button, the stopwatch first checks the status of the battery. If there is power remaining, the state machine will transition to the Started State. If there’s insufficient power, then the State Machine will transition to the Off State. Now let us modify the Stop Watch to add a Shared Trigger Transition “OutofBattery”.
To create a Shared Trigger Transition “OutOfBattery”, we drag a Transition line from the same source State connector used by the “Start clock” Transition.
Here is the Transition designer view of “OutOfBattery” Shared Trigger Transition.
These two Transitions, “Start clock” and “OutOfBattery”, are sharing the same Trigger event “StartTheWatch” Activity.
A Shared Trigger allows for the conditional progression to a next state based on the evaluation of expressions configured for multiple Transitions which share a common Trigger event.
In this example here, if Stop Watch isn’t started successfully, it will proceed down the “OutOfBattery” Transition and then move to state “Off”.
Auto Insert and connect In WF3, it takes several steps to insert a new state and a transition. The user will need to manually create transitions when introducing a new State. Adding a new State to existing StateMachine in WF4 becomes much easier with “auto insert” and “auto connect” designer enhancements.
Tracking WF4 provides the State level tracking ability to enable tracking when a WF instance enters each state. In StateMachine library, there is a public member “StateMachineTrackingRecord”, which is built on top of CustomTrackingRecord. Users can write a custom TrackingParticipant to track StateMachine events to get the history of States.
Debugging Users can set breakpoints on any Activity in a State or Transition.
State Variable Users can specify variables in the scope of a StateMachine or a State in WF4.
To learn more about the object model for WF4 State Machine and its usage, please refer to this MSDN Document. Also, please check out our great new Hands on Lab for State Machine. It should be very helpful to get you started on using WF4 State Machine.