The Gist of EBS Customizations
Preparing customizations is a relevant and significant step when talking about an Oracle E-Business Suite (EBS) upgrade to Release 12.2.
One thing to consider throughout this post is the fact that customizations in 12.1 versus customizations in 12.2 are irrevocably different. In general, customizations are extensions or changes in the business flows that you can implement to the functional products that are part of EBS.
With that in mind, these customizations can be implemented in several technologies and can be either installed in the middle tier or in the database, or both. When discussing database customizations, these can be deployed in custom schemas or in EBS schemas, and could have dependencies on EBS code.
Next is a visual depiction of how you would deploy customizations in EBS 12.1. In the application tier, the customizations live with the application code and in the database you would have custom code deployed with the application code and application schemas. Another option would be to have a custom schema with custom code and the database in a data model.
In the application tier, you can deploy customizations like forms, reports, system scripts for the application tier, etc.
In EBS R12.2, it’s a different story. Here, Oracle decided to implement a new feature called Online Patching. This new feature requires some changes at the architectural level, which is why you need to prepare your customizations.
Before diving into moving customizations when upgrading to Oracle EBS R12.2, let’s first clear the air about Online Patching. Online Patching is the ability to patch a running system without having to take the system down for a significant amount of time while the patches are applied.
When you install or when you deploy in a 12.2 environment, on the application tier, you end up with two file systems. They are two completely separated and isolated file systems that contain all the application code as well as the Fusion Middleware code that runs this code.
In the database, there is a specific feature called Edition-Based Redefinition (EBR) that allows EBS clients to efficiently store multiple copies of applications in the same database. It provides an isolation mechanism called Edition that allows the pre-upgrade and post-upgrade schemas to coexist.
Preparing to Move Customizations
Now, on to the topic of this blog. Customizations in 12.2, in order to be patched online, have to comply with some online patching development standards and patching procedures; to learn more about these compliance items, download our latest infographic for more details.
Once you move to EBS 12.2, you end up with an architecture where, in the application tier, you will have two complete copies of the application code as well as the Fusion Middleware. Your custom code will live with the application top, similar to how it was in 12.1, but deployed in both file systems.
The Online Patching feature will do its job to ensure it automatically keeps your customization code, as well as the application code, in sync.
To prepare your customizations for the R12.2 upgrade, you should keep in mind that there are two standard compliance levels. One is a minimal set of required standards where the code and customizations have to meet specific requirements to operate adequately in Oracle EBS R12.2. If your customizations do not meet these minimum standards, the custom code will most likely end up being flagged as invalid.
The recommended option is to have your customizations be fully compliant with Online Patching. While it does require additional standards than the minimum requirements, you will rest assured that your customizations are fully compliant and you will be able to patch your customizations online without an issue.
The decision between one and the other is based on the importance of minimizing downtime. In that regard, if you’re interested in minimizing the downtime of your application’s maintenance, the go-to recommendation is to be fully compliant. Regardless of the decision, EBS patches are always online.
Once a decision has been made, the actual work begins. You should:
- Create a thorough list of all of your customizations,
- Perform an analysis to understand the type of code remediation required for either minimal standards or full compliance,
- Deploy your customizations into your production environment.
Easier said than done, this process requires a high level of expertise that is rooted in profound knowledge of EBS upgrade projects. Oracle does provide tools like Online Patching Readiness reports that flag violations so they can be addressed. Make sure to run these reports before the R12.2 upgrade as they are applicable during the preparation of the upgrade.
The EBS Upgrade Effort
The upgrade effort, especially one like the one to Oracle EBS R12.2 is a major undertaking that needs to be carefully planned and strategized for as it involves different areas like CEMLI Remediation, Archive and Purge, preparing the database, and much more.
Unfortunately, with the clock ticking and a looming expiration date for Premier Support of December 2021, the time to act and perform the upgrade is now, before time runs out.
Premier Support is Oracle’s support offering that ensures your EBS gets updates, fixes, and security patches delivered to your EBS system in an ongoing, periodic fashion, ensuring your system and investment are protected. It also ensures that your system has the latest features and capabilities enabled, optimizing your work and supporting your mission-critical business tasks.
Expert assistance during the upgrade process to R12.2 is the safest bet to guarantee you get it done in time and successfully. There are numerous approaches you can leverage to accommodate your priorities in terms of budget, risks, and knowledge transfer, making it easier for you to take action as soon as possible.