Hi John, Thank you for such a quick response! And thank you for sharing your work with all of us.
Our definition looks pretty much like what you have there, and yes the 'review' workitem makes it to the participant but we were using something ajaxy and were hoping for the 'instant gratification'... But I understand the asynchronous nature of these API calls, which is in a sense forced by the inherent latency that comes with managing large numbers of long-running processes. The project we're working on currently wants to be a "single page web app" and we're trying to line up parts of our GUI with the stages some business objects find themselves into in our Ruote workflow. In this particular case, the user clicks on a "claim" button on the GUI which triggers an ajax call to the server and causes the engine to receive a proceed call for that wi - at that point we're trying to reply with a JSON that contains the wi of the very next 'review' activity. What is a proper Ruote pattern that would allow us to achieve what we're attempting here? I am very much interested in this notion of an "inbox" participant that would merge the claim and review steps. How would we go about implementing something like this? With your guidance and the approval of my employer, I would be interested in implementing it and contributing it back to Ruote. Cheers! Patrick On Nov 14, 9:14 pm, John Mettraux <[email protected]> wrote: > On Mon, Nov 14, 2011 at 08:32:34PM -0800, Patrick Lardin wrote: > > > I have a subprocess where a task is pushed to several reviewers > > through a concurrent iterator with a count of 1 so that only one > > reviewer can 'claim' that task, followed by the actual 'review' taks > > dispatched to the person who actually claimed it first. > > Hello Patrick, > > welcome to the ruote mailing list. > > So if I understand correctly, your definition looks like: > > ---8<--- > sequence do > citerator :on => '$f:reviewers', :to => 'reviewer', :count => 1 do > participant '${f:reviewer}', :activity => 'claim' > end > participant '${f:reviewer}', :activity => 'review' > end > --->8--- > > > The problem I have is that when I tell the engine that the 'claim' > > task is complete and call the 'proceed' method for it, I need to > > return the ID of the next workitem, the one corresponding to the > > 'review' step. Is there a blocking call in the Ruote API that I could > > call to get the set of changes affecting the process once the 'claim' > > step is completed? We figure out a way to do something like that by > > calling 'process' in a loop for that wfid, but even then we still > > couldn't find the workitem in our redis storage. > > Once the claim step is completed the participant expression replies to its > parent expression, the concurrent iterator. That iterator, since count is set > to 1, will cancel other branches (reviewers) and reply to its parent > expression with the workitem from the winner, the flow then goes on (the the > review activity). Sorry, it's not instantaneous. > > Out of the box, the polling loop is the right approach. Ruote will not "run > the workflow ahead" for you, the instance could get cancelled, the workflow > got get modified. You can view the participants as hooks in the flow. > > If I understand correctly, you're telling me that the "review" workitem never > makes it to the participant ? Or is it simply that you're using something > ajaxy and you want the answer immediately ? > > Another approach would be to develop a your own "inbox" participant where you > merge claim and review, so that you don't have to poll ruote for workitems. > If you need help with that I can propose pseudo-implementations. > > Best regards, > > -- > 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
