locked
State class is not inheritable in WF4 RRS feed

  • Question

  • Before we moved to WF4, we were planning (in WF3.5) to create sub-classes of the state class, and then to make only these classes available to the workflow designer (using our own version of the out-of-VS designer).  My developers were telling me that this was all OK, but now isn't possible in WF4, because the state is not-inheritable.

    We had this requirement because there a few key activities that have to be carried out when a state is entered for our application to work. (e.g. we assign an owner to the entity based on the state entered.)  Our application also has types of states which will always have some other rules and state entry activities enforced.  Again, we would have used a sub-class to make these type of states available in the designer, simplifying the design proces.

    As it stands, we now have to place more emphasis on the designer to assign this characteristics to the state.

    Any ideas on this one?  Am I missing something about WF4 that deals with this problem another way?

    Sean

    Friday, July 29, 2011 9:32 AM

Answers

  • Hi, Sean

    WF3/3.5 still works in .NET 4.0. if most of your workflow are already defined as WF3/3.5 state machine. you can reuse these workflows.
    You can use Interop activity in WF4 to run WF3/3.5 workflows.

    Regards
    MSDN Community Support
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    This posting is provided "AS IS" with no warranties, and confers no rights. My Blog: http://xhinker.com
    Microsoft Windows Workflow Foundation 4.0 Cookbook
    • Marked as answer by Andrew_Zhu Friday, August 5, 2011 2:59 AM
    Wednesday, August 3, 2011 6:33 AM

All replies

  • Hi, Sean

    WF3/3.5 still works in .NET 4.0. if most of your workflow are already defined as WF3/3.5 state machine. you can reuse these workflows.
    You can use Interop activity in WF4 to run WF3/3.5 workflows.

    Regards
    MSDN Community Support
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    This posting is provided "AS IS" with no warranties, and confers no rights. My Blog: http://xhinker.com
    Microsoft Windows Workflow Foundation 4.0 Cookbook
    • Marked as answer by Andrew_Zhu Friday, August 5, 2011 2:59 AM
    Wednesday, August 3, 2011 6:33 AM
  • Hi Andrew,

    We need to use WF4 because of the much improved tracking. (In particular, how easy it is now to track custom information.)  In fact, we're using it now - no going back.  My developers are telling me that it is much better in every other respect other than this issue with not being able to inherit the state.

    We'll work around it - but I was wondering why it has been done and what suggested workarounds might be.

    Regards

    Sean

     

    Monday, August 8, 2011 1:09 PM
  • I agree with you, I love the WF 4.0, it clearly defined the boundaries for WF app developer, so that we can not mess around too much. 
    ahorse
    Monday, August 8, 2011 6:01 PM
  • Usually, I would recommend that you use "IActivityTemplateFactory" to solve this.

    However, the problem with IATF is that it returns an Activity; however, StateMachine would only accept State.  So you cannot drag a custom state to the StateMachine canvas.

    In Dev10 PU1, assuming that you're using rehost, then you can add a "Composite State" by adding via the ModelItem.

    In Dev11, we would have a much more flexible way for you to add your own "Composite State" in StateMachine.  In the meanwhile, let's see if this can help you:http://blogs.msdn.com/b/isaacy/archive/2011/08/15/defining-composite-state-in-wf4-statemachine.aspx

     

    Monday, August 15, 2011 10:00 AM
  • Hi Isaac,

    Thank you for your response -very informative and useful

    The bracketed paragraph in the blog post describes our situation.  I'm a bit surprised that it appears to be considered a bit exceptional.  I would have thought that one of the main aims of a workflow solution would be to allow non-programmers to amend business logic, and then to do so with restrictions applied and as little complexity visible to them as possible.  Maybe that's just from my view of it.  Anyway, it looks like you are going to address it in the next release, so I can't ask for more than that.

    Thanks for the example showing how to use the ModelItem level.  It would guess that it has the drawback that the extended properties of the "CompositeState" are visible and can be amended, which could create a support nightmare.  However, we'll probably go ahead with this and wait to see what VS<next> brings.

    Regards

    Sean

     

    Wednesday, August 17, 2011 12:51 PM