Pravin Indurkar

Hello From TechED Boston

pravini — Tue, 13 Jun 2006 17:48:00 GMT

Hello From TechEd Boston. Just did my Talk on State Machine Workflows. It was great to talk about State Machine Workflows and get good feedback. It is exciting to see people using WF and State Machine Workflows in particular. I would like to hear more about the patterns people are implementing using State Machine workflows. One of the things we want to achieve is support for commonly occuring patterns within the foundatuion.

A lot of people asked me about slides and whether they will be online. I will be posting my slides for people to use as soon as I get good bandwidth to upload my presentation.

Cheers from Boston !!!

P.S. -- The Slides that I used at the PDC have now been uploaded

Recursive Composition Of States : A way to inherit behaviors in State Machine Workflow

pravini — Mon, 03 Oct 2005 00:55:00 GMT

One of the most powerful features in the state machine workflow is recursive composition of states. Much of the flexibility in modeling that the state machine offers comes from the recursive composition feature.

In certain processes there are requirements where certain events can happen any time. For example in a purchase order process the purchase order can be canceled any time or the change event can happen only when the PO is in the opened state or the PO is in the approved state but not shipped. Modeling such events can become challenging. One option can be to model the same event in every state where the event can occur. But that is a lot of repetition of the same behavior. What we want is a behavior similar to what is provided in Object inheritance. We need to provide the common behavior in some base class and then have that behavior inherited in all the other derived classes.

Recursive composition offers a very elegant solution to this problem. In recursive composition model a state activity can contain other state activities. Any event handlers that are attached to the container state are inherited by the contained states. The state machine workflow root activity is also a state activity so if any event handlers are attached to the root state machine workflow then they are inherited by all the states within the state machine. If you look at it closely it is very similar to object inheritance. The behaviors to be inherited is the behavior in the event handlers.

So now to model the Cancel event in the PO example all we need to do is to simply attach the Cancel event handler at the root state machine activity. To model the Change event we need to create a State and include the Opened and the Approved state in it. Now we can attach the change event handler to the state the we have created.

Consider another example of an interactive voice response (IVR) application. In that application you need to create a menu system to which the end user will respond to over the phone. Now in it you can have options like 'At any time Press 9 to go to the main menu' or 'At any time press * to end the phone conversation'. You can now model these as events attached to the root state machine workflow. You do not have to provide for them in every state. In some cases you can have a certain set of sub-menu's grouped to provide functionality like 'press 8 to go back to the previous menu'. All these functions can now be performed very easily.

Another cool thing that is offered is that in some cases you can override the default behavior that you may have provided in the event handler of a container state. For example in the case of handling the 'Cancel' event in the PO process we simply added the 'Cancel' event handler at the root state machine level. Now let us say you want to override that behavior in the 'PO Approved' state. May be we want to handle the 'Cancel' differently when the PO is approved. We can add an event handler in the PO approved state to handle the 'Cancel' event and provide the special processing that we want to. Now while executing this state machine the Cancel behavior we have provided at the root level will be overridden by the 'Cancel' event handler in the PO Approved state. This is similar to overriding methods in Type inheritance.

The recursive composition model is similar to the State and Sub State concept in UML. There are certain restrictions in the State Machine Workflow though. In a State machine workflow you cannot transition to the state that contains other states. This is simply to avoid the ambiguity of the current executing state. If a transition to the container state is allowed then it is difficult to figure out which one of the states inside that state was the intended current state. It is of course possible if we have some sort of rules on the container states that can direct to the right state. This is similar to embedding a state machine inside another. We do not allow that yet and when we do that we can allow the flexibility to transition to the container state.

The designer also provides great support for recursive state composition. All you need to do is simply drop a state in another state. You can then drop event handler at the container state level. That's it. You do not have to do anything else for the inheritance to work.

Try this out in your process models. It is a great feature available and you will find that your process models are not only able to handle very complex requirements but are very elegant and easy to maintain.

Why State Machine Workflows

pravini — Mon, 26 Sep 2005 05:26:00 GMT

Many people I have talked to have asked me why was there a need for state machine style of workflows. Here I am trying to put down some of my thoughts for the reasons why we felt the need for having the state machine style of workflows in Windows Workflow Foundation.

If you look generally at the business process landscape you will find that end user requirements have changed. They are no longer satisfied with simple business process automation. They want much more than automation. In my experience there are 3 main categories of requirements.

Flexibility
Visibility
Control

Flexibility

