:wait_for problem and dynamic :timers

[Danny Fullerton]

Hey guys,

In the following process I'm trying to create a concurrence where both
participant can modify the workitem but only administrator participant
can complete the segment (concurrence). I believe the :wait_for
attribute should do the trick but for some reason I can't get it working
properly. I have to close the evaluator participant in order to get out
of the concurrence. What I'm I doing wrong?

---8<---
RuoteKit.engine.variables['issue_management'] = Ruote.process_definition do
concurrence :wait_for => 'first' do
sequence :tag => 'first' do
administrator :timers '1m: reminder_soon, 2m: reminder_final, 3m:
reminder_late'
end
sequence :tag => 'second' do
evaluator
end
end
third_participant
end
--->8---

To get around the issue I'm using :count => 1 and do not permit
evaluator to reply which is obviously not optimal.

Secondly, I would like to know if there's a way the evaluator could
modify the :timers attribute of administrator dynamically? You see, the
job of the evaluator is to ensure the workitem severity is right and
modify it if needed. However, the time accorded to fix the issue depend
on the severity, hence the desire to modify it dynamically. If the issue
was considered low at first but is then evaluated to high by the
evaluator, the administrator will have less time to fix the issue.

thanks,

--
Danny Fullerton
Founder
Mantor Organization

[John Mettraux]

On Sun, Jun 03, 2012 at 10:42:44PM -0400, Danny Fullerton wrote:
>
> In the following process I'm trying to create a concurrence where both
> participant can modify the workitem but only administrator participant
> can complete the segment (concurrence). I believe the :wait_for
> attribute should do the trick but for some reason I can't get it working
> properly. I have to close the evaluator participant in order to get out
> of the concurrence. What I'm I doing wrong?
>
> ---8<---
> RuoteKit.engine.variables['issue_management'] = Ruote.process_definition do
> concurrence :wait_for => 'first' do
> sequence :tag => 'first' do
> administrator :timers '1m: reminder_soon, 2m: reminder_final, 3m:
> reminder_late'
> end
> sequence :tag => 'second' do
> evaluator
> end
> end
> third_participant
> end
> --->8---
>
> To get around the issue I'm using :count => 1 and do not permit
> evaluator to reply which is obviously not optimal.

Hello Danny,

I've added this test case to the ruote suite:

https://github.com/jmettraux/ruote/commit/05dd683cd901457e895c810a1d9404f711dc5632

But it works fine for me. It's on the ruote master. I've tried with
1.8.7-p249, 1.9.2-p290 and 1.9.3-p125 on SnowLeopard. I have tried with a
NoOpParticipant and a NullParticipant for the evaluator.

Do you have more details? What do you mean by "not working properly"?


Best regards,

--
John Mettraux - http://lambda.io/jmettraux

[John Mettraux]

On Sun, Jun 03, 2012 at 10:42:44PM -0400, Danny Fullerton wrote:
>

> (...)

>
> Secondly, I would like to know if there's a way the evaluator could
> modify the :timers attribute of administrator dynamically? You see, the
> job of the evaluator is to ensure the workitem severity is right and
> modify it if needed. However, the time accorded to fix the issue depend
> on the severity, hence the desire to modify it dynamically. If the issue
> was considered low at first but is then evaluated to high by the
> evaluator, the administrator will have less time to fix the issue.

Hello Danny,

how about something like

---8<---

concurrence :wait_for => 'first' do

administrator :tag => 'first' do
sequence do
evaluator
wait '${etimeout}'
cancel 'first', :if => '${etimeout}'
end
end
--->8---

[Danny Fullerton]

Hello,

No that wouldn't work as the timer would not be dynamic. I'll rephrase.

When the process is started with a priority level of 'low' the
administrator is only notified 1 day before a 3 weeks limit.

Now, during that time, the evaluator participant can always modify the
priority e.g. 'low->high'. This implies the administrator has now less
time to do the work (e.g. 2 day limit and notified several time within
this period).

---8<---
concurrence :wait_for => 'first' do

sequence :tag => 'first' do

administrator :timers '$timer'
end
evaluator # modify $timer only if the evaluator change the priority level
end
third_participant
--->8---

I tried building a process which was launching static high/medium/low
priority subprocesses and also tried Rufus::decision participant but failed.

Now I'm really not sure I'll be able to translate this in the process
definition itself. I believe I'll have to externalize the notification
system from Ruote process definition but I'm still asking, just in case.

regards,

--
Danny Fullerton
Founder
Mantor Organization

[John Mettraux]

On Wed, Jun 13, 2012 at 11:12:26PM -0400, Danny Fullerton wrote:
>
> (snip)

>
> Now I'm really not sure I'll be able to translate this in the process
> definition itself. I believe I'll have to externalize the notification
> system from Ruote process definition but I'm still asking, just in case.

OK, understood.

Just for fun I wrote this example (it runs from the command line):

https://github.com/jmettraux/ruote/blob/65acf4c1436ba3f8a846a68a8a75e0cb586c70e7/examples/dannymic_reminders.rb

Maybe it helps.