Soa 12.2.1 was released recently. Let us see how to implement one of the new feature of this release – Patching Running instances of composites.
With this feature, we can make selective modifications to running composites’ base code, create a patch using JDeveloper. Using WLST commands, we can apply the patch to server. Long running instances / Recoverable faulted instances of patched composites will pick up the changes.
As per Oracle documentation, following changes are allowed
- Non-schema related XSLT changes, changes to fault policy, sensor data, and analytics data.
- Compatible BPEL changes such as transformation activity, assign operations, etc.
- JCA Adapter configuration properties.
In this post, we will take the case of simple BPEL assignment to show case this feature.
We cannot use a SOA Server installed via Quick Installation (which uses run time File based repository). We need to have a runtime DB based MDS which supports versioning.
If we have full installation (Admin Server, separate managed server for SOA, OSB, etc) , we don’t need to do any extra work to explore this feature.
If we have SOA Quick Installation , we need to do the following
Install a Database
Sample SOA Application Development
Let us a create a SOA Application with an Asynchronous BPEL Component.
Add an “Assign” activity between receive and callback.
Add a copy rule to copy from input to output variable using concat function. To simulate run time error, misspell concat function.
Deploy the process. Ensure you are deploying to SOA Server configured with compact domain.
As part of the build we will be getting a warning but still the deployment would go through.
warning: Unknown function "contact_err" used in <bpel:from>
Test the composite. As the function is not found, the instance will be faulted and will be in recovery mode.
We will recover the instance after applying the patch.
To make changes and create a patch, we need to start JDeveloper in “SOA Patch Developer” role. Go to “Tools->Switch Roles->SOA Patch Developer” to switch roles.
In Patch Developer mode, by default, JDeveloper will allow us only to select/edit components that are compatible with patching process.
Edit the “assign” activity to correct the function name and save it. A patch.xml file will be created in SCA-INF folder which tracks the changes made in this mode.
Once all errors are corrected,we can create patch by selecting “Deploy -> <projectname>” option. This will create a SAR archive. There will no option to change revision number. This will create a sca_<projectname>_patch.jar file in deploy directory.
Validating and Applying patch
Patch can be applied using WLST command.
From a command prompt run “<home>/oracle_common/common/bin/wlst.cmd”
Connect to Weblogic instance using connect(username,password,url) function.
Validate the patch using sca_validatePatch command
sca_validatePatch('http://localhost:7001', 'weblogic', 'oracle123', 'F:\SOA122Wks\mywork\SOA122Features\PatchInstance\deploy\sca_PatchInstance_patch.jar')
We should get a “Composite Patch has been validated successfully” message.
We can now apply the patch using sca_patchComposite command
sca_patchComposite('http://localhost:7001', 'weblogic', 'oracle123', 'F:\SOA122Wks\mywork\SOA122Features\PatchInstance\deploy\sca_PatchInstance_patch.jar')
We should get “Composite has been patched successfully”.
Testing the patch
Login to EM. Click on “Recovery” and click “Retry” to retry the instance. With the application of patch, the instance should go through fine.
Deleting Patch File
When we switch back to Developer role, JDeveloper will give the following notification. As we are done with the patching, we can delete the patch file