BPM 11g Deployment & Instance Migration

I have seen a number of request lately asking how to manage deployment of new process versions and how to ensure that instances are migrated from the previous version to the current version.

This blog will present three cases

  1. Where the change to the underlying process is not deemed significant and the process instances are migrated automatically
  2. Where the change to the underlying process is more complex and the process instances need to be migrated manually
  3. Where the change to the underlying process is so complex that the process instance cannot easily be migrated at all 

The blog will guide you step-by-step through runtime version management using BPM Studio but is equally applicable to deployment via other methods (such as via EM).

Note: Instance migration is only available from PS4FP onwards, instances created in prior versions of BPM cannot be migrated to PS4FP and onwards.

Understanding the Process

A simple process.... 3 different HTs with 3 different forms, followed by a file write....

A simple schema... 3 complex types representing 3 forms...

A sample input... individual elements will form whole quotation....

 Form 1....

 Form 2...

 Form 3...

 Output File...

 Initiate several instances, each at differing points in the process flow...

Small Change to XSD in a Single Existing Form

This is a very standard use-case, customer has missed a field in a form, needs to change the underlying XSD and form and re-deploy.

 Change Form2 in XSD inside the BPM project to include a new element...

 ...note that this is immediately reflected in the BOs and DOs...

 ...and in the XSD associated with the form payload...

 We need to refresh the Data Control to reflect changes in the form by right-clicking on the relevant Data Control and choosing "Edit Definition"...

...the Data Control has now changed... 

Now need to reflect this change in the actual Form.

Looking at the Form itself, we can see where the field needs to go...

...so add an "InputText" field by right-clicking on "Field21"...

...and then drag-and-drop the new field from the Data Control over this...

 ...and the form is complete...

Deploy this to the WLS in the normal manner...

...and re-run a test to verify that the form has indeed changed...

Redeploy the BPM project.... we would like to keep running instances and migrate these to the new version.

Deploy the BPM project with the same RevisionID and "keep running instances" (note: in PS5 it is not possible to migrate instances across RevisionIDs)...

Inside BPM Workspace, notice that in "Pending Components" under the "Process Tracking" tab,  no process instances are pending...

...why is this ? All the instances have been automatically migrated to the new version since the change to the underlying process was not deemed significant enough to need manual migration.

How do we ensure that those instances that have passed the changed form, Form2 (i.e. those at Form3) have the correct data ? We can use "Alter Flow".

In the "Process Tracking" tab choose an instance at Form3...

...and choose the "Alter Flow & Suspend" action....

...and notice that in the DO we do not have a "Field20"....

...we can just add it directly to the shown XML and click "Resume" leaving the current activity as "Form3" (Note: we could have moved the process back to "Form2" and re-entered the data if desired"...

Go back to the relevant instance, complete "Form3" and let us look at the file contents....

Larger Change to XSD in a New Human Task / Form Inside a Scope 

Alter the XSD... 

 ...and the process...

...and create and deploy the new UI project for this Form.

Redeploy the BPM project as before, "keeping running instances"...

Inside the BPM Workspace, look at the "Pending Components"...

...since we've added a new scope, automatic migration of instances is not possible.

We now have two options....

  1. We can migrate the instances individually or as in bulk from the "Process Tracking" tab
  2. We can migrate the instances in bulk from the "Pending Components"

Migrate individually

 ...allow us to alter the flow and data...

Migrating as a group 

 ...allows us only to change the flow, NOT the data.

Migrate from Pending Components 

...does not allow access to alter flow OR data. 

Removal of a Scope

In this case the change is deemed to be so significant that instance migration is not easily possible.

Remove the sub-process around Form0...

...and redeploy with "Keep Running Instances"....

 Now, looking at the deployment log we see...

...deployment failed because of "unrecoverable incompatibilities". The change we made of removing the sub-process was obviously of too large a consequence... a full list of process changes which cause this are as follows (PS5)...

  • Exclusive or inclusive gateway pair is removed
  • Inclusive-complex gateway pair is changed to inclusive-inclusive gateway pair
  • Sub-process is removed or its loop characteristics are changed
  • User task is moved to another branch in gateway pair or outside the gateway pair
  • Activity level is changed... for example, the activity is moved inside a sub-process or gateway structure
  • Sub-process or Event sub-process or call activity is added
  • Event sub-process is changed from interrupting to non-interrupting
  • Boundary event is changed from interrupting to non-interrupting
  • Boundary event is added
  • User task implementation is changed to use another human task

So, how do we avoid this or work-around this ?

In reality it could be argued that changes of this significance should require a new RevisionID, in which case all old instances continue to completion on the old revision and any new instances use the new revision.

There is an alternative, we can "force" deployment of the composite by amending the "composite.xml" source...

...this sets the "force" flag at the composite level, i.e. applicable to all BPM processes in the composite, it can also be set at an individual BPM process level... see "BPM Modelling and Implementation Guide" for more details. 

Now, deploy as before with "Keep Running Instances" and the deploy log shows....

 ...now looking at the "Process Tracking" tab in BPM Workspace, we see the same situation as previously.... with "Pending Components" which can be dealt with as above....


Thank you for your useful entry!
This is very useful but I think boundary condition between manual instance migration and automatic instance migration is not clear.
If you know the boundary condition, could you please share it?

Posted by guest on May 24, 2012 at 11:35 PM PDT #

Glad you found it useful.

The boundary is clear between migratable (automatically or not) and not deployable... see the last section of the blog entry... the boundary between automatic and manual is clear internally to Oracle but subject to change, hence not really appropriate to mention here.
What I will say is that this should not really affect a user.... you deploy and if everything is migrated automatically, great, if not then deal with it as above.


Posted by Mark Foster on May 30, 2012 at 01:18 AM PDT #

I want to migrate BPM 10g to 11g.is it possible to migrate BPM 10g to 11g. if you have any websites please send me or any idea please assist me. i have been trying to import into JDevloper but composite.xml shows empty.when i trying to open the process it wont open.

or is there any migrating tools for to do for

Posted by guest on April 24, 2013 at 10:45 PM PDT #


It is not really possible to migrate from BPM 10g to 11g.... in fact a migration tool is planned from 10g to 12c... I suggest you wait for the 12c release... it will make your migration so much easier.

Posted by Mark Foster on April 25, 2013 at 12:42 AM PDT #

Post a Comment:
  • HTML Syntax: NOT allowed

This is the blog for the Oracle FMW Architects team fondly known as the A-Team. The A-Team is the central, technical, outbound team as part of the FMW Development organization working with Oracle's largest and most important customers. We support Oracle Sales, Consulting and Support when deep technical and architectural help is needed from Oracle Development.
Primarily this blog is tailored for SOA issues (BPEL, OSB, BPM, Adapters, CEP, B2B, JCAP)that are encountered by our team. Expect real solutions to customer problems, encountered during customer engagements.
We will highlight best practices, workarounds, architectural discussions, and discuss topics that are relevant in the SOA technical space today.


« August 2016