Re: 0.9.x and ProcessParticipant

[John Mettraux]

On Fri, Nov 20, 2009 at 7:10 AM, Enrico wrote:
>
> What could be causing this? Does this have anything to do with the way that ProcessParticipants respond to cancellation? Is this a bug of some sort?

Hello,

this is a design flaw in ruote 0.9.x. Please don't use them.

Cheers,

--
John Mettraux - http://jmettraux.wordpress.com

[Enrico Bianco]

Will this be fixed in ruote 2.0? My interest in using
ProcessParticipant is to make my process definitions a bit more
"dynamic" by breaking a large process into smaller processes, which
may be individually modified.

- Enrico

[John Mettraux]

On Fri, Nov 20, 2009 at 10:00 AM, Enrico Bianco <enr...@gmail.com> wrote:
> Will this be fixed in ruote 2.0?

Hello,

yes it is.

> My interest in using
> ProcessParticipant is to make my process definitions a bit more
> "dynamic" by breaking a large process into smaller processes, which
> may be individually modified.

See for example :

http://github.com/jmettraux/ruote/blob/master/test/functional/eft_5_subprocess.rb
http://ruote.rubyforge.org/exp/subprocess.html

Please note the many possibilities.

[John Mettraux]

On Fri, Nov 20, 2009 at 10:09 AM, John Mettraux <jmet...@openwfe.org> wrote:
> On Fri, Nov 20, 2009 at 10:00 AM, Enrico Bianco <enr...@gmail.com> wrote:
>> Will this be fixed in ruote 2.0?
>
> Hello,
>
> yes it is.

http://github.com/jmettraux/ruote/commit/4d9587669f5b501fcbf54cf14a75e57bb2878d4a

[Enrico Bianco]

On Nov 19, 8:09 pm, John Mettraux <jmettr...@openwfe.org> wrote:

> On Fri, Nov 20, 2009 at 10:00 AM, Enrico Bianco <enri...@gmail.com> wrote:
> > Will this be fixed in ruote 2.0?
>
> Hello,
>
> yes it is.
>
> > My interest in using
> > ProcessParticipant is to make my process definitions a bit more
> > "dynamic" by breaking a large process into smaller processes, which
> > may be individually modified.
>
> See for example :
>

>  http://github.com/jmettraux/ruote/blob/master/test/functional/eft_5_s...

>  http://ruote.rubyforge.org/exp/subprocess.html
>
> Please note the many possibilities.
>
> Cheers,
>
> --
> John Mettraux - http://jmettraux.wordpress.com

Modifying a subprocess in a process definition won't affect the flow
of a currently running process instance, right?

The intent is to avoid having to rewrite/replace expressions in
currently running process instances as much as possible because that
would be incredibly difficult to pull off quickly and reliably in a
production deployment. Different instances of the same process
definition might be at different steps and need different changes,
making it difficult to automate.

I will spend some more time discussing with the stakeholders of my
project what the nature and frequency of the changes to our processes
might be and try to come to a reasonable solution but what I'm
understanding here is that if we need to change the flow (not just the
variables) of a process in-flight, then we have no choice but to
dissect the instance and replace some of its expressions.

Thank you,
Enrico

[John Mettraux]

On Sat, Nov 21, 2009 at 12:48 AM, Enrico Bianco <enr...@gmail.com> wrote:
>
> Modifying a subprocess in a process definition won't affect the flow
> of a currently running process instance, right?

Hello,

modifying a subprocess definition in a process definition will not
affect the flow of a currently running process instance.

> The intent is to avoid having to rewrite/replace expressions in
> currently running process instances as much as possible because that
> would be incredibly difficult to pull off quickly and reliably in a
> production deployment. Different instances of the same process
> definition might be at different steps and need different changes,
> making it difficult to automate.
>
> I will spend some more time discussing with the stakeholders of my
> project what the nature and frequency of the changes to our processes
> might be and try to come to a reasonable solution but what I'm
> understanding here is that if we need to change the flow (not just the
> variables) of a process in-flight, then we have no choice but to
> dissect the instance and replace some of its expressions.

This is a difficult conversation (the one we have right now, not the
one you want to have with your stakeholders), we have to be sure to
speak the same language.

Subprocesses are essential for dynamic processes, as you yourself have
said in a previous mail.

A common pattern would be to have a high level process definition
triggering the relevant subprocesses. Which to trigger being decided
at runtime.

subprocess :ref => "${f:next_subprocess}"

Process definitions that are too monolithic will indeed require
painful "migrations". Better to have small easy to cancel pieces in an
adaptable top loop (or kind of).

Another technique would be to have workflow that migrate themselves
according to the state of the resources they are in charge of.
Workflows for high-level orchestration, state-machines for resource
lifecycle. Starting a workflow would see it reach the appropriate step
according to the state of the resources it's supposed to orchestrate,
auto-migration somehow.
Sorry this is just an architectural (rococo) brain fart.

It depends, as always.


Kind regards,

[Enrico Bianco]

On Nov 20, 11:05 am, John Mettraux <jmettr...@openwfe.org> wrote:
> This is a difficult conversation (the one we have right now, not the
> one you want to have with your stakeholders), we have to be sure to
> speak the same language.

I'm sure both conversations will prove to be quite difficult. =)

>
> Subprocesses are essential for dynamic processes, as you yourself have
> said in a previous mail.
>
> A common pattern would be to have a high level process definition
> triggering the relevant subprocesses. Which to trigger being decided
> at runtime.
>
>   subprocess :ref => "${f:next_subprocess}"

If I'm reading the ruote 0.9 documentation correctly, this needs to
refer either to a subprocess defined within the main process
definition (I've used subprocesses this way before) or to a file
containing a process definition if :remote_definitions_allowed is set
to 'true' in the engine parameters.

Using the former method, I would have the same problem as mentioned
above: a change to the subprocess definition will not affect the flow
of a currently running process instance. Using the latter method would
be possible and seems like it would be very close in effect to using a
ProcessParticipant.

>
> Process definitions that are too monolithic will indeed require
> painful "migrations". Better to have small easy to cancel pieces in an
> adaptable top loop (or kind of).

Which was the approach I was trying to take with ProcessParticipant.
With that approach, change would be contained within a subprocess
rather than necessarily affecting the entire process.

>
> Another technique would be to have workflow that migrate themselves
> according to the state of the resources they are in charge of.
> Workflows for high-level orchestration, state-machines for resource
> lifecycle. Starting a workflow would see it reach the appropriate step
> according to the state of the resources it's supposed to orchestrate,
> auto-migration somehow.

If I'm understanding correctly, with this approach it would be
possible to just cancel and re-launch the process when its definition
changes. The process would then automatically progress to the step(s)
that it should be on, based on the underlying state of the resource. I
definitely need to spend some time evaluating this idea.

You've read my process definitions, so you might have noticed that
there are quite a few process-level variables defined, some of which
are actually carrying "state" information. This approach would
separate the concern of state from the process itself and I imagine it
would lead to a much cleaner, easier to maintain process definition.
It would also make it possible to migrate to a completely different
workflow engine implementation in theory; the state is held within the
resource, and thus won't be lost when the workflow engine is
completely replaced.

This is an incredibly interesting idea and one that merits further
evaluation. It may prove to be the best solution for our particular
case, even if it takes a bit more work upfront than other options.

Thanks again,
Enrico