Best Practices from Oracle Development's A‑Team

BPM 11g Deployment and Instance Patching

Mark Foster


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 (patched) from the previous version to the current version.

This blog will present three cases

  • Where the change to the underlying process is not deemed significant and the process instances are migrated automatically
  • Where the change to the underlying process is more complex and the process instances need to be migrated manually
  • 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.

Main Article

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....

  • We can migrate the instances individually or as in bulk from the "Process Tracking" tab
  • 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....



Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha

Recent Content