Hi John, Thanks for the explanation. It should suffice. But in long term, would like to consider any 'further sophisticated' mechanism than this ?
I really don't know what 'further sophisticated' mean here, but a dumb this way to understand how existing (a neat and apparently very simple) scheme would not be sufficient, I thought I would ask it to you. A couple of small doubts: * Where from the replay would begin during recovery process? * How are two instances of the same process are identified (I did not get this from journal example)? Many thanks for raising the ticket. ./harshal On Apr 12, 10:27 am, John Mettraux <[email protected]> wrote: > On Fri, Apr 10, 2009 at 11:34 PM, harshal <[email protected]> wrote: > > > Is there any reference or pointer on recovery part in case Ruote > > crashes while executing a process? > > It would be great if you could throw some light on this. > > Hello Harshal, > > It's true that there's not much documentation about this. I will > remedy to that > :http://rubyforge.org/tracker/index.php?func=detail&aid=25384&group_id... > > Here are a few hints : > > When a process operation result in an error, the engine will register > the error in its error journal and that segment of the process will > thus get stuck. You can interrogate the status of a process > programmatically via : > > process_status = engine.process_status(workflow_instance_id) > > where 'workflow_instance_id' is a string like "20090408-habujotsuni" > which is the unique process instance identifier. > > This process status holds a "errors" field which lists the errors > affecting the process instance. A sound, running, process instance has > an empty error list. > > You're supposed to be able to fix the cause of the error and then > replay at the error to let the flow resume. > > e = engine.process_status(wfid).errors.first > engine.replay_at_error(e) > > There is an old piece of documentation about error replaying at : > > http://openwferu.rubyforge.org/journal.html(the last section > "replaying journals" is still valid). > > Note that ruote-rest and ruote-web2 do expose error browsing and > replaying via their /errors resource. > > It's possible to define behaviours for segments of processes upon > error (subprocesses/participant, alternative paths that get executed > in case of errors) : > > http://openwferu.rubyforge.org/on_error.html > > Now, if the Ruby runtime in which ruote resides crashes, you should be > able to simply restart the application and ruote will simply be able > to continue his mission (provided you're using it with some kind of > persistence and provided the Ruby runtime didn't crash while ruote was > in the middle of saving some process status information). > > Best regards, > > -- > John Mettraux - http://jmettraux.wordpress.com --~--~---------~--~----~------------~-------~--~----~ you received this message because you are subscribed to the "ruote users" group. to post : send email to [email protected] to unsubscribe : send email to [email protected] more options : http://groups.google.com/group/openwferu-users?hl=en -~----------~----~----~----~------~----~------~--~---
