John, On Thu, Dec 27, 2012 at 7:03 PM, John Mettraux <[email protected]> wrote:
> > On Thu, Dec 27, 2012 at 03:29:41PM -0800, Doug Bryant wrote: > > We are investigating replacing our state_machine code into our existing > > ruote workflow. > > Hello Doug, > > to respond to the subject of your email "ruote as a statemachine > replacement", with "statemachine" in its general sense (not the gem name), > let's just say that ruote is not a state machine library. > > http://blog.engineyard.com/2011/ruote-and-flow/ > http://jmettraux.wordpress.com/2009/07/03/state-machine-workflow-engine/ > > > I was a bit loose with my definition of statemachine. Ultimately, we have an app which uses the state_machine gem. That app lives at the tail end of our workflow but was one of the first apps created for this project. Ruote was not in use at the time and we are looking at moving some of the state_machine (gem) functionality into our existing Ruote workflow. Our current usage of Ruote involves managing the workflow across ~10 individual applications. Ruote has paid big dividends here. For this particular app in question, state_machine gem is currently used in conjunction with ruote insofar that a state change triggers an event that Ruote acts upon. > > The idea is to provide a rest call to post some data and > > ask the workflow to advance to the next step If the underlying > participant > > is a storage participant, will a call to #proceed(workitem) advance to > the > > next step before that method returns? > > No, the proceed call will place the order to let the workitem resume in its > flow. It will return before the resume happens. > > > > I saw the do_not_thread=true in the > > storage participant & had a glance at the source, but could not determine > > the answer to this question with certainty. > > do_not_thread=true tells the worker to run the participant code here > immediately, in the worker thread. When do_not_thread=false (the default), > the dispatching of a workitem to a participant happens in a dedicated > thread > (the worker goes on processing the next piece of work). > > A storage participant is mostly used when a human action is expected. It's > totally OK to use other kinds of participants and let them tweak the state > of > the [business] objects. Using ruote and a state machine library together is > OK. State machine libraries are wonderful for defining object lifecycles. A > ruote workflow, most of the time, orchestrates the lifecycle of multiple > objects. > Thanks for the clarifications. That helps. > > I guess your use case is "let's place that object in state x and wait for > human y to do something about it". That can be done by extending the > storage > participant or by writing a custom participant. Just have to think clearly > about the use case. > Correct. User A changed some data so User B needs to act on that data. The data is also subject to events such as expiration. A bit more thought is required to make sure the state can be represented meaningfully if managed by Ruote. Thanks for taking the time to answer these questions. It's much appreciated. Doug > > > Happy new year, > > -- > John Mettraux - http://lambda.io/jmettraux > > -- > 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 > -- 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
