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.
Reloading the state machine instance from persistence in Tracking
Marcin Obel
Did Beta 2 Samples come with this scenario - seems like it will be a popular question!
Cristiano Muzi
G
Miketrix
Hi,
I repeat the same question than Kiwi JB:
Did Beta 2 Samples come with this scenario
This is very important.
Regards
Ignacio
Kade
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
Danz.
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
ZhangQing
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!
hfrmobile
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.
Zakary
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.
LanceT
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
JensLundberg
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
marek_matonok
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