Workitem-Consuming

[Klaus Schmidtmamn]

my pdef:

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.


greetings
Klaus

[John Mettraux]

Hello Klaus,

On Wed, May 09, 2012 at 01:40:59AM -0700, Klaus Schmidtmamn wrote:
>
> (...)

>
> 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+)/)

> .t_i

> puts "level=#{level}"
>
> puts "i am into local Participant now!"
> super
> reply_to_engine(workitem)
> end
> end
>

> (...)

>
> 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.

It's because your #on_workitem, right after storing the workitem in the
storage thanks to the "super", immediately replies to the engine thanks to
"reply_to_engine(workitem)", that makes the workflow go on.

Never forget re-reading your code.

Thanks for the new thread of conversation,

--
John Mettraux - http://lambda.io/jmettraux

[Klaus Schmidtmamn]

Thank You!

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.

Greetings
Brain

[John Mettraux]

Hello Brain,

On Wed, May 09, 2012 at 06:24:23AM -0700, Klaus Schmidtmamn wrote:
>
> 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

Please note that using a Ruby global variable ($i) is not a good idea... They
never get garbarge collected. Why use a global variable when a local variable
is sufficient?

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

You can even write

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

> 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.

What is the question?

> 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

Yes. Of course when you've got a gun, you can shoot yourself in the foot.

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

Your idea of requesting information from a user at the beginning of your
#on_workitem is a bad idea, as you've experienced yourself the "gets"
conflicts with the main loop "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.

> 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.

Yes, the for_klaus client lets you pick any workitem, whoever the launcher.

> Greetings
> Brain

Brian?


Kind regards,