cursor do
      user_3 :task => 'doing user_3 stuff...'
      echo 'back from participant-implementation...'
      user_4 :task => 'doing user_4 stuff now...'
      echo 'end of Pdef reached'
end

My registration:

    @dboard.register do
      participant /^user_/, Klaus::SkilledParticipant
    end

My Participant-Impl:

class SkilledParticipant < Ruote::StorageParticipant
      include Ruote::LocalParticipant
      def on_workitem
         puts "partitcipant-name: * #{workitem.participant_name}"
         level = workitem.participant_name.match(/^user_(\d+)/)
[1].to_i
         puts "level=#{level}"

         puts "i am into local Participant now!"
         super
         reply_to_engine(workitem)
      end
   end

if i login, say my user-name and launch the process-definition, it
says:

username: user_3
skill-level: 0
registered participant...
user_3> launch
user= user_3
skill= 0
launched process instance 20120509-0739-duduwaja-nazegiku
user_3> my skill level is: 0
do level 0 jobs
do the task now!
partitcipant-name: * user_3
level=3
i am into local Participant now!
back from participant-implementation...
partitcipant-name: * user_4
level=4
i am into local Participant now!
end of Pdef reached

it seems as during launching the pdef, all code from my participant-
implementation will be executed, no matter of sequence or waiting for
the next participant.

if I now ask for workitems, it says:
workitems
  N ID                                   PARTICIPANT
TASK
  0 20120509-0740-rajobiza-gidogebu 0_0_0_4 user_3         doing
user_3 stuff...
  1 20120509-0740-rajobiza-gidogebu 0_0_0_6 user_4         doing
user_4 stuff now...
workitems: 2

I thought the participiant "user_4" can only be executed if
participant "user_3" has his work done...
like a storage-participant does.

My main question is: I do not know where to put the main logic - into
pdef or into implementation - of the participant.
Sorry, but already I Do not understand why the "launch" action
consumes the whole workflows, with all participants without waiting
for a "proceed" action or waiting for the special participant, logged
in.

Hello Klaus,

Never forget re-reading your code.

Thanks for the new thread of conversation,

Now, I also can give workitem-fields back to the Workflow and use them
to take different paths through the process-definition.

like this:

participant:
...
    $i = Integer(gets)
    workitem.fields['total'] = $i
end

reply_to_engine(workitem)
...

pdef:
      user_3 :task => 'doing user_3 stuff...'

      echo 'total was given: ${f:total}'
      echo 'back from participant-implementation...'

      user_4 :task => 'doing user_4 stuff now...'

But again some open questions, related to the topic:

1. It seems as if I have to handle myself which participant will be
executed by whom. Not like in my "for-klaus" example, where only the
current user can execute the participants with the same name.

2. During combining the "for-klaus" example with a self implemented
participant, I found out this is asynchronously. Means. If I am
waiting for a user-prompt within the participant-implementation, My
Input can also be an Input for the "main-command-loop" in this:

  def run

    loop do
      print("#{@user}" + (@workitem ? ":#...@workitem.fei.sid}" : '') +
'> ')
      self.eval(gets)
    end
  end

Is there a way to handle the Participant-Implementation in an other
terminal (later I would generate some web-output instead)

3. If I connect as a new user to my "for-klaus" client, is there a way
to join an existing Process-Instance (an already launched one)?
For me, it seems that only the one (the terminal which launches the
process-definition) will see the participant-implementation-execution.

Hello Brain,

  i = Integer(gets)
  workitem.fields['total'] = i

You can even write

  workitem.fields['total'] = Integer(gets)

If you get back to the original for_klaus example, you'll notice that the
"note" modifies the workitem fields. It was this command you were supposed to
discover and enhance. You could use the arguments to the command to modify
the workitem, and it would all fit nicely in the for_klaus main loop.

So I'd say that the for_klaus client is showing you a way to do user
interaction with a workitem without having to provide your own class
inherited from Ruote::LocalParticipant.

Try to step back, breathe and look at the big picture. If you keep your nose
within one centimeter of the code you'll never get anything.

Kind regards,