Ah... it turns out that wait_for is exactly what I want! (Just an update for the benefit of others)
Somehow I missed that you can wait_for a specific wfid, in addition to number of processes (and more). Thanks again, John. -Nic On Aug 3, 5:26 pm, Nic Young <[email protected]> wrote: > Thanks for the prompt reply, John. That makes sense. > > My concern is not regarding testing. I saw the wait_for commands being > used there, but didn't want to rely on that in production. We have > some cases where a workflow is launched (or a workitem is completed) > as the result of an in-browser action, and the response to that action > needs to present the subsequent step (these are by nature not long- > running or intensive steps in a workflow, but we do have others that > are). I can just catch the process identifier and query for it with > retires if I want to block for that request, so it's all good. > > Let me know if you think I'm embarking on something blatantly > dangerous or stupid here. > > Thanks again. > > Keep well. > > -Nic > > On Aug 2, 12:27 pm, John Mettraux <[email protected]> wrote: > > > > > > > > > On Tue, Aug 02, 2011 at 01:57:58AM -0700, Nic Young wrote: > > > > I've got a single worker using MongDbStorage and a catch_all, Storage > > > Participant, running behind ruote-kit. I've got a small, sample test > > > app running separately, which runs a very basic workflow. It accepts a > > > post, initiates the workflow with ruote-kit, and immediately asks > > > ruote-kit for any resultant workitems before redirecting according to > > > the workitem payload. It follows the same model when proceeding to > > > subsequent steps (a call to ruote-kit to proceed, followed immediately > > > by a workitem query). Mostly it works as expected, but sometimes the > > > query for resultant workitems either yields no results (when starting > > > a workflow), or yields a workitem denoting the previous step (when > > > proceeding). If I then query for workitems again then the expected one > > > appears. This leads me to believe that somewhere something is > > > happening asynchronously, and I'm querying before the process has > > > completed. > > > Hello Nic, > > > glad to read from you. > > > I plead guilty here. Ruote is fully asynchronous, from day 0. > > > When you launch a process it returns you a process identifier (a so-called > > wfid), it never returns you the "result of the process". > > > Whatever the storage you choose, you'll see that behaviour. > > > Look at the participants too, they are themselves just fat callbacks you > > wire into process definitions, they react upon incoming workitems. > > > If your code tries to act on obsolete information, the operation will just > > fail and you'll have to ask for more up-to-date information before retrying. > > > If your concern is about testing, look at the ruote test suite for some > > examples, they are using helper methods like Engine#wait_for to wait until > > some process events trigger. > > > Sorry for the confusion, cheers, > > > -- > > John Mettraux -http://lambda.io/processi -- 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
