X

Best Practices from Oracle Development's A‑Team

BPM 11g Deployment and Instance Patching

Mark Foster
Director

Introduction

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

DAF01

 

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

DAF02

 

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

DAF03.GIF

 

Form 1....

DAF04.GIF

 

Form 2...

DAF05.GIF

 

Form 3...

DAF06.GIF

 

Output File...

DAF07.GIF

 

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

DAF08.GIF

 

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

DAF09.GIF

 

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

DAF10_01.GIF

 

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

DAF11.GIF

 

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

DAF37.GIF

 

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

DAF13.GIF

DAF14.GIF

 

Now need to reflect this change in the actual Form.

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

DAF15.GIF

 

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

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

DAF17_01.GIF

 

...and the form is complete...

DAF18.GIF

 

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

DAF19.GIF

 

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

DAF20.GIF

 

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

DAF21.GIF

 

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

DAF22.GIF

 

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

DAF23.GIF

 

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

DAF24.GIF

 

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

DAF25.GIF

 

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

DAF26.GIF

 

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

DAF27.GIF

 

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

Alter the XSD...

DAF28.GIF

 

...and the process...

DAF29.GIF

 

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

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

DAF30.GIF

 

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

DAF31_02.GIF

 

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

DAF32.GIF

 

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

DAF33_01.GIF

 

DAF34_02.GIF

 

Migrating as a group

DAF35.GIF

 

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

Migrate from Pending Components

DAF36.GIF

 

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

DAF38

 

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

DAF39.GIF

 

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

DAF40.GIF

 

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

DAF41.GIF

 

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

DAF42.GIF

 

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

DAF43.GIF

 

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