BPM 11g: Instance Patching Revisited: Inability to Create New Instances

October 6, 2014 | 11 minute read
Mark Foster
Director
Text Size 100%:

Introduction

Back in 2012 after the release of BPM 11g PS4FP I wrote a blog entry on Instance Patching, what it was and how it worked.

Remember, instance patching is redeployment of a composite on the same Revision ID with "keep running instances" option, as opposed to instance migration which follows deployment of a new composite with a new Revision ID and selected instances migrated from the old to the new revision.

I've decided to revisit the subject in a little more detail on the back of an issue a customer had with instance patching.... they'd redeployed a composite after making a very small "compatible" change to the BPM process and subsequently found that they could not instantiate new instances. This blog will detail why this situation happened and how to recover from it.

Walk-through of the Issue

Revisit the Process

From the previous blog entry we had a very simple process with three human activities and file write....

IP14_01

....we instantiated several instances and progressed them to various different human activities....

IP14_02

 

Make an Incompatible Change to the Process

As in the prior blog entry, if we make an incompatible change to the process model then instances should not be able to be automatically patched.

Add an embedded subprocess with a new human activity (exactly as we did in the prior blog)....

IP14_03

...deploy this with the same "Revision ID' and "Keep running instances" option....

IP14_04

 

Now if we go into the BPM Workspace we should see the BPM component suspended (as in the prior blog)....

IP14_05

...strange, no pending components....

IP14_06

...and all instances successfully patched !

This is an improvement since the PS4FP release of the product, now the engine can handle more complicated changes to the process when instance patching.

Let's try removing the embedded subprocess and redeploy....

IP14_07

IP14_08

...it failed to deploy that time. We'll need to "force" it as per the prior blog entry....

IP14_09

...and now it deploys....

IP14_10

 Investigate the Suspended Instances

Looking in the BPM Workspace under the "Process Tracking" tab we can see the process is "Pending"....

IP14_11

... and the instances are all suspended....

IP14_12

Try Creating a New Process Instance

Now, it may be that investigation needs to be done on these existing instances before it can be decided what to do with them.

In the meantime, let us create a new instance (from the EM "test" or wherever) and look at the flow trace....

IP14_13

... this is strange ! The Service (WS endpoint) has been invoked but the process itself has not... what is happening here ?

Let us look at the state of the composite and the process in EM....

IP14_14

... the process is clearly "Up".

IP14_15

...and so is the composite.

Very strange !

Examine the Composite

Maybe there is a problem with the composite itself. The best way to check this is to export the deployed composite from EM....

IP14_16

IP14_17

IP14_18

...save the exported composite and open it up....

IP14_19

...and let us look at the source, in particular the BPM component....

IP14_20

That looks like the culprit.... the BPM component has been suspended within the composite.

Why is this ? This is standard behavior, if all instances have not been patched then new instances cannot be created.

Resume the Suspended Instances

Let us resume (in bulk) all the suspended instances from the BPM Workspace....

IP14_21

IP14_22

That has worked....

IP14_23

no "Pending Components"....

IP14_24

...and no suspended process instances.

Let us try creating a new instance (from EM for example)...

IP14_25

...it works !

(Wrong) Conclusion !

That's all we need to do then, patch all the existing instances and we can create new instances.

Well.... not really, what if for business reasons we can't patch all the suspended instances until we've investigated them individually but we still need to create new instances ?

Look Deeper

Let us create some more suspended instances by deploying with another embedded subprocess (same Revision ID and "keep instances running")....

IP14_26

...which is compatible.

And deploying again (same Revision ID and "keep instances running") after removing the embedded subprocess....

IP14_27

...which is an incompatible change....

IP14_28

Now, we can't simply patch all the suspended instances this time because we need to investigate them individually first.... what can we do ?

Find the MBean

The property we found earlier in the extracted composite....

<bpel.config.suspend>

...is also available in an MBean....

Within the Enterprise Manger navigate to the "System MBean Browser"....

IP14_29

...and within this, navigate to....

<Application Defined MBeans><oracle.soa.config><Server: server-name><SCAComposite><composite-name><SCAComposite.SCAComponent><component-name>

...where the text in red is relevant to your server/composite/component.

IP14_33

...Expand attribute 14...

IP14_30

IP14_31

...there it is !

We can set it to "false" here and "apply" the change.

Creating a new process instance (in EM)...

IP14_32

...works !

NB: This attribute change will not survive a server restart !

...unless the attribute is persisted... the reason for this is that the state is persisted in MDS and on server restart this state is reloaded from MDS and overwrites any changes made. How do we persist this change ?

Let us go back to the MBean Browser and choose the "Operations" tab, in it we can choose the "save" operation...

IP14_34

...click on "save" and then on the "Invoke" button....

IP14_35

...and now the attribute is persisted to MDS....

IP14_36

 

(Another Wrong) Conclusion !

So that's it... all we need to do is to change the attribute to "false" in the MBean and we're good to go.

In fact what we have learned is that, if the change is compatible then all instances are automatically patched and we have nothing to worry about.

Not exactly.

Automatic Patching Limit

I know of several customers having encountered this.

Essentially, only 100 instances are patched automatically for a compatible change.

You may think your change is compatible and you may expect all the instances to be patched, but you may be wrong.

You should always check, in the BPM Workspace or via the API, for the success or otherwise of the deployment and instance patching.

What possible justification can there be for this limit of 100 ?

On redeployment the BPM engine will attempt to patch all instances in one transaction. In the past, before the limit was implemented, some customers ran into problems with OOMs, and rollbacks etc... As a result a (seemingly arbitrary) limit of 100 was implemented to avoid these issues.

You must be aware that if you have more than 100 running instances of the composite then not all of the instances will be automatically patched. You will need to patch the remaining instances either individually or in bulk from either the BPM Workspace or via the API.

Summary

Instance patching is a very powerful feature of BPM 11g (and 12c) but customers need to be aware of how it works and what limitations there are to it. In this blog post we have delved deeper into the workings of instance patching and provided mechanisms for manipulating it as a customer's business requires.

Mark Foster

Director

Director - Oracle A-Team


Previous Post

OAM11g --- The Redirect Infinite Loop

Tim Melander | 3 min read

Next Post


Part 2: Custom Login and Logout with Detached Credential Collector (DCC)

Tim Melander | 20 min read