On Nov 20, 11:05 am, John Mettraux <[email protected]> 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
> Sorry this is just an architectural (rococo) brain fart.
>
> It depends, as always.
>
> Kind regards,
>
> --
> John Mettraux - http://jmettraux.wordpress.com
--
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
