On Wed, Dec 22, 2010 at 14:14, John Mettraux <[email protected]> wrote:
>
> 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 :
>
Which won't really work in my case, because I have a resource per process,
not 1 shared resource for each of those processes.
A participant may be my best option at this point.
>
> ---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]<openwferu-users%[email protected]>
> more options : http://groups.google.com/group/openwferu-users?hl=en
>
--
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
