Updating existing workflows

[Doug Bryant]

John,

We have a situation where a long running workflow has been launched and needs to have it's process definition updated to account for workflow changes. Is there a recommend approach for accomplishing this?  Our thoughts at this point are to: 

A) cancel/delete the existing workflow, start a new workflow, advancing to the correct step without actually executing any of the steps (mostly remote participants via amqp)

or 

B) keep the old workflow and old functionality running alongside the new functionality.

I don't see option B working out very well due to the complexity it introduces.  Option A seems feasible but not without complexity;  not sure if it is a good approach or not.   Do you have any thoughts/recommendations on this matter?

Thanks, Doug

[John Mettraux]

On Fri, May 10, 2013 at 10:05:13AM -0700, Doug Bryant wrote:
>
> (...)

>
> A) cancel/delete the existing workflow, start a new workflow, advancing to
> the correct step without actually executing any of the steps (mostly remote
> participants via amqp)
>

> B) keep the old workflow and old functionality running alongside the new
> functionality.
>
> I don't see option B working out very well due to the complexity it
> introduces. Option A seems feasible but not without complexity; not sure
> if it is a good approach or not. Do you have any thoughts/recommendations
> on this matter?

Hello Doug,

I know nothing of your context, so I'll give blind advice.


## ruote's thinking

Ruote is meant to run workflows, it just runs them, it doesn't keep track of
relations between workflows, this is only relevant to users of the workflows
/ applications that use ruote.

If you switch from workflow definition A to workflow definition A', ruote is
perfectly happy to run instances/executions of both definitions.

A classical use case, "the routine has changed, let's update the workflow
definition, the old workflows will simply go on, new launches will be
performed with the new workflow definition".

(Note that workflow definitions share participants).


## long running workflow

But in your case

> We have a situation where a long running workflow has been launched and
> needs to have it's process definition updated to account for workflow
> changes. Is there a recommend approach for accomplishing this?

There is a simple tool that could help.

https://github.com/jmettraux/ruote/blob/f532b2d535f822ca23dcd5f7dcd6da748674a44e/test/functional/ft_14_re_apply.rb

You can point re_apply to a process expression (that means a leaf or a
segment) of a running instance and get it cancelled and re-run with a new sub
definition.

With a bit of automation, you can turn that into a migration tool. (tool
determines the position of the workflow and decides on which expression to
re_apply with which process definition).


## mutation

At some point, I had some sponsored work on "mutations" (but I couldn't go on
with that work), it still may be useful.

https://github.com/jmettraux/ruote/blob/f532b2d535f822ca23dcd5f7dcd6da748674a44e/test/functional/ft_81_mutation.rb
https://github.com/jmettraux/ruote/blob/f532b2d535f822ca23dcd5f7dcd6da748674a44e/lib/ruote/dboard/mutation.rb
https://github.com/jmettraux/ruote/blob/f532b2d535f822ca23dcd5f7dcd6da748674a44e/lib/ruote/dashboard.rb#L414-L434

It stopped worked on this, I remember it worked for some simple cases (as
shown by its test cases), but I didn't go with more complex expressions
(can't even remember if I tested with "cursor").


## re_apply

That "re_apply" could help, I have the impression your workflow instances are
stuck in 5-10 well known "places" and thus you'd have 5-10 re_apply scenarii.


OK, enough writing. Have a nice week-end!

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

[Doug Bryant]

Thank you.   Will do some investigating this weekend.  

The context in which we want to update the workflow is additional steps added to the process.  

This is very simplified, but  basically

sequence do

  alpha

  delta

  zulu

end

has become

sequence do

   alpha

   beta

   charlie

   delta

   victor

   zulu

end

delta will always be delta but when existing running workflows advance, the next step should be victor rather than zulu.  We do take take advantage of the "classical" use case and it has served us very well so far.  In this case, it's a requirement for existing workflows to use the new steps also.

Thanks again.

Doug

--
--
you received this message because you are subscribed to the "ruote users" group.
to post : send email to openwfe...@googlegroups.com
to unsubscribe : send email to openwferu-use...@googlegroups.com
more options : http://groups.google.com/group/openwferu-users?hl=en
---
You received this message because you are subscribed to the Google Groups "ruote" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openwferu-use...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.