Patching SOA Composite Instances in Oracle 12.2.1 by Dennis

Introduction

Composite Instance Patching is a new feature introduced in 12.2.1 that allows compatible changes to be made to a SOA composite definition and be applied to long-running active instances. The feature enables you to patch running instances of a composite and recover faulted instances after patching the runtime. You can deliver urgent composite fixes and make compatible/allowed changes that are picked up with long-running instances without aborting them. If a patched running instance comes across a business process that has been fixed by the patch, say a BPEL transformation, then it picks up the fixes applied to the business process.

Prior to 12.2.1, there was no way to make small changes to a composite and have in-flight instances, which could be long running for days/months, or error hospital instances see those changes. The alternatives were to either redeploy an existing composite revision but that causes long running instances to stop processing, or, to create a new composite revision which does preserve existing running instances but those instances do not see the changes introduced in the new revision. Now, with the new Composite Instance Patching feature in 12.2.1, critical fixes can be applied in a timely fashion and have them take effect immediately which is a unique differentiator for Oracle SOA Suite.

In this article I will (1) highlight some of the compatible changes that can be made to a composite, (2) discuss the enhancements to JDeveloper that allow you to quickly and easily design the patch without worrying about making invalid modifications in the composite patch, and (3) outline the steps used to build, validate, and deploy the composite instance patch to the SOA runtime.

Compatible Composite Changes

As mentioned above, there are only a limited set of modifications that can be made to a composite and deemed compatible with running instances.  Some of the compatible changes that you can make include:

• Non-schema related XSLT changes
• Changes to fault policy, sensor data, and analytics data
• Compatible BPEL changes such as sync/async invoke, transformation activity, assign operations, etc.
• JCA Adapter configuration properties
• Modifications of token values in composite references

while some of the incompatible changes that you cannot make include:

• Deleting or renaming composite artifacts
• Updating binding properties
• Changes to a WSDL and Schema definition
• Changes to XQuery mappings
• Changes to BPEL receive inputs, structured activities, assign mapper source/target/skip conditions

Do not worry about knowing exactly what constitutes a compatible or incompatible change since, as we shall see, all those rules are accounted for in a new SOA Patch Developer mode within JDeveloper which automatically disables changes that cannot be made when constructing the patch.

Composite Instance Patch Development in JDeveloper

To simplify the creation of a composite instance patch a number of enhancements have been made to the JDeveloper tooling.  The first change is the introduction of a new new SOA Patch Developer role.  When launching JDeveloper you must first select the role that matches your requirements. Read the complete article here.

SOA & BPM Partner Community

For regular information on Oracle SOA Suite become a member in the SOA & BPM Partner Community for registration please visit www.oracle.com/goto/emea/soa (OPN account required) If you need support with your account please contact the Oracle Partner Business Center.

Blog Twitter LinkedIn Facebook Wiki