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
