Feedback on state machine migration RRS feed

  • General discussion

  • Hi folks,

    In order to help migrate WF customers from .Net 3.X to .Net 4 Beta1, our team has posted a set of migration documents over here. Please give them a read and provide any feedback you have on state machine migration over on this thread.

    Thanks in advance for trying .Net 4, and we're looking forward to your feedback.

    -Yavor Georgiev
    Program Manager, Connected Framework
    Friday, June 5, 2009 5:10 PM

All replies

  • Thank you for this document.  I really appreciate you taking the time to give this deeper insight into the rationale for the omission of a built in state machine activity.  I had previously evaluated using the WF3 state machine workflow for some of my application scenarios and in my cases it was not a good fit - it was hard for me to model a single set of finite states that mapped well to the conceptual workflow that involved multiple parties and multiple values all part of one big workflow.  For me the new flowchart activites feel like a much better fit for what I am trying to model.  For example I will likely use the technique described in the document of having the currentState variable and a unique place that listens for every possible event.  When I was modeling my process using WF3 state machine I found myself adding event handlers to the root activity or the same event handler to multiple states anyway so in my case the single place to switch on an event is more natural anyway.  Plus in the {flowchart switch/current state} technique I can have a richer expression of current state beyond a single value - for example I may have 3 independent variables each of which may have n values and I think it will be more clear to have a switch with an expression of something like {(currentStateA=x or currentStateB = y) and currentStateC =0} than it would be if I had to model that using a single state for each combination in WF3.

    Plus in my case my workflows are intended to model some real world business processes that have been defined by human users, and in most cases the way those users will communicate their processes will be via a flowchart anyway - so the use of a flowchart is just going to map more naturally to what my users are trying to express.  In all of the workflow scenarios that my users have proposed so far no one has ever provided me with a state machine diagram.  I know that the state machine migration document offers the stopwatch example as a case where maybe the state machine does map more naturally - but to me WF is not about implementing stopwatch logic (or even something like the automated touch tone phone response like in the WF3 SDK samples that uses a state machine).  My general purpose .Net languages give me plenty of ways to implement those simple scenarios - the thing I look to WF for is specifically for those human workflow solutions involving multiple steps with multiple parties executing over a long time.  And I'm not sure that the state machine workflow was a good fit for those anyway.

    I have to say that the more I read about WF4 the more excited I become about what this is going to let me accomplish in my applications.  Frankly I've been scratching my head at WF3 and having a very hard time buying into it's implemenation - but with WF4 I'm having the exact opposite reaction.  Please keep the documentation, migration guides, and samples coming.
    Friday, June 5, 2009 9:12 PM
  • Hi PaulG, I'm glad to hear about your positive experience with WF4 and our migration doc.

    Tuesday, June 9, 2009 9:29 PM
  • Hi,

    We are using WF3 state machine workflows extensively (about 200 workflows are defined so far) in order to represent the natural states of a transaction (created -> checked for risk, approved, executed, batched, settled, etc.). On the eventing side, I can say that we have both events which are applicable only for a certain state or for a set of states (then we have to configure the event several times) and that we always check if a certain "action" is applicable for a certain transaction state (this is exposed even over the service interface as a separate method). The workflow designer is used by non-developers to configure new or modify existing state machine workflows, as well as for documentation/presentation purposes.

    Having mentioned that, I seem to be very much surprised and disappointed by the news that there is no State Workflow activity in WF4. It seems that some specific cases can be covered with the FlowChart activity or with nested while/pick/switch activities and global handling of states, but if we take this for a normal transaction state machine it will result in an extremely messed-up graphical presentation which can be "sold" neither to developer nor to non-technical people.

    In case I need to implement custom StateMachineWorkflowActivity, StateActivity, StateInitializationActivity, EventDrivenActivity and SetStateActivity - will there be ***any*** guidance on that from Microsoft or I am left on my own?

    I have to read the document on again because I have the feeling I have missed the answer to the question - "Why was StateMachineWorkflow dropped out of WF4 even though it was recognized that some processes ***much more*** naturally map to a state machine?" ...

    Thanks in advance and br,
    Deyan Petrov
    Friday, June 12, 2009 8:03 AM
  • Deyan-

    First of all, you should definitely not interpret the planned lack of a StateMachine Activity in .NET 4.0 as a long term value judgement on the StateMachine or a long term plan to not support such an orchestration style.  We plan to provide a rich eco-system of activities in the years to come and State Machine is at the top of the list.  The lack of StateMachine in .NET 4.0 is only a statement on that release.

    To specifically answer your question, "Why was StateMachineWorkflow dropped out of WF4 .... ".  When you release any very large product like .NET 4 there is a trade off between getting the new product to customers so they can start using it, and waiting to add more features in.   We feel that the value we are adding with the new WF runtime and the modeling styles we have is very compelling and we wanted to get this to customers as soon as possible so they could start taking advantage of this value prop.  It was a very hard decsion but it was determined that the earlier time to market for the product out-weighed the StateMachine activity.  That said, we have gotten strong feedback on the value of the StateMachine activity from a number of customers. 

    Bob-- WF Team.
    Sunday, June 14, 2009 6:16 AM
  • I have found the WF 4 migration guidance very helpful. Having backwards runtime support for WF 3/3.5 w/o breaking changes seems to be the most understated point for state machine questions. I think the default understanding is that since WF 4 does not include an activity for a state machine it must be a breaking change. I guess the development communtiy has got used to the idea that each new major version usually means breaking changes backwards. I am glad the WF 4 migration doc clearly outlines that not all is lost by using WF 3/3.5 on WF 4.

    Conceptually, the WF 4 Interop activity actually feels alot like the WPF WindowsFormsHost so I am glad there is something to relate to. The WF 4 doc could draw this out more as a similar migration path.

    I would like to see tooling support like a .NET upgrade project wizard - this would alleviate a lot of the anxiety about breaking changes. 


    If this answers your question, please use the "Answer" button to say so | Ben Cline
    Monday, June 15, 2009 6:20 PM
  • Will there be a migration path for long running state machine i.e. if I have a bunch of state machines that run in .NET 3.5 and then later one day I would like to upgrade to .NET 4.0.
    - What do I need to concern in term of binary compatibility since they must be persisted in DB?
    - How do I manage the transition to make it as painless as possible? 
    - I'm going to start using WF in my project. Should I wait for .NET 4.0 or start with .NET 3.5 for this WF?
    - When will Microsoft start supporting .NET 4.0? Any plan for go-live support?
    - In the document, you mentioned "2. Waiting: You can wait for a subsequent WF release that contains a StateMachine implementation out of the box. ". Is there any specific timeline or version for that?
    • Edited by Nat Tuesday, June 23, 2009 12:08 AM
    Monday, June 22, 2009 11:46 PM
  • Our business proccess requires multiple active states at the moment.
    Do you think to provide such kind functionality in the WF 4.0 StateMachine of Flowchart?

    Friday, July 3, 2009 1:20 PM
  • Will there be a migration path for long running state machine i.e. if I have a bunch of state machines that run in .NET 3.5 and then later one day I would like to upgrade to .NET 4.0.
    - What do I need to concern in term of binary compatibility since they must be persisted in DB?
    - How do I manage the transition to make it as painless as possible? 
    - I'm going to start using WF in my project. Should I wait for .NET 4.0 or start with .NET 3.5 for this WF?
    - When will Microsoft start supporting .NET 4.0? Any plan for go-live support?
    - In the document, you mentioned "2. Waiting: You can wait for a subsequent WF release that contains a StateMachine implementation out of the box. ". Is there any specific timeline or version for that?

    Hi Nat - regarding your questions:
    Transition: You also have the option of running your WF3 workflows and WF4 workflows side-by-side. This would allow your workflow instances to be hydrated and executed in the workflow definition/runtime that they were designed to run in.

    Which version to use: Particularly because this is being asked in a state machine thread, I would urge you to look at the capabilities and features of WF3 and WF4 and decide which one best fits your needs - and start with that version of WF. I hope that you find WF4 compelling to adopt, but completely understand if timing or the need for a full state machine is a requirement for your project.

    Go Live support: Typically, you can get a Go Live license with the release of a product's Beta 2. I would predict that is the same case for .NET 4, but I will defer to someone more in the know on that point. In the meantime, Microsoft is currently supporting .NET 4 via more informal channels (these forums, on blogs, and via your local DPE rep).

    State Machine timeline: Bob's comment above is probably your best guide for that. As Bob says (and Bob is the Product Unit Manager for WCF and WF), "The lack of StateMachine in .NET 4.0 is only a statement on that release." It's a high priority feature.
    Monday, July 27, 2009 10:05 PM
  • Hi Yavor,

    I was disappointed by the clumsy design of WF 3.5 etc. and had decided not to recommend it to my company. A new start with WF 4.0 had me eager to try it.  

    I have been looking high and low for books on WF 4.0 but they are just not available. I am beginning to see why.

    You just don't do Business Process Modelling without state machines.  Also, state machines are easiest way to program reactive systems by a country mile.

    What a disappointment that thay are not in WF 4.0, especially as they are fully specified by UML.

    Flowcharts are fine for systems but you need state machines for objects/classes.

    Tony Rogan

    ps my company needed to model the states of a pinpad and I have a nice UML statechart for this which I would loved to have used WF4 for. Pity I can't seem to attach a document to the forum as I would really have liked to know how I go about programming this in WF4 especially the super states and concurrent states.
    • Edited by trogan Wednesday, August 5, 2009 9:55 AM Update
    Wednesday, August 5, 2009 8:42 AM
  • Hi Trogan,

    Expect to see books on WF 4 next calendar year as start coming up on RTM. There are a WF 4 books in the pipeline with several publishers, but folks are very hesitent to publish books on beta technologies - they typically don't sell well enough to recoup costs and it typically leaves excess copies in circulation long after the final bits are released (for example, the original WF Beta 2 book still shows up among the top 15 WF books sold by Amazon even today!).

    As for state machines, we definitely value your feedback on features that didn't make it into .NET 4 - as it helps us prioritize features post-release; thanks for posting on the topic! For attaching documents, you can always post the document up to a website (or some place like the Live SkyDrive) and link to it from here. It's always helpful to know more about the processes that folks want to use WF to model.

    Again - thanks,
    Wednesday, August 26, 2009 10:12 PM
  • For simple state machines the migration doc will work.  However, for real life state machines I find hierarchial state machines that utilize the Chain of Responsibility pattern to be the most useful and resilient in the face of change.  In other words, a state machine that will handle its events or pass to its containing state machine.  Asynchronous events and long running processes are part and parcel of this and, of course, add to the complexity of implementing it as part of a framework.

    Monday, December 7, 2009 11:49 PM
  • My vote is to definitely have support for StateMachine in WF4. The stopwatch example in the guidance document should be enough to persuade anyone of that. The WF4 implementation is way more complex and it's a very simple set of interactions. We have a workflow which has nine states (all of which represent human activities that could take days to complete) and 11 transitions. WF3 allowed us to model this in a very intuitive way.
    Saturday, December 12, 2009 8:15 PM
  • I have given input with others on this in the past here:

    Basically there are some very powerful advantages to being able to hierarchially compose state machines.
    I gives you a way to control complexity.  While it may seem odd, using a statemachine to control UI/interaction flow is where I believe this really shines.

    Please consider what was written in my previous forum post.
    Tuesday, January 12, 2010 4:29 PM
  • I too feel that State Machine support should be added back into WF. This is a very powerful concept that we make use of extensively where I work and we have developed several WF state machine flows in 3.5. I believe there is also a very good use for flowchart workflows as well, but please add state mahine flows back in.

    Thursday, January 21, 2010 6:11 PM
  • Hello!

    I think the migration document is bringing good help however everything is plain obvious as you get a bit used to Workflow Foundation 4.0.

    I think you should re-introduce the concept of a state machine, but:
    1) It should be faithfully implementing the semantics of UML state machines and for instance not claim that both activities and actions are actually activities. No, actions conceptually happen discretely which is not the case with activities and it's an inappropriate generalization to claim differently. Therefore conditions should also be supported like in UML. If these things are not implemented, i.e. it's not a state machine in the UML sense, there'll be a need to to compensatory work over and over again.
    2) You should be able to mix state machines with other activities as well so for instance a FlowStep could be a state machine and an activity or an action could be/contain a flow chart etc.

    Best regards,

    Henrik Dahl
    Thursday, January 21, 2010 9:57 PM
  • Another vote for getting the state machine back in 4. We use them a lot and were really looking forward to some of the improvements we had read about WF in .NET 4. I didn't know that SM was being dropped until I was just doing some experimentation in the VS2010 RC and couldn't find the SM. To say we're bummed is an understatement. I read the guidance docs for migration and it's clear that flowcharts won't cut it. We use a lot of nesting and events are for the most-part applicable only to specific states. The biggest let-down is that the major problems we have with the 3.5 SM won't be addressed, though perhaps we can hope for a future version of SM in 4.x that will.

    Pain points in WF3.5:
    1. Designer slowness. It should not take me 15 minutes to hook up one event. Clicking a dropdown and waiting 30-40 seconds for it to populate is inexcusable. This occurs with any non-trivial workflows. (oh, and I have an i7, it's not my box that's slow).
    2. Designer forgetfullness. The designer should remember how I have things layed out (including arcs) and not mess with them. I can't tell you how many times I've had states show up completely off-screen and had to use the outline view to get to them.
    3. Update scenario. We use lots of long-running (months) workflows. We need to be able to change workflows and have those running instances update as well. We have had to resort to destroying the workflow and rebuilding it and forcing it to the proper state. The new persistence options in WF4 sounded like a good solution, pitty we can't make use of them.
    4. Global namespace... ugh. I understand WF4 may fix this.
    5. Printing support is dismal. I'd like to be able to fit my diagrams to a page and print them. Requires #2 to be useful.

    I'm sure there's more, but that's what I can remember at the moment.
    Thursday, February 11, 2010 10:20 PM
  • I really do hope the state machine can be included in a future release of WF4.  I have used state machines extensively in recent implementations, SharePoint developments and non-SharePoint. 


    One implementation that stands out, is an order processing system that involves two state machines controlling the internal states of customer orders and corresponding supplier purchase order(s).  On any given day there are over 10000 orders being hydrated and rehydrated to process updates received via the UI to manage issues and external facing services to process updates from suppliers. During the evening the workflow timers kick in and awaken each order in a given state to check SLA measurements and raise issues accordingly.

    To me the state machine provides a clear, concise and maintainable design.  Ok there are some performance issues in the state machine but you can work around some of these, for example, I always use a custom activity as the first allowed activity in a SM event.  This also allows work to be shared out more easily as another developer can open a custom activity without the state machine being checked out.


    Thursday, March 25, 2010 11:49 AM
  • Hi all,

    Visual Studio is yete at RC state, i don't think we can really hope new breaking change.

    I forgot the idea to migrate my WF3 state machines to WF4. I love the new flow charts and i think it is a more easy way to do something like state machine.


    Jérémy Jeanson MCP http://blogs.codes-sources.com/JeremyJeanson/ (French or English Spoken)
    Thursday, March 25, 2010 2:44 PM
  • Having read the features of WF 4, my IT department has decided not to upgrade to WF 4 until it supports the state machine, which is the only reason we adopted WF so far for our systems.

    Following features are found not readily provided by WF4 as in WF3

    - Provide valid events at each state such that the UI can enable/disable particular functions that trigger the events.

    - In the data migration of legacy system, it is required to create workflows and force them to intermediate states because we are not building a brand new system.

    - It is not trivial to map the object state diagram designed in UML to the flowchart in WF 4. It generates unnecessary discerpancies among design and implementation that renders difficulty in software maintenance afterwards. 

    Thursday, April 8, 2010 12:45 PM


    We have released a codeplex project which supports State Machine Activities on the WF shipped in .NET 4 (WF4). 

    You can download them here:  http://wf.codeplex.com/releases/view/43586

    Please feel free to send feedback on the CodePlex project.


    Bob Dimpsey

    Product Unit Manager, Application Server Developer Platform. 

    Monday, July 5, 2010 7:04 PM
  • Will there be a migration path for long running state machine i.e. if I have a bunch of state machines that run in .NET 3.5 and then later one day I would like to upgrade to .NET 4.0.
    - What do I need to concern in term of binary compatibility since they must be persisted in DB?
    - How do I manage the transition to make it as painless as possible? 
    - I'm going to start using WF in my project. Should I wait for .NET 4.0 or start with .NET 3.5 for this WF?
    - When will Microsoft start supporting .NET 4.0? Any plan for go-live support?
    - In the document, you mentioned "2. Waiting: You can wait for a subsequent WF release that contains a StateMachine implementation out of the box. ". Is there any specific timeline or version for that?

    It is exactly what I need, Now I got it, It's very valuable, Thanks for your analysis!
    Monday, September 6, 2010 4:46 AM
  • Hi,

    I am an Application Development Manager with a top US bank We have used State Machine workflows to handle our Loan Modification and Foreclosure workflows  and have spent considerable money and resources to have this  up and running succesfully. We are very disappointed with Microsoft decision to  drop State Activity from WWF 4.0. This has forced us to evaluate WebSphere MQ Workflow  and will have to convert our existing workflows to the new platform. I believe this will impact big enterprises adopting WWF due to the unpredictable road map.

    Wednesday, November 17, 2010 7:29 PM
  • Windows Workflow Foundation - WF Migration Kit CTP 2 Released

    For those of you migrating your WF3 State Machine to WF4 I'm happy to announce that the WF Migration Kit tool now supports State Machine migrations as well.

    Sr. Program Manager, AppFabric Development Platform (WF/WCF) http://blogs.msdn.com/rjacobs http://www.twitter.com/ronljacobs
    Tuesday, August 2, 2011 5:58 PM
  • Thank you Ron for this good news!

    I relayed it to french users ;)


    Jérémy Jeanson MVP, MCP, MCTS http://blogs.codes-sources.com/JeremyJeanson/ (French or English spoken)
    Wednesday, August 3, 2011 7:43 AM