how to interact with a running process

[ypz]

Hi,

I am trying to figure out how to interact with a running process from another process. After going through this mailing list,  my understanding is that I should use a StorageParticipant to manipulate the workitem of the running process.  For this purpose,  I wrote two test scripts, one for running a test process definition, and the other to manipulate a running process's workitem. Please see https://gist.github.com/ypz/6614031 for both scripts.

After starting run_pdef.rb script, I can see  from its output  the process is in the waiting loop as it supposed to. But when I run ack.rb script with appropriate wfid of running process in another window, it can't find any workitem for that process, therefore, nothing happens. 

Did I miss something important and obvious or am I totally misunderstand how to interact with a running process ? 

Thanks for any helps.

Ypz

[John Mettraux]

On Wed, Sep 18, 2013 at 02:03:01PM -0700, ypz wrote:
>
> Hi,

Hello and welcome to ruote's mailing list.

> I am trying to figure out how to interact with a running process from
> another process. After going through this mailing list, my understanding
> is that I should use a StorageParticipant to manipulate the workitem of the
> running process.

If interacting means "process A asks process B about its opinion" then yes.

"interacting" could also mean "process B terminates process A" or things like
this.

> For this purpose, I wrote two test scripts, one for
> running a test process definition, and the other to manipulate a running
> process's workitem. Please see https://gist.github.com/ypz/6614031 for
> both scripts.
>
> After starting run_pdef.rb script, I can see from its output the process
> is in the waiting loop as it supposed to. But when I run ack.rb script with
> appropriate wfid of running process in another window, it can't find any
> workitem for that process, therefore, nothing happens.
>
> Did I miss something important and obvious

Ack.rb asks to the storage: "any workitem for this workflow", storage
replies: "no, no workitems". Looking at run_pdef.rb, one can see that
"wait_for_admin_ack" is not a storage participant. It does not place the
workitem in the storage.

Here is a rewrite of your gist (using bundler):

https://gist.github.com/jmettraux/6617970

Like your original gist it keeps placing a workitem for the admin until the
admin acknowledges.

> or am I totally misunderstand
> how to interact with a running process ?

It's OK I think.

You are not forced to use a storage participant, anything that lets process B
looks at a workitem from process A is OK.

Storage participant is convenient.

The thing that is not good with your idea: process B has to know the wfid of
process A. A better design is probably one where process B queries for
whatever workitem in queue "admin" and proceeds them...

Maybe you want process A to launch process B and wait for B's answer...

Step back a few paces and look at the big picture.


Best regards,

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

[ypz]

On Wednesday, September 18, 2013 6:25:12 PM UTC-7, John Mettraux wrote:

On Wed, Sep 18, 2013 at 02:03:01PM -0700, ypz wrote:
>
> Hi,

Hello and welcome to ruote's mailing list.

Thanks

 

> I am trying to figure out how to interact with a running process from
> another process. After going through this mailing list,  my understanding
> is that I should use a StorageParticipant to manipulate the workitem of the
> running process.

If interacting means "process A asks process B about its opinion" then yes.

"interacting" could also mean "process B terminates process A" or things like
this.

In my current use case, the individual step may fail in such a way that only a human administrator can fix it, so I need a script to allow administrator to tell the running process that "I fixed the problem, it's OK to proceed to next step in the workflow".

>
> Did I miss something important and obvious

Ack.rb asks to the storage: "any workitem for this workflow", storage
replies: "no, no workitems". Looking at run_pdef.rb, one can see that
"wait_for_admin_ack" is not a storage participant. It does not place the
workitem in the storage.

Here is a rewrite of your gist (using bundler):

  https://gist.github.com/jmettraux/6617970

Like your original gist it keeps placing a workitem for the admin until the
admin acknowledges.

That helped, thanks a lot !

 

 

You are not forced to use a storage participant, anything that lets process B
looks at a workitem from process A is OK.

Storage participant is convenient.

What are other ways to look at/access a workitem of a running process ?  Any examples?

So far, all my custom participants extends Ruote::Participant.  I am not sure when should I use Ruote::StorageParticipant.  Some general guidelines would help.

Take care,

Ypz

 

[John Mettraux]

On Thu, Sep 19, 2013 at 04:14:28PM -0700, ypz wrote:
>
> (...)

>
> What are other ways to look at/access a workitem of a running process ?
> Any examples?

Hello,

generally if you want to access the workitem of a running process, you use
the storage participant to make it available.

You don't tell if, by design, you want to make such workitems available. A
vanilla workflow uses participants as hooks into the plane of "real
participants", human and services who do the real work. If there are no such
hooks (or all those hooks are quick-lived participant who perform
immediately) then the flow probably doesn't lend itself to inspection.

Using the Dashboard you can inspect running processes, see "where" they are.
Workitems are usually waiting in expressions. Usually those wait points are
participant expressions, that dispatch, thanks to a participant
implementation, to a real participant. You are free to cancel existing
expressions (that's a kind of interaction) or pause them (that too). You can
reapply an expression (with a new workitem).

Cancelling a process is simply cancelling the root expression of a process.

Those expressions have an "applied_workitem" variable which contains a copy
of the workitem as it was when the expression was applied (instantied and
applied).

Some custom participant implementations leverage that "applied_workitem" and
use it to become some kind of storage participant like construct.

> So far, all my custom participants extends Ruote::Participant. I am not
> sure when should I use Ruote::StorageParticipant. Some general guidelines
> would help.

A guideline would be: if there is a human [decision] involved, use a storage
participant, else implement a custom participant.

The parallel thread with Denis shows another case. The storage participant is
used as a temporary storage for a workitem between a http call and its
callback. Denis could have implemented that with a custom participant too.

So the guideline is rather: if you can push the workitem to the real
participant, you use a custom participant. If the real participant pulls the
work from you, you use a storage participant.

But that's a guideline, not a law.


Look and play with the Dashboard methods to inspect processes and their
expressions.