Reloading the state machine instance from persistence in Tracking

I am trying to extend The Ordering State Machine example.

I want the form to load all persisted workflows on start up, displaying each at their current state in the list view.




I have implemented the SqlPersistenceService and the Tracking service successfully and both databases are being populated.

 


As a test I am loading a persisted workflowInstance using its GUID


WorkflowInstance CurrentInstance = theWorkflowRuntime.GetWorkflow(new System.Guid("63714370-9bd8-4ab3-9928-cc3c0b2c6696"));

            CurrentInstance.Load();

 


I have implemented the handler for the workflowLoaded event which calls LoadOrderWorkflow, which is basically the StartOrderWorkflow. I have set the statemachine as running.

 

The workflow seems to reload Ok and AddListItem adds it to the listview. 


I need to display the current state of the workflow, using update list. I imagine I have to rebuild the statemachine from its persisted state and raise an event with an ActivityEventArgs parameter with the QualifiedId set to the current state.

Is this right or is there a simpler method I have missed

Thanks for your help. I am very glad you included the state machine design option.

 

 

 

 




Answer this question

Reloading the state machine instance from persistence in Tracking

  • Pejsa Ballistics

    hi Andrew,
    I'm also working in the same path so as to retain the state machine after host has been restarted. and also i'm working on ASP.NET. it will be of great help if you can send any implementation of the above problem either in windows forms or asp.net implementation

    Thanks,
    sreepada
    sripad99@hotmail.com

  • LukeParker

    Andrew,

    You have the right aproach.  When you're loading the workflow again, be aware that WorkflowLoaded could get called multiple times, and so you should make sure that your list doesn't already have the instance before adding it.  I think you're probably already doing this, but I thought I'd point it out as well.

    To show the current state of the workflow, the Ordering State Machine sample has a StateMachineInstance helper class that exposes properties like the current state.  However, because this relies on tracking, I don't think you will be able to get the currently executing state after the host is restarted.  This is because the 'executing' tracking event would have already been delivered before the host was shutdown.  When the host restarts, the StateMachineInstance would need to be recreated from persisted tracking information, which is not done in the sample.

    In Beta2, the state machine workflow instance class will contain properties and methods that query the runtime and don't rely on tracking - which should make the implementation of the scenario a lot simpler!

    Arjun

  • reklis

    Hi,Andrew,
    I want to realize the same purpose ,but I can't find a good way to do this,Can you send your examples to me
    zhao_yuguang@hotmail.com
    thanks.

  • tyu

    I'm storing the current state in a local variable on the base state machine class. Then I added a global event handler on the base workflow that handles the GetLastState event from the hosting service through an ExternalDataExchangeService. This way when I reload a persisted workflow I know where I was at last time I ran it.

    G


  • Jorg Jooss

    Thanks Arjun,

    It has since occured to me that the best solution might be to store the current state of the workflow in an Order object. The order object could be saved in the state changed handler and a set of order objects could be reloaded at start up. I also wonder if the order id could not be the workflow instanceId, as the workflow is really an order object rendered as its possible states

    Would making the id's the same cause problems in the event sinks when events are raised with order id's which match the worflow instance

    I ask this because I imagine there will be many occasions when the workflow is just an object rendered as states.



  • sarmistead

    Andrew,

    You shouldn't have a problem making the instance ids the same as the order ids - as you mentioned, the workflow instance really is the order represented in of its comopnent states.  However, I don't think I followed when you said that the set of order objects could be reloaded at startup.  You can reload all the existing instances into memory at application startup, but in Beta1, you'll still need a way to query execution state (as I mentioned in the last post).

    Arjun

  • sined nivuach

    hi Andrew,

    I'm working on asp.net. My problem is like this question, and my workflow is sequence. If the host is restarted or IIS is restarted, how can i get the previous workflowinstance and it's state


    Thanks
    hncshxf@hotmail.com



  • LongTom

    Hi,

    I repeat the same question than Kiwi JB:

    Did Beta 2 Samples come with this scenario

    This is very important.

    Regards

    Ignacio


  • Tom Gillespie

    Hi Arjun,

    I am also working on a similar scenario as Andrew, My problem is when the application is reloaded I am able to get the instances from the DB and I couldnt figure out the way how to load those into the statemachine as it needs to be rebuilt again.

    I am begineer, so any help would be of great use to me

    thanks in advance

    Bala


  • Andreas Kranister

    My plan was to save the value of the QualifiedID as passed to the handler of the change state event ( the QualifiedID in the example is the name of the state the workflow has just changed to). The state name would be saved as a member of the Order object which would be persisted when the application was closed down. On startup the application would reload all the order objects and then load each workflow in turn, displaying the value of this member in the list as  the current state. (There is one workflow per order.)

    This is really to get around querying the execution state of the workflow. It is based on the assumption that in the example, the new state is received at the change state handler and the application is the only means of changing the state.  Therefore saving the value of the QualifiedID at the change state event would be the equivelent of querying the workflow for its current state, because we know the state will persist until the next change state event occurs and the application has been closed down, so no state change could have taken place. Of course if the state machine were moved on by some other application then this wouldn't work.

    In fact I agree, it isn't a very good solution to the problem. I am looking forward to seeing how you query the current state in Beta2!

      



  • DMM-e

    Hi,
    Did Beta 2 Samples come with this scenario - seems like it will be a popular question!



  • Reloading the state machine instance from persistence in Tracking