Work-around Instance Migration Limits of BPM Suite 11g

The following describes a work-around for 2 situations for which instance patching and migration is not supported, being changing the level of an activity, and removal of an embedded sub-process. In short this work-around consists of re-implementation of the activities to move, and emptying the reusable sub-process.

There are a couple of restrictions for the Oracle BPM Suite that can make that process instances cannot be patched (deployment using same revision number) or migrated (deployment using new revision number, and then move from old to new revision). Two of them are that you cannot change the scope of an activity (like moving it in our out of an embedded sub-process) or removal of an embedded sub-process. For both situations there is a work-around, that I can demonstrate with one case.

More information about instance patching and migration can be found here for BPM 11g (11.1.1.7) and here for BPM 12c (12.1.3).

The Work-Around

Suppose you have a process (A) like this:

And you want to change it to this (in real life you may want to move the activity inside to a totally different location, or even remove the embedded sub-process altogether) to this model (D):

As migration of running instances is not supported:

1. Because of changing the scope of the activity, and
2. Because of removal of the embedded sub-process

you will get an error like this when trying to do so:

 However, what you can do, is change the model like this (C):

The trick is that the Say Goodbye activity has not been moved outside, but re-implemented. In this case I created a new activity with the same name, and reused the existing task definition. So I only had to redo the data mappings.

You won't win any prize for most beautiful process model with this but it works. In practice you want to collapse the embedded sub-process and rename it to something like "Empty".

The Proof of the Pudding

To make sure it actually works for running processes I used an extra step between (A) and (C), being this model (B):

 First I started with the first model, created 2 instances with one in Say Hello, and the other in Say Goodbye. I then deployed the last model with "Keep running instances" checked (instance patching). The result was that both instances were automatically migrated (i.e. just kept on running).

Then I created a start situation of 3 instances, each of them being in a different activity. The most interesting is the one in Say Goodbye in the re-usable sub-process, as in this case the token is in an activity that is going to be removed.

 In line with the documentation, when deploying model (C) all instances were put I status Pending Migration. Using Alter Flow I was able to migrate the instances in the first and last activity as-is. After that I could successfully complete them.

The interesting one though, is in the second activity:

I was able to migrate that with Alter Flow by moving the token from the embedded sub-process (not the activity inside the embedded sub-process!) to the last activity:

The engine never knew what hit it ;-)