grab an engine event to fire up a task

[Gonzalo]

Hi John and all,

I need ruote (v0.9.21) to do some stuff whenever the engine produces a
particular event.

For example, I would like to send a XMPP message to a client just when
the engine dispatches a workitem to an ArParticipant participant. What
would be the best way to accomplish this? Listeners?

Many thanks for the help and tips.
Best regards to all.

Gonzalo.

[John Mettraux]

On Thu, Nov 19, 2009 at 7:48 PM, Gonzalo <gonzalo....@gmail.com> wrote:
>
> I need ruote (v0.9.21) to do some stuff whenever the engine produces a
> particular event.
>
> For example, I would like to send a XMPP message to a client just when
> the engine dispatches a workitem to an ArParticipant participant. What
> would be the best way to accomplish this? Listeners?

Hello Gonzalo,

what about sticking with participants and doing something like this
(my bad, a few typos in there) :

http://github.com/jmettraux/ruote/blob/748145b149705ff975518186069d44270c6aeb8c/test/functional/ft_17_multi_participants.rb

The first participant is in charge, the other merely notify...


I hope this will help... Else a listener intercepting "applies" on a
given participant name should be OK.

http://openwferu.rubyforge.org/expressions.html#exp_listen

The first option applies to all process definitions, while the second
is limited to one process definition.


Best regards,

--
John Mettraux - http://jmettraux.wordpress.com

[Gonzalo Suarez]

Hi John,

I'll try both and see what's best for me.
Many thanks.

Gonzalo.

> --
> you received this message because you are subscribed to the "ruote users" group.
> to post : send email to openwfe...@googlegroups.com
> to unsubscribe : send email to openwferu-use...@googlegroups.com
> more options : http://groups.google.com/group/openwferu-users?hl=en

[Nicholas Petrella]

Hi John,

I had a quick question about the MultiParticipant. Why in the intialize do you neuter everything except the first participant passed in? Wouldn't you want the last one to be un-neutered so that only after all the participants have run will the process proceed?

It is probably something simple I am missing but I figured I would ask to be sure. Thanks!

-Nick

[John Mettraux]

On Fri, Nov 20, 2009 at 2:51 AM, Nicholas Petrella
<nickpe...@gmail.com> wrote:
>
> I had a quick question about the MultiParticipant. Why in the intialize do
> you neuter everything except the first participant passed in? Wouldn't you
> want the last one to be un-neutered so that only after all the participants
> have run will the process proceed?
>
> It is probably something simple I am missing but I figured I would ask to be
> sure. Thanks!

Hello Nicholas, it's been a while !

Your idea makes sense. My idea was like : the first participant is the
real one, all the others are "notifications". Most important first.
That's on the surface. Now behind the MultiParticipant method
signature, things could be very different (threaded consumption,
notifications first, ...)

I guess it depends on the end usage.


Thanks for sharing your ideas, cheers,

[Gonzalo Suarez]

Hi again,

I guess my problem can't be solved grabbing a engine event. I attached
a file with a workflow that illustrates my issue. I have a client that
interchanges messages with route. The client updates/proceeds on
workitems whenever a workitem is applied on a ArParticipant
participant. In the example workflow they are participants "form_A"
and "form_B". Participant web_service is an automatic process.

After the client proceeds on "form_A" it may happen to things:

1. web service participant is invoked and after it finishes a new form
("form_B") should be shown by the client
2. web service participant is invoked and after it finishes, the workflow ends.

I would need the client to show some kind of message when the first
case happens. Something like "please wait, a new form will show up".

We thought we could pass a parameter to participant "form_A" to tell
the client to show the message after a "proceed" and then if flow goes
to branch 2. use some king of XMPP message to tell the client not to
show it.

We don't like this much... We wouldn't like to mix this kind of logic
(client navigation) with the business logic.

