Hello John,
Thank you for answering. To reduce my confusion I have some more
questions:
1.
The construct:
@dboard.register do
participant /^skill_/, Klaus::SkilledParticipant
participant /^user_/, Ruote::StorageParticipant
end
means that all participants, containing a "skill" in her name are
instantiated as SkillParticipants and "user" as "StorageParticipant".
Do I need this "participant /^user_/, Ruote::StorageParticipant" if
there are only "skill-participants"? E.g. if each Workflow-Action
depends on the skill-level of the user, I only need "participant /
^skill_/, Klaus::SkilledParticipant"?
What does "Klaus" mean in "Klaus::SkilledParticipant"?
For me, it only works without the "Klaus::"- prefix.
2.
What actually confuses me most is the way how to realize individual
steps within my process-definition for the different users with
different skill level:
What I did is the following: After starting the client, the user can
input his name (not mandatory) and his skill-level (mandatory) like
this:
@dboard.register do
participant /^skill_/, SkilledParticipant
#participant /^user_/, Ruote::StorageParticipant
end
print 'username: '; @user = gets.strip
print 'skill-level: '; @skill = Integer(gets.strip)
2.
Does it make sense to launch the process-definition only with the
required skill-level... like this:
puts 'user= '+@user
puts 'skill= '+String(@skill)
wfid = @dboard.launch('./defs/def0.rb', 'skill_level' => @skill)
How to read this 'skill-level' parameter within the Process-
Definition? I think the skill-parameter has no influence over the
procss-definition if it starts like this:
citerator :on => [ 0, 1, 2, 3 ], :to_f => 'level' do
echo 'level= ${f:level}'
handle :level => '$f:level'
end
...
To me it seems like no matter what variable is given to the "launch",
the process-definition is deployed for all participants? I do not
understand what influence a variable like
'skill_level' => @skill has at this position.
3.
On the other hand side, you gave me the example below with the "skill-
level as variable". But how can I combine the registered participants
with this variable?
This confused me... So how would you change this part to make sense:
Ruote.define do
citerator :on => [ 0, 1, 2, 3 ], :to_f => 'level' do
echo 'level= ${f:level}'
handle :level => '$f:level'
end
define :handle do
cursor do
# level is passed as variable ${v:level}...
echo 'my skill level is: ${v:level}'
echo 'do level 0 jobs' , :if => '${v:level} == 0'
echo 'do level 1 jobs' , :if => '${v:level} == 1'
# this seems to be double conditioned...
# why using a variable like "${v:level}" if I have the different
skilled participants?
skill_0 :task => 'easy' , :if => '${v:level} == 0'
skill_1 :task => 'normal' , :if => '${v:level} == 1'
skill_2 :task => 'hard' , :if => '${v:level} == 2'
skill_3 :task => 'very hard', :if => '${v:level} == 3'
end
4.
Concerning to your explanation of task: "skill_0 :task => 'easy'" will
only say what to do, but in what way I can execute a function or a
method, if this workflow-position is reached?
I think on sth. like "skill_1 :task => doSth()'
Where should this function exist?
Greetings + Thank you for beeing patient
Klaus
On 3 Mai, 23:52, John Mettraux <[email protected]> wrote:
> 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
