Hi John,
>
> >> There is one thing. Since we now favour participants instantiated for
> >> each dispatch over participants instantiated at register time, it
> >> may/will not be the the 'same' participant doing the on_reply as the
> >> one that did the dispatch.
>
> > I'm not sure what is the problem here. Participant is stateless,
> > needed "state" information may be saved in the workitem. User just
> > provide a classname with some options, and it will have desired
> > behavior in any worker aquainted with this class. I planned to
> > implement some basic participant and subcluss it for "type" of tasks.
> > It will parse and transfrom results as needed. Usually we have 10-20
> > different type of tasks per workflow instance, used for all the
> > processes.
>
> 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.
Best regards,
Oleg
--
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