I hope I had explined my issue well. Is this a right approach? Is
there any ruote feature we are missing that could help us to deal with
this in a better way?

Thanks you all for your help and tips.
Best regards.

Gonzalo.

[John Mettraux]

On Mon, Nov 23, 2009 at 1:24 AM, Gonzalo Suarez
<gonzalo....@gmail.com> wrote:
>
> We don't like this much... We wouldn't like to mix this kind of logic
> (client navigation) with the business logic.
>

> I hope I had explained my issue well. Is this a right approach? Is

> there any ruote feature we are missing that could help us to deal with
> this in a better way?

Hello Gonzalo,

I understand your concerns. Ruote is about workflow as in business
process, not much as in webflow / client navigation.

== idea a) decoupling worksession from workitem

The dead simple approach is 1 worksession = 1 workitem. But why not
having a specialization of your workitem consumption ?

---8<---
sequence do
participant :ref => 'Alfred', :operation => 'open with form_A'
_if :test => '${f:x} == ${f:y}'
# then
sequence do
participant :ref => 'webservice'
participant :ref => 'Alfred', :operation => 'close with form_B'
end
# else
sequence do
participant :ref => 'Alfred', :operation => 'close with no form'
participant :ref => 'webservice'
end
end
end
--->8---

"open with form_A" would open a worksession / workcase to be closed
later. The workitem delivered to alfred would trigger the creation of
a worksession closed.

Well, looks nice but not very snappy, could spoil the "client
navigation" experience.


== idea b) power to the participant (side)

Forget about describing that flow with ruote, you want it to be snappy, right ?

The flow would look like :

---8<---
participant :ref => 'Alfred'
--->8---

Then the rest is handled by the participant implementation : form A,
webservice, form B OR not. I put the "or" in uppercase because that
decision is done on the participant side, not on the engine side.

The disadvantage here is that the client has to do the webservice invocation.

==

I understand you want to avoid duplication of the decision form_B or
not in Ruote and on the client side. Your process definition seems to
suggest that at the end of form_A, we can decide (no extra information
needed from the engine side).

That's all I can think of for now. I hope this will help, best regards,

[Gonzalo]

Hi John,

Many thanks for the quick answer and suggestions.

Best reagards,
Gonzalo.

[Gonzalo]

Hi John,

I wonder if modifying LocalParticipant to handle a special "hash"
would be a good way to keep the logic and the navigation
'separated'... Now we could have something like this:

participant :ref => "form_A",
:nav => {:wait_for_next_form => true} # special "hash"

participant :ref => "web_service_Foo",


participant :ref => "form_B",
:nav => {:wait_for_next_form => false}


Then, we modify LocalParticipant to call a special consume method that
processes only :nav param, probably a XMPP notification for our
client. Then, after this, the "real" participant consume is called.

That way, every participant, even "automatic" ones, could notify stuff
to the client (just after the workitem is applied by the engine) just
by including the special param :nav.

Well, may be all this is silly. I'm just trying to figure out the best
way to deal with this issue...

Best regards!
Gonzalo.

[John Mettraux]

On Tue, Nov 24, 2009 at 5:22 AM, Gonzalo <gonzalo....@gmail.com> wrote:
>
> Then, we modify LocalParticipant to call a special consume method that
> processes only :nav param, probably a XMPP notification for our
> client. Then, after this, the "real" participant consume is called.
>
> That way, every participant, even "automatic" ones, could notify stuff
> to the client (just after the workitem is applied by the engine) just
> by including the special param :nav.

Hello,

or you could subclass ArParticipant to let only a some participant
benefit from this feature. Automatic participants shouldn't need it,
there is no client (browser?) involved... Maybe I'm wrong.

Cheers,

[Gonzalo Suarez]

Hi John,

Well 'automatic' participants could use that to update some info in
the client like a progress bar or something similar... Just an idea...
Just thoughts...

Many thanks again for your help and tips.
Best regards.
Gonzalo.