Hello John,
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?
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?
Where can I find an example of interaction between Processdefinition
(Subprocess) and a the participant-implementation?
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?
4.
what is the diff between a "task" and an "activity"?
Thank you and greetings,
Klaus
On 27 Apr., 02:57, John Mettraux <[email protected]> wrote:
> Hello Klaus,
>
> On Thu, Apr 26, 2012 at 01:47:18PM -0700, Klaus Schmidtmamn wrote:
>
> > 1. Why do I have to use the worker
> > (Ruote::Worker.new(Ruote::FSStorage…) within the server Script and why
> > does it work without the “worker” within the client script?
>
> > If I put this part into the client script, multiple clients are able
> > to work without the server(“server worker” ) :
>
> > @dboard = Ruote::Dashboard.new(
> > Ruote::Worker.new(
> > Ruote::FsStorage.new('ruote_work')))
>
> Well spotted.
>
> If you have a workflow that is waiting for a long time or has a "cron"
> expression and only rely on workers inside of a client, you could have a
> situation where, when no clients are running, the workflows are actually not
> executing (there is no worker picking up tasks). Of course, whenever a client
> starts, the execution resumes, but that is annoying when you
> told to a workflow to "do that at this point in time" and it happens, only
> later (too late?), when a client finally kicks in.
>
> If you have ruote running side by side (in the same Ruby process) with a
> webserver, it's OK, both need to be running all the time. But what I've seen
> from production is that people want to seperate the webserver from any
> worker. You want to serve more web requests and you are usually happy with a
> pack of workers running in the backend.
>
> For a small organization having the worker side by side with the webserver is
> OK (and it's easy to test and debug).
>
> > 2. What do you think, will be the next step in order to integrate this
> > client into a rails controller which writes out json-objects or plain
> > html-stream? I do not want you solving my complete work; I just need
> > an inspiration how to continue.
>
> Well, the commands in the "for_klaus" client encompass both the controller
> and the view, it's then easy to
>
> class WorkflowController
> def launch
> pdef = extract_pdef_from_params
> fields = extract_initial_workitem_fields_from_params
> @wfid = $dashboard.launch(pdef, fields)
> end
> end
>
> ruote-kit (https://github.com/kennethkalmer/ruote-kit) is full example,
> although rack-centered, not rails-centered, but it's easy to find inspiration
> for controllers and views in there.
>
> https://github.com/kennethkalmer/ruote-kit/blob/master/lib/ruote-kit/...
> https://github.com/kennethkalmer/ruote-kit/blob/master/lib/ruote-kit/...
> ...
>
> Best regards,
>
> --
> John Mettraux -http://lambda.io/processi
--
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
