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
