Keeping on top of techstack patching with E Business Suite

Keeping on top of techstack patching with eBusiness Suite

Once an eBusiness Suite environment is installed, configured and up and running, patches will typically be applied in the following circumstances:

1. To fix a specific bug or problem
2. Mandatory patches for legislative or legal reasons
3. To keep the system meeting the minimum required support levels
4. Security patching
5. To activate new features or modules
6. Planned upgrade

These are all to one degree or another reactive patching exercises in response to a customer’s explicitly stated requirements.

However, all good Apps DBAs should also be recommending and performing proactive patching on the technology stack components of eBusiness Suite. This keeps the ‘nuts and bolts’ of the system up-to-date with all of the latest features and bug fixes.

Whenever there is a planned patching exercise or other maintenance activities on a system, I always check to see whether there are new techstack patches that can or should be included as well. I then present my findings to the customer with my recommendations and rationale.

• If the customer approves, then the additional patches are applied and tested along with the planned patches
• (Or) If the customer wants to only apply a specific fix for a specific issue and does not want to widen the scope, then that is fine too!

Identifying new technology stack patches

The sort of patches we are interested in are not those that directly impact the functionality of the application. Oracle release family pack updates, minipacks, rollup patches and Recommended Patch Collections (RPCs) for the ‘transactional’ modules but those sorts of updates require careful planning and are not something that can just be tagged on to something else.

What we are interested in are the techstack patches, and there are some useful notes on My Oracle Support that I keep as favourites and check. I have outlined these below for you:

eBusiness Suite 12.1

eBusiness Suite 12.2

Happily, this exercise is much easier for eBusiness Suite 12.2 as Oracle bundles up this information into a single note:

• Oracle E-Business Suite Release 12.2: Consolidated List of Patches and Technology Bug Fixes (Doc ID 1594274.1).

Within Oracle eBusiness Suite itself, the Patch Wizard can be used to list the latest recommended patches for the core technology products and transactional modules, however this only lists eBusiness Suite application patches and not those for the database or application server.

The first time going through all of these Notes can take some time, and the list of patches to apply can be quite large – but take heart! After the first iteration, proactively checking these Notes on a periodic basis will mean that you won’t fall too far behind with these patches in future and catching up with the latest ones becomes a doddle with only one or two to do (and sometimes there are no new ones to do).

Why apply these patches at all?

There are several advantages to applying these patches on a periodic, proactive, ad hoc basis:

• Known Oracle bugs in the current version are fixed
• Easier to get Oracle Support to respond to Service Requests, only if it can be proven that the system already has all of the recommended technology stack patches applied to it
• Uptake of the latest security fixes for the technology stack
• Uptake of the latest performance fixes for the technology stack
• Ensures that the system is already compliant with any client-side rollouts of later versions of Windows operating systems, Java versions, Office versions or Internet Explorer versions
• Proactively applied technology stack patches that will one day be mandatory pre-requisites for future functional patches – this is especially true for HCM RUP patches
• Looks great to auditors!
• Reduces the effort and downtime of future upgrade projects by starting from a later point in the current environment
• Even if the customer is particularly risk-adverse and only wants to apply patches to fix specific problems in a reactive way, the effort is still not wasted and the ‘missing’ techstack patches can be documented for the future!

Of course introducing any sort of change carries risk and there could be new bugs introduced into the system that were not there before. However, a robust testing strategy should be able to capture these before they make it to the live environment – and if the system is being tested anyway for some planned patches, there is no additional testing effort that is required!

At Claremont, we pride ourselves on our proactivity and implement this process as a matter of course; as a result, we achieve stable systems and happy customers (as evidenced by our customer satisfaction scores!)