An Insight into Oracle Fusion Patching and Testing ReadinessTimothy Aegoori
Listen on the go!
Traditionally in the Software Development Life Cycle (SDLC), a patch is a fix, a quick repair job, or a piece of programming designed to resolve functionality issues, improve security, and add new features. Throughout its lifetime, the software gets frequent errors called bugs which produce unexpected results, and a patch is an immediate fix to those problems.
Applying modifications to the Oracle Fusion Applications environment is called Oracle Patching. We need patching to solve security vulnerabilities, improve performance, fix bugs, and add new features. Continuous patch application minimizes incidents where bugs are encountered. It ensures the instance of Oracle Fusion Applications is performing efficiently and thus improves security.
Oracle Fusion Patch Categories
Oracle Fusion application patches fall under two different categories as mentioned below.
Oracle Fusion Patching Tools
Based on the patching categories and patch types there are various tools to apply. Below is the table that describes, the patch category, patch types, and tools applicable.
|Critical Patch Updates (CPU)||OPatch|
|Technical Patch Bundle (P4FA)||FASPOT under P4FA section|
|Functional One-Off Patch||As described in the Apply One-Off Patches section – “Fusion Applications Patch Manager”|
|Functional Patch Bundle (BP)||As described in the Apply a Functional Patch Bundle section – “Fusion Applications Patch Manager “|
|Aggregated One-Off||As described in the Apply a Functional Patch Bundle section— “Fusion Applications Patch Manager”|
OPatch: It is an Oracle utility tool that helps organizations with the process of applying patches to Oracle’s software and rolling back.
FASPOT: FASPOT is used to arrange the installation of the P4FA bundle patches. It has certain guided preparation steps to follow while applying bundle patches.
FASPOT applies the patches in the below listed categories:
- Fusion Middleware Components (including ODI, atgpf, oracle common, webtier, SOA, BI, WebCenter, ECM, SES, wls)
- Identity and Access Management (including OHS and OID)
The installation of RDBMS patches is not within the scope of FASPOT and must be installed manually by Database Administrators (DBAs).
Oracle Fusion Applications Patch Manager (Patch Manager)- The basic function of a Patch Manager is to apply functional standard patches, and bundle patches. It can also validate whether patches can be applied and generate patching reports or not. Patch Manager provides a command-line interface to systemize its patching functions.
Skill, Key Roles, and Expertise Needed to apply the Oracle Patches
To apply Oracle fusion functional or technical patches, certain skill set and knowledge is required as mentioned in the below table.
|Roles/skill||Technical knowledge areas|
|A Fusion Applications administrator||Oracle Fusion Application installation(s) knowledge|
|A Database administrator||WebLogic and SOA familiarity|
|An Identity Management (IDM) expert||Database knowledge|
|Identity Management knowledge|
|Relevant operating system knowledge (Linux, etc.)|
Key activities: when planning a patching activity for Oracle Fusion Applications environment
- Patch Planning
- Patching Tools are set
- System Backup planning
- Impact Analysis of the patches
- Patch Test Planning.
Summary describing when to apply the patches
|Type||One-Offs||Aggregated one offs (AOO)||CPU||Patch Bundles|
|Technical||Apply only when there is critical issue, else wait for patch bundle release||Not applicable||Upon release apply Immediately||Ideally apply every month, and less frequently than every month is not recommended.|
|Functional||Apply only when there is critical issue, else wait for patch bundle release||Apply only when project timelines impacted else wait for update bundle||Not Applicable||Apply Monthly upon release or choose alternates based on the requirements|
Overview of Oracle Patch releases
For every quarter, Oracle releases a quarterly patch update cadence through the Oracle applications cloud console. Here the information on software and hardware patch updates are specified and are applicable for the environments mentioned below.
- New Features/Functions
- BUG Fixes
- Provide Infrastructure updates
Monthly Updates from Oracle: Optional
Oracle notifies all its partners service admins about the updates included in each patch. For minor patch releases, Oracle typically provides a one-week advance notification before patching the test environment, and for major update releases, Oracle provides a two-month advance notification.
A document with the detailed information is shared with the admin informing about the released patches and the same get uploaded on the Oracle Cloud Release Readiness website. The information on the website includes announcements, new features, changes in functional behaviour, and bug fixes.
Website link: https://cloud.oracle.com/saas/readiness/overview
Quarterly Updates: Mandatory
In a calendar year, there will be four feature/function updates to notify partners about the schedule of the quarterly update period.
Quarterly updates may include:
- New and enhanced features/ functions
- National Language Support (NLS) updates applicable for all installed language packs
- Fixes for all reported issues linked with Oracle Cloud Applications
- Fixes for all reported issues linked with Oracle Transactional Business Intelligence (OTBI) and Oracle Fusion Middleware. Sometimes the middleware updates are even referred to as P4FA updates
What is Opt-In and Opt-in Expiration?
Opt-In: Based on the functionality and features, the release of the quarterly patch has two options – Enabled and Disabled.
Enabled means the availability of the patch release to the end-user immediately once oracle pushes the update, without any human intervene. Disabled means the client must take step by step action to make the patch release available to them.
Opt-In Expiration: Feature which automatically makes the Disabled options of Opt-in Enabled for the future patch release updates. The disabled features of previous releases get automatically enabled in the oracle cloud application instance.
Managing Oracle Cloud Fusion Patching with Cigniti’s Best Practices and Guidelines
Most enterprise organizations are adopting cloud-based IT operations/administration and currently the market is in the transformation phase. Oracle fusion cloud is one of the top ERP solutions for big and mid-size enterprises.
As mentioned above, every quarter Oracle provides software and hardware updates for its partner Oracle cloud environments through patches.
We know, patching is the process to modify the Oracle Cloud Applications comprising new functionality, UI changes, customer enhancement requests, and bug fixes. As the updates are mandatory and inevitable, testing must be done to ensure whether all the enhanced functionalities are working according to the business operations of the organization or not. Testing is even needed to know, whether the changes have not impacted their BAU.
So, enterprise clients should complete testing, analyze the results, and raise issues with Oracle within a limited interval of time. Oracle opens the testing window for approx. 2 weeks only. Testing of the quarterly patch is a joint effort by IT/DEV, QA & BA’s, and it needs perfect coordination.
Below are a few fundamental requirements before testing begins.
- Quarterly Release Schedule: knowing the patch release date to plan for the quarterly patch testing
- What’s New: Regular check of the Oracle Cloud Readiness website to understand the updates on new features, capabilities, etc. So, one should timely check on the features and remain updated and identify the forthcoming updates, which also helps create the test cases.
- Opt-In Expiration: One should be aware of the features falling under the “Opt-In Expiration” to plan for testing in the next quarterly update.
- Test Case Readiness
- Regression: Common test cases with every quarterly patch
- Upgrade Specific: New Test cases specific to the quarterly patch, upcoming features, and capabilities in the quarterly patch
- Opt-In Expiration: Test cases for features automatically migrated to production from the previous release
- Quarterly Patch Application: Firstly, the Quarterly patch gets implemented in the Non-Production instance, and then it is done to the Production instance. You only have a two-week window to execute all the test cases before the patch gets applied to the PROD instance. And before the patch gets applied to PROD, all the executed test cases must PASS. In case of failure, a user should raise an Oracle SR and immediately put the PROD patch application on hold.
Cigniti has a unique way of approaching these testing challenges of the oracle fusion cloud. Below are the best practices that we follow to meet the oracle fusion patch testing schedule.
- Create a patch tracking sheet
- Analyze the patch impact on the applications and create a test plan accordingly.
- Types of patches to plan and apply
- Impact assessment of the patches
- Based on the quarterly patching schedule, prepare the test cases well in advance.
- Follow the Cigniti checklist for fusion cloud testing
Cigniti Patch Testing Check List
|Analyze Quarterly Updates||Available before 2 months of the release||QA Team||Follow the below link to review – |
|Create Test Plan||Week1||QA Team||Regression, patching specific test cases, and Opt in expiration scenario test cases|
|Review ||Week2||QA Team||Review in detail|
|Present the patching test coverage/plan and get it approved||Week2||Client BA’s||Client BA’s to approve the test plan|
|Create Manual Test cases||Week2 and week3||QA Team||Manual test cases to be enhanced or new manual test cases should be authored|
|Apply Patch in Test Environment||Based on the release date||Oracle||Oracle shares the instance downtime details generally two weeks prior to the quarterly patch application date|
|Manual and Automation Regression testing||Execute in 2 weeks window||QA Team||Test and update results with the stakeholders|
|Testing sign off/Review||Once after the execution is done||Client BA’s||In case the testing fails, raise an SR with Oracle to stop the quarterly patch from getting applied in the PROD instance|
|Apply Patch in Production||Based on the release date||Oracle||Oracle shares the instance downtime details generally two weeks prior to the quarterly patch application date|
|Production sanity checks||After applying the patch in production||Dev Team/Client BA’s||Dev to do the sanity check in prod or the client BA’s|
Need help? Schedule a discussion with our ERP Testing experts to get more insights into oracle fusion patching and testing readiness.