On Wed, Dec 22, 2010 at 11:25:58AM +0100, Joeri Samson wrote:
>
> I'm wondering how to use _when in my code. In the documentation it is said
> that the blocking form of _when makes most sense when used inside a sequence
> or cursor. This I get, if it was placed in a concurrence then it wouldn't
> really changing much of the flow. What I do not understand however is how to
> influence the evaluation of the conditions once the process is blocked on
> the _when condition. I don't see how I could change a process variable or a
> workflow item from outside.
> Of course it's possible to place this sequence in a concurrent flow, but if
> that's actually necessary it may be a good idea to clarify that in the
> documentation.
Hello Joeri,
you could be observing a variable bound at the engine variable :
---8<---
require 'rubygems'
require 'ruote'
engine = Ruote::Engine.new(Ruote::Worker.new(Ruote::HashStorage.new))
#engine.configure('ruby_eval_allowed', true)
#engine.noisy = true
wfid = engine.launch(Ruote.define do
echo "in"
#as_soon_as :test => '${v://ok} == true'
as_soon_as '${v:ok}'
echo "out"
end)
sleep 1
engine.variables['ok'] = true
p :ok
engine.wait_for(wfid)
--->8---
> The reason I ask this is that I have to wait until a certain resource
> changes state from undecided to either won or lost. This has to be
> controlled at the end of the workflow, but it may not change immediately,
> else I could use _if. I could of course have a participant listen to that
> event (and in fact that may be easier to reuse), but my first inclination
> was to think that _when was a natural fit for what I wanted.
And the when can be set with a cron string to poll at right intervals.
> I suppose I could still use _when if I made the test expression ruby code,
> but that seems overkill.
It depends on your use case.
---8<---
as_soon_as '${r:MyLib.is_the_pizza_ready?}'
--->8---
looks not that bad.
There is another technique that might interest you. It's a bit obscure though :
---8<---
require 'rubygems'
require 'ruote'
engine = Ruote::Engine.new(Ruote::Worker.new(Ruote::HashStorage.new))
#engine.configure('ruby_eval_allowed', true)
engine.noisy = true
wfid = engine.launch(Ruote.define do
echo "in"
listen :to => 'ready', :upon => 'reply'
echo "out ${msg}"
end)
sleep 2
engine.receive(
Ruote::Workitem.new(
'fei' => { 'expid' => '0', 'subid' => '0', 'wfid' => 0 },
'participant_name' => 'ready',
'fields' => { 'msg' => 'hello world' }))
p :received
engine.wait_for(wfid)
--->8---
I should probably cook something to simplify that "empty" workitem creation.
I have to say that the classical "let's emit a workitem and wait for its
return" technique is not that bad. It really means "hey, this process instance
is interested in that event, please reply when it happens".
The "listen" technique is fun though.
Well, it all depends on your use case.
Best regards,
--
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
