Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Yahoo! Search
There is one important decision to make when creating a new workflow. Will the workflow be a sequential workflow, or a state machine workflow? Windows Workflow provides these two types out of the box. To answer the question, we have to decide whois in control. A sequential workflow is a predictable workflow. The execution path might branch, or loop, or wait for an outside event to occur, but in the end, the sequential workflow will use the activities, conditions, and rules we've provided to march inevitably forward. The workflow is in control of the process. A state-machine workflow is an event driven workflow. That is, the state machine workflow relies on external events to drive the workflow to completion. We define the legal states of the workflow, and the legal transitions between those states. The workflow is always in one of the states, and has to wait for an event to arrive before transitioning to a new state. Generally, the important decisions happen outside of the workflow. The state machine defines a structure to follow, but control belongs to the outside world. We use a sequential workflow when we can encode most of the decision-making inside the workflow itself. We use a state machine workflow when the decisionmaking happens outside the workflow. In this chapter, we will take a closer look at how state machines operate.
If you e njoye d this article , you'll e njoy the book e ve n m ore ! O rde r now from Pack t Publishing and save 10%!
9/1/13
A state represents a situation or circumstance. In the diagram below, we have a state machine with two states: a "power on" state and a "power off" state. The machine will always be in one of these two states.
An event is some outside stimulus. In figure 1, we only have one type of event - a button click event. The state machine will respond to this event in either the "power on" or the "power off" state. Not all states have to respond to the same events. A transition moves the state machine into a new state. A transition can only occur in response to an event. Transitions don't have to move the state machine to a new state - a transition could loop back to the same state. When the machine receives a button click event in the "power off" state, it transitions to the "power on" state. Conversely, if the machine is in the "power on" state and receives a button click event, it moves to the power off state. Implied in the concept of a state transition is that some action will take place before or after the transition. A state machine doesnt merely store state - it also executes code when events arrive. In our diagram the state machine would be controlling the flow of electricity by opening or closing a circuit when it arrives in a new state.
9/1/13
inside of State activities to represent the legal events for the state. Inside of an EventDrivenActivity, we can place a sequence of activities that will execute when the event arrives. The last activity in the sequence is commonly a SetStateActivity. A SetStateActivity specifies a transition to the next state.
odetocode.com/articles/460.aspx
3/18
9/1/13
The new project will create a workflow - Workflow1.cs. We can delete this file and add our own workflow file with code separation.
The workflow designer will now appear with our new state machine workflow. At this point, the
odetocode.com/articles/460.aspx 4/18
9/1/13
Toolbox windows will be available and populated with activities from the base activity library. Initially, however, we can only use a subset of activities - the activities listed inside the BugFlowInitalState shape shown below.
Before we can begin to design our state machine, we are going to need some supporting code. Specifically, we need a service that will provide the events to drive the workflow.
Life Of A Bug
State machines will spend most of their time waiting for events to arrive from a local communication service. We know that we will need an interface that defines a communication service contract. The interface will define events that the service can raise to the workflow, and methods the workflow can invoke on the service. For this example, our communication is unidirectional - all we define are events the service will raise to the workflow.
[ E x t e r n a l D a t a E x c h a n g e ] p u b l i ci n t e r f a c eI B u g S e r v i c e { e v e n tE v e n t H a n d l e r < B u g S t a t e C h a n g e d E v e n t A r g s >B u g O p e n e d ; e v e n tE v e n t H a n d l e r < B u g S t a t e C h a n g e d E v e n t A r g s >B u g R e s o l v e d ; e v e n tE v e n t H a n d l e r < B u g S t a t e C h a n g e d E v e n t A r g s >B u g C l o s e d ; e v e n tE v e n t H a n d l e r < B u g S t a t e C h a n g e d E v e n t A r g s >B u g D e f e r r e d ; e v e n tE v e n t H a n d l e r < B u g S t a t e C h a n g e d E v e n t A r g s >B u g A s s i g n e d ; }
The event arguments for these events will require the service to pass along information the workflow can use during processing. For example, one useful piece of information will be a Bug object that carries all the attributes (title, description, assignment) of a bug.
[ S e r i a l i z a b l e ] p u b l i cc l a s sB u g S t a t e C h a n g e d E v e n t A r g s:E x t e r n a l D a t a E v e n t A r g s {
odetocode.com/articles/460.aspx 5/18
9/1/13
p u b l i cB u g S t a t e C h a n g e d E v e n t A r g s ( G u i di n s t a n c e I D ,B u gb u g ) :b a s e ( i n s t a n c e I D ) { _ b u g=b u g ; W a i t F o r I d l e=t r u e ; }
p r i v a t eB u g_ b u g ;
The service that implements the IBugService interface will raise events when the status of a bug changes. The service might fire the event from a smart client application in response to a user manipulating the bug in the UI. Alternatively, the service might fire the event from an ASP.NET web service upon receiving updated bug information in a web service call. The point is that the workflow doesn't care why the event fires, and doesnt care about the decisions leading up to the event. The workflow only cares that the event happens. We will use a nave implementation of the bug service interface and provide simple methods that raise events. Later in the chapter, we will use this service in a console mode program to raise events to the workflow.
p u b l i cc l a s sB u g S e r v i c e:I B u g S e r v i c e { p u b l i ce v e n tE v e n t H a n d l e r < B u g S t a t e C h a n g e d E v e n t A r g s >B u g O p e n e d ;
p u b l i cv o i dO p e n B u g ( G u i di d ,B u gb u g ) { i f( B u g O p e n e d! =n u l l ) B u g O p e n e d ( n u l l ,n e wB u g S t a t e C h a n g e d E v e n t A r g s ( i d ,b u g ) ) ; }
/ /a n ds oo n ,f o re a c he v e n t. . .
Now that we know about the service contract our workflow will use, we can continue building our state machine.
9/1/13
activity for each possible state of a software bug, we'll have a designer view like below.
Notice two of the shapes in the above picutre use special icons in their upper left corner. The BugFlowInitialState shape has a green icon in the upper left because it is the initial state for the workflow. Every state machine workflow must have an initial state the workflow will enter on start-up. We can change the initial state by right-clicking another shape and selecting "Set As Initial State" from the context menu. The BugClosedState has a red icon in the upper left because this is the completed state. A workflow is finished upon entering the completed state, but a completed state is optional. In many bug tracking systems, a bug can be re-opened from a closed state, but in our workflow we will make the closed state a completed state. We can set the completed state by right clicking a shape and selecting "Set As Completed State" from the context menu. Our next step is to define the events the state machine will process in each state. We will define these events using an EventDriven activity.
odetocode.com/articles/460.aspx
7/18
9/1/13
OnBugOpened represents how the state machine will react to a BugOpened event in its initial state. We cannot do much with the activity at this level of detail. We need to drill into the activity by double-clicking OnBugOpened. Double-clicking brings us to the details view of the activity shown below.
This detail view shows a "breadcrumb" navigation control along the top of the designer. The purpose of the breadcrumb is to let us know we are editing the BugFlowInitalState activity inside the BugFlow workflow. In the center of this view is a detailed view of the EventDrivenActivity we dropped inside the state. We see now the activity is a sequence activity that can hold additional child activities. There are a few restrictions, however.
odetocode.com/articles/460.aspx 8/18
9/1/13
The first activity in an EventDrivenActivity must implement the IEventActivity interface. Three activities from the base activity library meet this condition - the DelayActivity, the HandleExternalEventActivity, and the WebServiceInputActivity. All of our events come from a local communication service, so we will use a HandleExternalEventActivity to capture these signals. The picture below shows a HandleExternalEventActivity inside the OnBugOpened EventDrivenActivity. We've changed the activity's name to handleBugOpenedEvent and set its InterfaceType to reference the IBugService interface we defined earlier. Finally, we selected BugOpened as the name of the event to handle. We've done all the setup work we need to handle an event in our initial workflow state.
At this point, we could continue to add activities after the event handler. For example, we could add an activity to send notifications to team members about the new bug. The last activity we want to execute will be a SetState activity, which we cover next.
odetocode.com/articles/460.aspx
9/18
9/1/13
We can now click on the BugFlow link in the breadcrumb and return to view our state machine workflow. The designer will recognize the SetState activity we just configured and draw a line from the BugFlowInitialState shape to the BugOpenState. The workflow designer gives us a clear picture that the workflow of a bug starts in BugFlowInitialState, and moves to the BugOpenState when an incoming BugOpened event signals the official birth of a new bug.
At this point, we can continue to add event driven activities to our workflow. We need to cover all the possible events and transitions in the life of a bug. One advantage of a state machine is that we control which events are legal in specific states. For example, we never want any state other than the initial state to handle a BugOpened event. We could also design our state machine so that a bug in the deferred state will only process a BugAssigned event. The picture below shows our state machine with all the events and transitions in place.
odetocode.com/articles/460.aspx
10/18
9/1/13
Notice how the BugClosedState does not process any events. This state is the completed state, and the workflow will not process any additional events.
9/1/13
HandleExternalEvent).
E x t e r n a l D a t a E x c h a n g e S e r v i c ed a t a E x c h a n g e ; d a t a E x c h a n g e=n e wE x t e r n a l D a t a E x c h a n g e S e r v i c e ( ) ; w o r k f l o w R u n t i m e . A d d S e r v i c e ( d a t a E x c h a n g e ) ;
B u g S e r v i c eb u g S e r v i c e=n e wB u g S e r v i c e ( ) ; d a t a E x c h a n g e . A d d S e r v i c e ( b u g S e r v i c e ) ;
W o r k f l o w I n s t a n c ei n s t a n c e ; i n s t a n c e=w o r k f l o w R u n t i m e . C r e a t e W o r k f l o w ( t y p e o f ( B u g F l o w ) ) ; i n s t a n c e . S t a r t ( ) ;
By the end of the code, we have a workflow instance up and running. In this next code snippet, we will invoke methods on our bug service, which will fire events to the state machine. We've carefully arranged the events to move through all the states in the workflow and finish successfully.
B u gb u g=n e wB u g ( ) ; b u g . T i t l e=" A p p l i c a t i o nc r a s hw h i l ep r i n t i n g " ;
b u g S e r v i c e . O p e n B u g ( i n s t a n c e . I n s t a n c e I d ,b u g ) ; b u g S e r v i c e . D e f e r B u g ( i n s t a n c e . I n s t a n c e I d ,b u g ) ; b u g S e r v i c e . A s s i g n B u g ( i n s t a n c e . I n s t a n c e I d ,b u g ) ; b u g S e r v i c e . R e s o l v e B u g ( i n s t a n c e . I n s t a n c e I d ,b u g ) ; b u g S e r v i c e . C l o s e B u g ( i n s t a n c e . I n s t a n c e I d ,b u g ) ;
One of the advantages to using a state machine is that the workflow runtime will raise an exception if our application fires an event that the workflow current state doesn't handle. We can only fire the BugOpened event when the state machine is in its initial state, and we can only fire the BugResolved event when the workflow is in an assigned state. The workflow runtime will ensure our application follows the process described by the state machine. In a real bug tracking application, it may take weeks or more for a bug to reach a closed state. Fortunately, state machine workflows can take advantage of workflow services, like tracking and persistence (both described in Hosting Windows Workflow). A persistence service could save the state of our workflow and unload the instance from memory, then reload the instance when an event arrives weeks later. There is something else unusual about our example. Our application knows the state of the workflow as it fires each event. A real application might not have this intimate knowledge of the workflow. Our application might not remember the state of a two-month-old bug, in which case it won't know the legal events to fire, either. Fortunately, Windows Workflow makes this information available.
9/1/13
"Close This Bug" button when the bug is in a state that will not transition to the closed state. Instead, we want the user interface to reflect the current state of the bug and only allow the user to perform legal actions. We can do this with the help of the StateMachineWorkflowInstance class.
StateMachineWorkflowInstance
The StateMachineWorkflowInstance class provides an API for us to manage and query a state machine workflow. As shown in the class diagram below, this API includes properties we can use to fetch the current state name and find the legal transitions for the state. The class also includes a method to set the state of the state machine. Although we generally want the bug to follow the workflow we've designed in our state machine, we could use the SetState method from an administrator's override screen to put the bug back into its initial state, or to force the bug into a closed state (or any state in-between).
Let's modify our original example to call the following method. We will call this DumpWorkflow method just after calling the bug service's AssignBug method, so the workflow should be in the "Assigned" state.
p r i v a t es t a t i cv o i dD u m p S t a t e M a c h i n e ( W o r k f l o w R u n t i m er u n t i m e ,G u i di n s t a n c e I D ) { S t a t e M a c h i n e W o r k f l o w I n s t a n c ei n s t a n c e= n e wS t a t e M a c h i n e W o r k f l o w I n s t a n c e ( r u n t i m e ,i n s t a n c e I D ) ;
9/1/13
} }
This code first retrieves a workflow instance object using the workflow runtime and a workflow ID. We then print out the name of the current state of the workflow, the number of legal transitions, and the names of the legal transitions.
We can use the information above to customize the user interface. If the user were to open this particular bug in an application, we'd provide buttons to mark the bug as resolved, or defer the bug. These are the only legal transitions in the current state. Another interesting property on the StateMachineWorkflowInstance class is the StateHistory property. As you might imagine, this property can give us a list of all the states the workflow has seen. If you remember our discussion of tracking services from Hosting Windows Workflow, you might remember the tracking service does a thorough job of recording the execution history of a workflow. If you guessed that the StateHistory property would use the built-in tracking service of WF, you'd have guessed right!
We can use the classes like SqlTrackingQuery to investigate the history of our state machine, or we can use the StateMachineWorkflowInstance class and the StateHistory property to do all the work for us. Let's call the following method just before closing our bug.
p r i v a t es t a t i cv o i dD u m p H i s t o r y ( W o r k f l o w R u n t i m er u n t i m e ,G u i di n s t a n c e I D ) {
odetocode.com/articles/460.aspx 14/18
9/1/13
S t a t e M a c h i n e W o r k f l o w I n s t a n c ei n s t a n c e= n e wS t a t e M a c h i n e W o r k f l o w I n s t a n c e ( r u n t i m e ,i n s t a n c e I D ) ;
This code gives us the output shown below - a list of the states the workflow has seen, starting with the most recently visited state.
Note: we can only use the StateMachineWorkflowInstance class while the workflow is still running. Once the workflow completes, we have to fall back to the tracking service and use tracking service queries to read the history of a state machine.
odetocode.com/articles/460.aspx
15/18
9/1/13
Given this bit of information, all we need to do is add event driven activities for common events into our workflow, instead of inside each state. In figure 16, we've removed the event driven activities for the bug assigned and bug closed events from the individual states, and dropped them into the parent workflow.
You'll notice this step has reduced the complexity of our state machine a bit. In fact, the BugDefferedState and BugResolvedState activities have no event driven activities inside them at
odetocode.com/articles/460.aspx 16/18
9/1/13
all. Instead, they'll inherit the behavior of the parent and process only the OnBugAssigned and OnBugDeferred events. All the other states will inherit these event driven activities, too. Hierarchical state machines are a good fit for business exceptions, like when a customer cancels an order. If the customer cancels, we have to stop the workflow no matter the current state. With hierarchical state machines, it is important to realize that a SetState activity can only target a leaf state - that is a state with no child states.
Summary
In this chapter we've looked at state machines in Windows Workflow. State machines consist of states, events, and transitions. Windows Workflow provides all the acvtivities we need to model these constituent pieces. State machines will typically be driven by a local communication service or web service requests, and the workflow runtime services, like tracking and persistence, work alongside state machines the same way they work with sequential workflows. Finally, hierarchical state machines enable us to extract common event driven activities and place them into a parent state. By K. Scott Allen Let me know what you think of this article!
odetocode.com/articles/460.aspx
17/18
9/1/13
Tweets
Ninja Coding 30 Aug @ninjacoding C# Fundamentals - Pt 1 @pluralsight by @OdeToCode pluralsight.com/courses/csharp So good going through a second time and taking notes! C# rocks \m/,
Ninja Coding 30 Aug @ninjacoding COMPLETED C# Fundamentals - Part 2 course from @pluralsight authored by @OdeToCode pluralsight.com/courses/csharp 5 star! Thx!
Weerstation 30 Aug Brugge @poldeleeuw @OdeToCode Hi Scott, I'm taking your course mvc 4 on pluralsight. Are you working on a new course for mvc 5 at this moment? Thank you.
odetocode.com/articles/460.aspx
18/18