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 -- -- 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 --- 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
