On Tue, Apr 20, 2010 at 6:09 PM, Olle <[email protected]> wrote: >> >> OK. If the participant is in charge of handing the workitem to the >> "external participant" and fetching back the answer, all from its >> consume method, then you have an on_reply, already. Easy. >> >> If the workitem comes back to the engine via a listener, should I >> re-instantiate the participant and trigger its on_reply ? > > Yes. It's exactly my case. There is an external service, which > receives task results from CMS and puts it into ruote (it does POST > _ruote/engine/reply?merge_workitem currently). > > participant.on_reply method needs to receive workitem and be able to > change it. If such approach affects performance, engine/worker could > check {participant.responde_to? "on reply"} during first instantiating > and flag participant expression, so there would be no need to re- > instantiate participant if it doesn't provide "on_reply" handler. > > Participant class knows how to "tune" and post task to the user and > how to parse and transform received results in context of process. > Listener/receiver is an off-sided intermediate component. It knows > nothing about the process logic, but knows how to get "raw" results > from CMS and pass it to ruote. That was my idea.
Hi Oleg, Makes sense. -- John Mettraux - http://jmettraux.wordpress.com -- 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
