Applications

In the previous blog post, we discussed the overall architectural changes that have been made in Oracle E-Business Suite 12.2 as well as the ability to be able to patch the system while it’s up, with users still online.  Oracle E-Business Suite AD Online Patching (ADOP) only works because the fundamental mechanism that allows this is using the Oracle Database feature, Edition Based Redefinition (EBR).  The first step in being able to use EBR is to edition base a schema.  The APPS schema as well as other application schemas are edition enabled out of the box with EBS 12.2.  Additionally, you will also need to remember to edition enable your custom schema, also known as the custom top.  With EBR, database objects can be “editioned” (versioned) and the following list shows what can or cannot be editioned.

✅ FUNCTIONS

✅ LIBRARY

✅ PACKAGE

✅ PACKAGE BODY

✅ PROCEDURE

✅ SQL TRANSLATION PROFILE

✅ SYNONYM

✅ TRIGGER

✅ TYPE

✅ TYPE BODY VIEW

❌ TABLE

❌ INDEX

❌ MATERIALIZED VIEW

As we can see objects that cannot be editioned are those that take up data storage such as tables, indexes, and materialized views.  These objects on the other hand will make use of editioning views and crossedition triggers.  The editioned view will only expose the columns and data of the table that are allowed for the current edition.  The table data itself will be maintained through the use of crossedition triggers.  The editioning view name will include a suffix using the hashtag symbol.  Any custom code must reference the editioning view or preferably the synonym but never the table name directly.  Accessing tables directly could potentially lead to incorrect data results!  The following diagram will demonstrate the concept of an editioned view on a table in Oracle E-Business Suite 12.2.

What does EBR mean for developers that might be working on EBS customizations?  Well, it means a fundamental shift in how they are accustomed to not only writing code in the database but in the manner in which it will need to be deployed.  They must follow one of two options, the full development standards to apply these customizations as an online patch or only a minimal amount of development standards to apply it as a downtime patch.  My Oracle Support document ID, 1577661.1, Developing and Deploying Customizations in Oracle E-Business Suite Release 12.2, explains all of this in great detail.

Finally, we need to be cognizant of old editions that might start to stack up in the database as that might lead to performance problems with the system.  Cleaning up of these old editions is typically done automatically during the cleanup phase of AD Online patching but in some cases you may need to cleanup those up manually.  Oracle typically recommends keeping no more than 25 editions before enacting a manual cleanup cycle.  You can perform a maximum cleanup by using the cleanup mode full option (e.g. adop phase=cleanup cleanup_mode=full).  By keeping database editions to a minimum you are able to recover the maximum amount of space while averting any performance issues with your system.