That sounds like our application, if I understand you correctly - the user completes a work item and as a result you want the user presented with further work items in "real time" from a single page app. We do this using websockets (specifically pusherapp.com) and backbone.js. Ruote publishes all work items to an AMQP participant. Our application takes these into it's own database and broadcasts the new work item(s) via websockets which our single page app subscribes to and updates the UI for the user. It is not instantaneous but close enough and flows quite well with no post backs and no polling required. We are having latency issues under load but I think they are inherent to our own environment and we are close to resolving them. The asynchronous nature of ruote is not well suited to typical web request / response (in my opinion) but websockets or equivalent allows for a event based approach that is very natural.
Thanks, Nathan Stults On Nov 14, 2011, at 10:06 PM, "Patrick Lardin" <[email protected]> wrote: > 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 -- 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
