Hello Klaus,
On Thu, May 03, 2012 at 12:24:52PM -0700, Klaus Schmidtmamn wrote:
>
> since i tested a little around with the "for_klaus" example, i already
> have some questions.
>
> 1.
> Because i have many users with different skill level, i thought it
> make sense to have participants with the role of "skill-level".
> All Users (roles) should be active at the same time, so i think i need
> a Definition like this:
>
> Ruote.define do
>
> concurrence do
> subprocess :ref => 'skill_0_Handling'
> subprocess :ref => 'skill_1_Handling'
> subprocess :ref => 'skill_2_Handling'
> subprocess :ref => 'skill_3_Handling'
> end
>
> define 'skill_0_Handling' do
> cursor do
> ...
> rewind
> end
> end
>
> define 'skill_1_Handling' do
> cursor do
> ...
> rewind
> end
> end
> ...
>
> You think my thoughts are correct here?
I cannot read your thoughts ;-)
This could be rewritten as something like:
---8<---
Ruote.define do
citerator :on => [ 0, 1, 2, 3 ], :to_f => 'level' do
handle :level => '$f:level'
end
define :handle do
cursor do
# level is passed as variable ${v:level}...
end
end
end
--->8---
But you could launch one process instance per skill level, it would be
cleaner and the you don't seem to need to have those parallel things linked
together.
---8<---
(0..3).each { |i| @dboard.launch(pdef, 'skill_level' => i) }
--->8---
I'm probably wrong, but my excuse is that I don't know your use case.
> 2.
> In my "for_klaus" exmaple, there is always only a task defined e.g.
>
> user_alice :task => 'tune engine'
>
> But what if i will execute my own functionality instead of a task
> "tune engine"? I thought this could work with the consumer in the
> class like this:
>
> class Skill0
> include Ruote::LocalParticipant
>
> def initialize(opts)
> @opts = opts
> end
>
> def on_workitem
> begin
> puts 'say sth...'
> reply
> rescue
> re_dispatch(:in => @opts['delay'] || '1s')
> end
> ...
>
> But here, i do not understand the registration mechanism:
>
> You wrote into the registration part:
>
> @dboard.register do
> participant /^user_/, Ruote::StorageParticipant
> end
>
> I think this will register all users in the given Processdefinition.
> But in order to script a well implementation for each participant, i
> need sth like this:
>
> @dboard.register_participant "user_skill0", Skill0
>
> right?
You could do something like:
---8<---
class SkilledParticipant
include Ruote::LocalParticipant
def on_workitem
level = workitem.participant_name.match(/^skill_(\d+)/)[1].to_i
# ...
end
end
@dboard.register do
participant /^skill_/, Klaus::SkilledParticipant
participant /^user_/, Ruote::StorageParticipant
end
--->8---
In this example you can have all the "skill_0123" go to SkilledParticipant
and have the skill level interpreted on the fly.
Of course, nothing prevents you from being a bit more static:
---8<---
@dboard.register do
(0..3).each do |i|
participant "skill_#{i}", Klaus::SkilledParticipant, 'level' => i
end
participant /^user_/, Ruote::StorageParticipant
end
--->8---
(where your skilled participant knows about its level via the 'level' option
it's passed each time it's instantiated).
> Where can I find an example of interaction between Processdefinition
> (Subprocess) and a the participant-implementation?
I'm not sure if it's the right answer, but I've got the feeling that my
SkilledParticipant example is an example of such an interaction because the
participant extract infos at runtime from the name under which it's invoked.
> 3.
> Is the "on_workitem" function within the participant-implementation
> the same as i use
> "proceed" (@dboard.storage_participant.proceed(@workitem)
> @workitem = nil) in the "for_klaus" example?
No, the #on_workitem method is a general participant method, while the
#proceed method is almost only found in Ruote::StorageParticipant.
#on_workitem is called by ruote right after it instantiated the participant
to make it perform work on the workitem.
#proceed is called by clients to ruote that are using the
Ruote::StorageParticipant, have just performed some work related to a
workitem and want that workitem to leave the storage participant and
proceed/resume into its workflow instance.
> 4.
> what is the diff between a "task" and an "activity"?
Well, a "task" is just a convention I use to place a participant invocation
into some context.
---8<---
Ruote.define do
klaus :task => 'ask question'
john :task => 'answer question'
end
--->8---
John and Klaus will receive workitems. The task is just a label on the
workitem. Maybe the participant implementations uses it, maybe not. From the
ruote [engine] point of view, it's just a piece of payload information.
There is no "activity" concept in ruote.
Sometimes it's convenient to label a workitem "task" or "activity" in
documentation or explanations, but for the engine, it's only about handling
workitems to participants.
Kind regards,
--
John Mettraux - http://lambda.io/jmettraux
--
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
