X

The Latest Technology Stack News Directly from EBS Development

Upgrading to EBS 12.2 With a Non-APPS Schema

Steven Chan
Senior Director

An Oracle database stores the objects associated with a single installation of Oracle E-Business Suite. Product code objects are stored in the APPS schema; product data objects are stored in the relevant base product schemas. Product code objects include packages, procedures, functions, triggers, views, materialized views, java classes, and queues.

EBS APPS schema

What does the APPS schema do?

The APPS schema has access to the complete Oracle E-Business Suite data model. Oracle E-Business Suite responsibilities connect to an APPS schema, and the environment variable FNDNAM is set to the name of the APPS schema. The APPS schema owns all the code objects for the Oracle E-Business Suite, and has access to all data objects. There is one APPS schema for every product installation group.

Utilizing a single schema that has access to all objects avoids cross-product dependencies, and creates a hub-and-spoke access model rather than the spider web model that would otherwise be needed. The APPS schema also improves the reliability of and reduces the time needed for installation, upgrading, and patching, by eliminating the need for cross-product grants and synonyms.

It wasn't always "APPS"

Older versions of EBS were delivered with a different default schema name: APPS_FND.  Some older versions even allowed you to override the default name of the schema prior to installation.

Recent versions of Oracle E-Business Suite use the APPS schema by
default.  It is not possible to change the name of the APPS schema.

Hardcoded references to APPS are not permitted

We have many upgrade-related scripts, tools, and utilities.  All of these standard EBS tools are required to handle any EBS schema name, regardless of whether it is named APPS, APPS_FND, or something else.  There should be no hardcoded references to, say, the APPS schema. This development standard is enforced by regular automated scans of the entire EBS source code.

Earlier versions of some EBS upgrade scripts may have had hardcoded references to APPS.  Running an upgrade to, say, EBS 12.2 against an EBS environment with an EBS schema named APPS_FND would fail in certain circumstances.  This is not expected behavior.  We would regard that as a bug that needs to be fixed immediately.

All E-Business Suite scripts with hardcoded APPS schema references have since been superceded by later versions that can handle any EBS schema names.  To avoid issues with non-standard schema names, make sure that you're using the latest Rapid Install and AD/TXK utilities.  Click on the "Upgrade Recommendations" link in the sidebar of this site for pointers to the latest utilities.

Known issues

It is possible to integrate E-Business Suite environments with Oracle Identity Manager (OIM), which offers connectors that handle user provisioning.  Those OIM connection scripts still contain hardcoded references to the APPS schema (bug 24613821). 

Getting support

If you encounter any issues with non-standard EBS schema names, please log a formal Service Request with Oracle Support. You are welcome to drop me a line or post a comment here, too, if your schema-related SR gets stuck in the pipeline for some reason.

References

 

Join the discussion

Comments ( 6 )
  • nshah Tuesday, November 1, 2016

    Hi Steven,

    I met with you in UKOUG 2012 and raised exactly this point. Ever since, waiting for a permanent solution that until date, I didn't see. So many of scripts in application patches still come with hardcoded APPS schema name and we are using apps_appl as our schema. We face big issues and sometimes funny situations where oracle support SR engineers are not able to grasp why are we using non-APPS schema name and they try to raise a bug with development to know how one can use a non-standard apps schema as if they don't even know it is possible.

    Even latest upgrade scripts are still having hardcoded apps schema name. We recently did couple of test upgrades from 12.1.3 to 12.2.5 with latest rapidinstall version and latest tk/tk and faced at least dozens of issues due to having APPS.OBJECTNAME hardcoded in the scripts.

    We are suffering from this issue from decades. We urge to find a way to create APPS user and move each and everything from APPS_APPL to APPS user. Is there any certified way to do it?

    Hope to see your comments on it.

    Regards, Naeem


  • Steven Chan Tuesday, November 1, 2016

    Hello, Naeem,

    There are no certified or documented methods of changing schema names.

    I am sorry to hear that you are still encountering issues with this. Can you forward SR numbers so that we can assist?

    Regards,

    Steven


  • Matt Snare Wednesday, November 16, 2016

    Hi Steven,

    Likewise I have a client that has APPS_FND from back in the 10.7 days, and upgrades are a real headache for them. Our recent 11.5.10.2 -> 12.2.5 upgrade revealed 26 individual bugs that needed patches delivered by Oracle Development for example. Perhaps the internal scanning tool detects some, but some hard-coded references still remain, as does the odd data type bug (say varchar2(4) assuming the value to be APPS for example).

    We have these bugs resolved for 12.2.5 now but it was an amazingly lengthy ordeal obtaining these fixes.

    MOS note 167824.1 mentions that a long time ago there was a supported migration path for APPS schemas but has since been lost. It would be really beneficial to customers (including mine of course!) if such a migration were developed for current versions of EBS; this issue is always the number one problem for me when considering each EBS upgrade.

    Cheers,

    Matt Snare.


  • Naeem Wednesday, November 16, 2016

    Hi Matt,

    This is exactly the pain I was talking about. Upgrades and sometimes small patches or diagnostic scripts (e.g. rda) has hardcoded apps schema name that we need to fix before using it.

    Regarding migration from non-standard apps schema name to APPS schema, I believe it could prove to be another nightmare and the reason is that we are making this fix since long and thus have so many hardcoded names for our schema (APPS_APPL.object_name).

    I suggest to send this info across to all development teams to strictly avoid using hardcoded name and all developers MUST be on the same page.

    Thanks, Naeem


  • Steven Chan Wednesday, November 16, 2016

    Naeem, Matt,

    I am sorry that you've struggled with that. It is frustrating for all of us, and we are trying hard to do better in this area. As you've discovered, it is difficult for automated tools to ferret out all of the possible places where there might be hardcoded schema references.

    Please send me emails with Service Request numbers for the issues you encountered respectively. I can check that the patches produced for your reported issues are included in the main 12.2 codeline for future updates. That will ensure that others in the same boat will have an easier time of it downstream.

    Regards,

    Steven


  • Susmit Thursday, August 10, 2017
    Hi Steven,

    Another issue we got while Running American English upgrade driver.
    cz13973852.sql failed for same reason. There is a MOS Note:- Conversion Of APPS_FND Schema To APPS Schema (Doc ID 2170341.1). However it asks to apply some Code Line C patch:- Patch 24320843:R12.CZ.C.

    We are Not yet in 12.2.x as we are applying upgrade driver. How can we apply this patch?
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.