When was the last time you had to wait for active instances to fail before a process fix could be applied? I would guess not that long ago. Even if you get the fix applied, you still need to deal with the failed instances. To the rescue, SOA Suite 12.2.1 provides the ability to patch a long running instance without aborting the instance. There is a limited list of allowable changes that can be patched, the changes can be found in this Oracle blog post.
In this post, I will demonstrate how patching long running SOA instances is easily accomplished via FlexDeploy with absolutely no modifications to the deployment process. The FlexDeploy SOA Suite plugin executes the initial SOA process deployment and manages the patch deployment.
The PatchingTest process will utilize a wait activity to simulate a long running process and have a selectionFailure exception in the XSLT map that needs to be fixed. We will run the process twice, once to see the failure and a second time to patch the XSLT before the wait expires. The process looks like this:
Utilizing FlexDeploy, the PatchingTest process is built/deployed with a revision of 1.0 (FlexDeploy Project Version 1.0.11).
We can now run a couple of instances of the process and determine that one of the instances failed with a SelectionFailure.
There can be many instances of this process running and with this being a long running process, it would be nice to be able to fix any instances that haven’t reached the faulty xsl map. Looking at the process, it is easy to see that the namespace on the xpath expression is incorrect. Since this change is a non-schema based change, we can make the modification and utilize the composite patching feature of SOA Suite 12.2.1.
The first thing that needs to be done is to switch the role (Tools->Switch Roles) of JDeveloper from Studio Developer to SOA Patch Developer. Now we can edit the xsl map as shown below. Just a reminder that in patch mode, JDeveloper will control what can be modified.
Once the change is saved to your workspace, JDeveloper will create a new artifact (SOA/SCA-INF/patch.xml) that needs to be committed to your SCM along with the xsl change. Utilizing FlexDeploy again, the PatchingTest process is built/deployed. The SOA plugin will detect that a patch.xml artifact exists and build/deploy the patched composite with no changes to the deployment process.
Any long running instances for this process will complete with the XSL change and complete successfully. As you can see below, the instance 290002 was created at 1:02:39 and completed at 1:12:40. The fixed xsl map was deployed at 1:09 thus the instance completed successfully.
It should be noted that if you are patching any revision that isn’t the default revision, the patching process will make that patched revision the default revision and may not be what you expected.
And just like that you can patch long running SOA instances easily via FlexDeploy.