Businesses today need to be agile and the business processes that they use constantly change to keep pace with the demands of their customers. Moreover for small businesses to compete their ability to be agile in responding to customer needs is what distinguishes them from their bigger competitors. Thus there is a need to create business processes that are flexible and accommodate a variety of situations. Often the business processes contain a prescribed path to the end goal but then there are a lot of alternate ways the same goal can be achieved. For example a Purchase order can contain a prescribed path where the PO goes from being create to approved to shipped to completed. But then there a multitude of other ways in which the PO can be completed. The PO can get changed, or back ordered or canceled and then ReOpened. All these paths must be accounted for. Just to put things in perspective. We did a study of the purchase order process of a small business and found that there was one traditional order fulfillment path but then there were about 65 different variations on the same process depending on the nature of the order. Trying to hardwire such a large number of alternate paths is not only difficult it is almost impossible. Traditionally there are two ways in which this was dealt with. Either the business process was hard wired to accommodate all the paths, making the implementation of the business process extremely complex, brittle and hard to maintain. In the other way the alternate paths are simply not dealt with and any situation of the ordinary was dealt outside the domain of the process. When dealt outside the process all the benefits like tracking, visibility etc were lost. Most often people create manual systems to track such out of the ordinary situations.

State machine workflows provide an easy way to create these complex business processes easily. In a state machine the idea is not to hardwire the different paths a process can take but rather to simply account for all the possibilities. The way you do it is by providing event handlers for each of the external events that can influence the process. Within each event handler you can put logic to respond to that event. You can then group the event handlers into logical states of the process. Each state corresponding a to a milestone in the process.

Visibility

In a connected world the ability to provide visibility into a business process to your partners and customers is a very important competitive advantage. It also helps a business internally to measure key performance indicators and help in continuous improvement.

Once you have implemented your process the most important thing to do is to provide visibility into the running instance of the process. Without providing that visibility the process will be pretty much useless. In a lot of cases business processes are specifically built with visualization in mind. In some cases a whole layer is built to simply interpret the running instance of the process and provide visibility. All these approaches are fine but when you consider a flexible process which is changing frequently, the interpretive layer would have to change frequently too to make sure that the visualization is in sync. Also the knowledge of the business process is duplicated, once in the visualization layer and one in the process execution layer. This is not a very desirable way to build business systems.

Another important reason for providing visualization is to make sure that the users who are interacting with the process have all the right context to take any actions they want to. An ideal visualization must provide information about the past steps in the process, the current context and some information about the likely future. A business process must be built so that all these three aspects (providing the past, present and the future) are easily possible.

State machine workflows offer a very nice and effective way to query the process. Moreover there is no interpretive layer that needs to be built around it. The current state of the business process is the current state of the state machine. You can figure out the past steps by simply looking at the states the process has been through. In order to figure out the future you simply have to find out the possible events that can be received in a state and the possible transition from the current state. As you can see the amount of work that needs to be done to provide information is not much. The information about the process need not be duplicated in a visualization layer. You can see the order processing state machine example or the Interactive voice response application that are available for download. The entire Visualization layer is completely agnostic of the process. If any change is made to the process there is no need to change the UI it can simply query for the structure of the new process.

Control

Control almost seems paradoxical when we just talked about flexibility. The control we are talking here is the ability of the end user to control a running instance of the process. For instance think of the PO process where the PO process owner wants to skip the approval step. Or may be a PO is important enough where an additional approval is required for which the approval step needs to be repeated. Such type of interaction patterns require a kind of control that the end user must have on the execution of the process.

State machine workflows provide you the ability to control the execution. A user can skip a state or jump to any other state in the process. Trying to provide this kind of control in a sequential workflows would mean hardwiring those paths in the process. But again that would mean that the flexibility is lost.

Overall State machine workflows provide a very easy to use and useful paradigm. Also it is not something new that you have to learn. State Machine have been in use since the advent of computing and all of us have used them. Even in doing business process analysis all of us have drawn a state machine of the process on paper and then implemented it in code. What we offer in Windows Workflow Foundation is not only a way to create those state machines in Visual Studio but also a way to execute them.

Windows Workflow Foundation Announced

pravini — Fri, 16 Sep 2005 11:26:00 GMT

It was great to finally have Windows Workflow Foundation announced. I personally could'nt wait to tell the story to the rest of the world. Judging from the responses from the attendees at the PDC WWF has created quite a buzz. I think this is just the start. The goal is to get people to start writing business applications in a new way. A process centric way of creation of business applications where the applications can evolve much faster to meet the changing needs of the business. As the business rules change the only thing that needs to change is the process definition. The rest of the application should remain the same. This will reduce deployment costs, downtime for the applications. Customization of these applictions can be very easy.

Personally the session on State Machine workflows that I delivered was a long awaited event. For 3 years (it seems a lot longer) I along with some collegues of mine have been working on the state machine workflow model and it was great to finally share our ideas with the rest of the world. I especially would like to thank Marcelo Uemura for all the hard work that he has put in into making this a reality. Marcelo, I owe it to you buddy !! without you this won't have been possible. It was a long journey to evalgelize the state machine model but finally we did succeed in making this a reality. We still need work to make sure we can make the state machine workflow model super wasy to use but I think we have made a good start