Saturday Jul 16, 2011

E-Business Suite Technology Frequently Asked Questions (FAQ)

Last updated: February 21, 2013

Given changes to our blogging platform this year, it's gotten much harder to browse and locate previously-published articles on certain topics.  As a workaround, here's a FAQ to act as an index to our most-commonly referenced articles.

1. EBS Technology Stack Basics

Q: I'm completely new to Oracle E-Business Suite.  Where do I start?

A: There's a lot to learn, but don't get intimidated.  This article is a good starting point to understand key terms.  The latest EBS 12.1 documentation is hereThis article has pointers to good resources for beginners, including formal training from Oracle University.

Three tier architecture for EBS 12.0 and 12.1

Q: How can I keep current on EBS technology stack news?

A: We announce over 120 new certifications a year.  Stay current by monitoring or subscribing to this blog.  We publish roadmaps for upcoming certifications few times a year.  The latest is available here.

Q: Where can I find documentation for EBS technology stack components?

A:  Documentation for the EBS 12.1 is here; documentation for older releases is here.  Technology stack components that must be updated regularly are cross-referenced in these Note roadmaps:

Q: What are the latest E-Business Suite releases?

A: There are two types of EBS releases:  Rapid Installs and Release Update Packs.  Rapid Installs can be used to create a brand-new E-Business Suite environment.  Release Update Packs can only be applied on top of an existing environment.  The releases are:

Q:  What technology stack versions were included in the latest EBS releases?

A:  Here's a summary of the bundled technology stack components in the three EBS 12 Rapid Install releases that you can (and should) upgrade yourself as new versions become available.

2. Support Policies

Q: I'm having a problem.  How can I get help?

A: Sadly, this blog isn't the best place to get technical support.  For technical support resources and tips on logging Service Requests with Oracle Support, see this article.

Q: Is my third-party product supported with Oracle E-Business Suite?

A: We test specific Oracle products with the Oracle E-Business Suite.  This is called certification. We don't certify the E-Business Suite with third-party products, but you can certainly use them.  We distinguish between certification and support.  For details, see this article.

Q: What do I need to know about support for EBS 11i?

A: Premier Support ended on Nov. 30, 2010.  Extended Support began on Dec. 1, 2010.  New EBS 11i patches will be created for a minimum baseline environment.

Q: What do I need to know about EBS 12 Support dates and patching baselines?

A:  They're governed by two interlocking policy documents.  If you're running EBS 12, you must ensure that you're on these minimum patching baselines.

EBS Premier and Extended Support timelines

Q: How do Server Technologies (Database) support policies affect EBS environments?

A: Database support dates for Premier, Extended, and Sustaining support apply to E-Business Suite, too.  EBS users do not get any special exemptions from Oracle Database support dates.

Q: How do Fusion Middleware support policies affect EBS environments?

A:  Support policies for Fusion Middleware components used by EBS are a bit more complicated.  See this article for details.

3. Upgrades and Migrations

Q: I want to upgrade from EBS 11i to 12.  Where do I start?

    Q: I need to migrate my server to a different platform.  Where do I start?

    A: Verify that your target platforms are certified.  Plan your migration carefully.  Evaluate available tools for the job, including the Transportable Database process or Transportable Tablespaces.

    Q: I plan to upgrade EBS and migrate my server platforms.   Which do I do first, and what tools can I use?

    A: In general, migrating your database server to faster hardware will make your EBS upgrades faster.  There are more considerations for different endian platforms.  For more details, see this whitepaper on best practices.

    4. EBS System Maintenance

    Q: My E-Business Suite environment has slowed down.  What can I do?
    A: Start here.  Power users will love the additional tweaks and tips referenced in this article.

    Q: How can I reduce my maintenance downtimes?
    A: There are seven ways to reduce your patching downtimes.  EBS 12 users can also optimize AutoConfig execution and run AutoConfig in parallel.

    Q: What resources are available to help me test my environment?

    A: Testing is vital; your EBS environment is unique.  You can use testing tools like the Oracle Application Testing Suite.  We provide Test Starter Kits for older tools such as WinRunner and QuickTest Professional, too.

    Q: What's the best strategy for maintaining my environment?

    A: Apply EBS and technology stack updates to your environment in this order of priority.

    5. General Certifications

    Q: Is <version X> of <component Y> certified with the E-Business Suite?

    A: Check this one-page summary.  If what you're looking for isn't listed, check the official certification database on My Oracle Support.

    Q: When will the next version of <something> be released or certified with EBS?

    A:  Oracle's Revenue Recognition rules prohibit us from discussing certification and release dates.  And, besides, it's just unwise for us to speculate about dates.  This is why.

    Q: Is my third-party product supported with Oracle E-Business Suite?

    A: We test specific Oracle products with the Oracle E-Business Suite.  This is called certification. We don't certify the E-Business Suite with third-party products, but you can certainly use them

    Wednesday Jun 15, 2011

    OAUG/Collaborate Recap: Best Practices for E-Business Suite Performance Tuning

    [June 24, 2011 Update: Added link to PDF version]

    We have an Applications Performance Group whose raison-d'etre is to ensure that the E-Business Suite runs at peak performance in all circumstances.  This team has helped tune the E-Business Suite environments of world's largest companies to handle staggering amounts of transactional volume in multi-terabyte databases.  This group also publishes our official Oracle Apps benchmarks, white papers, and performance metrics.

    Isam Alyousfi and Lester Gutierrez are key members of our Applications Performance Group.  They recently presented their popular session covering performance tuning tips for all layers of the E-Business Suite at OAUG/Collaborate earlier this year.  It's available for download here:

    EBS Architecture diagram from a performance perspective

    This sprawling presentation covers:

    • Performance-oriented architectural overview of the E-Business Suite, with drilldowns to key techstack modules
    • Methodology for approaching performance issues, including isolation of performance problems within a particular area (e.g. database vs. application tier)
    • Comprehensive list of performance-related data to gather, including SQL tuning, PL/SQL Tuning, Reports Tracing, Database tuning, Forms tuning, Middle tier tuning
    • Methods for conducting root-cause analysis for performance issues
    • Methods for selecting the right diagnostics for particular classes of performance issues
    • Tuning the Applications tier:  Forms, OC4J/JVM, CPU and response time issues, garbage collection tuning, handling OutOfMemoryErrors and memory leaks, client process CPU drains
    • Tuning the Concurrent Manager: cache size, dedicated concurrent managers, FND table purging, workload management tips, transaction managers for synchronous online processing
    • Tuning the Client and Network: minimizing browser footprints, network routing issues, packet loss
    • Tuning the Database: mandatory init.ora settings, required performance patches, use of key database features like Auto Memory Management, conversion to the Oracle Applications Tablespace Model (OATM), I/O optimization, statistics gathering, establishing baselines for different workloads, using SQL Performance Analyzer and SQL Plan Management, AWR reviews, DB Console, TKPROF, 11g performance-related enhancements
    • Tuning EBS products: Release Update Pack recommendations, performance-related product patches, Workflow best practices, purging and archiving, runtime performance testing tips

    This presentation is chock full of tips, pointers, and hard-won knowledge.  It represents the distillation of countless performance-related Service Requests and customer escalations.  If you're grappling with performance issues in your environment, or simply trying to squeeze more performance out of existing hardware, I'd strongly recommend downloading this presentation.

    Related Articles

    Friday May 13, 2011

    New Whitepaper: Extending E-Business Suite 12.1.3 using Oracle Application Express

    I'm pleased to announce the availability of a new whitepaper:

    • Extending Oracle E-Business Suite Release 12 using Oracle Application Express (APEX) (Note 1306563.1)
    Oracle Application Express APEX screenshot

    It's possible to personalize the E-Business Suite, but there may be situations where personalizations aren't sufficient to meet your requirements. In these scenarios, Oracle Application Express, also known as Oracle APEX, is an option for creating supplemental applications that can be integrated with your Oracle E-Business Suite instance.

    This new whitepaper outlines how to extend Oracle E-Business Suite 12.1.3 (and higher) functionality using Oracle Application Express. Recommended architecture and security considerations are discussed in detail.

    You can also find the whitepaper on the APEX OTN Site > Learn More > Technical Information and White Papers > Extending Oracle E-Business Suite Release 12 using Oracle Application Express (PDF).

    Related Articles

    Wednesday Feb 09, 2011

    New Whitepaper: Upgrading EBS 11i Forms + OA Framework Personalizations to EBS 12

    Personalizations are -- and have always been -- one of the safest and most upgradable ways to "customize" your Oracle E-Business Suite screens, both for Oracle Forms-based screens and for Oracle Application Framework-based pages. However, the upgrade from Release 11i to Release 12.1 spans many years of EBS evolution, during which time Oracle has actively been building many new features and modules. A lot has changed in Oracle E-Business Suite that may affect upgrading your personalizations from 11i to 12.1. 

    We have published a new note on My Oracle Support that discusses ways to evaluate your existing personalizations:

    Two distinct types of personalizations

    There are two distinct types of personalizations:

    1. Form Personalization
    2. OA Framework Personalization.

    Both types of personalization are completely metadata-based. The personalizations are stored as data in database tables. However, because the underlying technologies (Oracle Forms and OA Framework) are very different, Forms personalizations and OA Framework personalizations are not equivalent and cannot be converted or migrated from one to the other.

    Diagram showing how personalizations can be transported for like-to-like functionality from EBS 11i to 12 Like-to-Like.gif

    Critical factors when affecting upgradeability

    Upgradability of personalizations is based on the premise that you are upgrading "from like to like." That is, a personalization based on a certain form, affecting certain fields, will be upgradable to the next version of the same form assuming that the underlying structure of the form is the same (that is, the blocks and fields touched by the personalization are still in the form and have the same names). In other words:

    • For an upgrade from one minor release to another minor release, personalizations are generally likely to be upgradable.
    • For an upgrade from one major release (11i) to another major release (12.1), personalizations are much less likely to be upgradable.

    Personalizations that need to be reimplemented manually

    A personalization is not upgradable if you are not upgrading "from like to like." This can happen for a number of reasons:

    1. A screen or page has been sufficiently modified in the new version of the product such that the old objects that were personalized no longer exist in the new version. For the 11i to 12 upgrade, however, forms are more likely to have been rebuilt in OA Framework than to have been modified using Oracle Forms.
    2. An Oracle Forms-based screen has been replaced by an OA Framework-based page. This is very common across the 11i to 12.1 upgrade, because many products have rebuilt a lot of their Oracle Forms-based functionality into OA Framework while adding or redesigning other features. For example, the user interface for item instance functionality in Oracle Install Base has been rewritten in OA Framework.
    3. A screen or page has been moved into a different product, so the personalization metadata no longer applies (because each product has its own namespace). For example, between 11i and 12.1, some payments forms were removed from Oracle Payables (AP) and their functionality was consolidated with other payments functionality into a new Oracle Payments (IBY) module. Personalizations made to those original AP payments forms would no longer apply.

    Comparing EBS 11i screens to EBS 12 equivalents

    For the most part, when you upgrade an OA Framework-based page from Release 11i to 12.1.3, that OA Framework page will still exist in 12.1.3 unless the specific Oracle E-Business Suite product has been heavily redesigned. So in general, OA Framework personalizations are likely to upgrade smoothly ("like to like") to 12.1.3, though of course it depends on the specific products you have.

    There are various ways to tell if a particular form or page no longer exists in 12.0 or 12.1. Generally, you should start with the upgrade manuals for your installed products and determine if there has been a major redesign of any of the modules you have. In those cases, most of your form personalizations will no longer apply, and in fact, you will probably no longer need them anyhow. For example, as mentioned above, payments functionality has been moved into a separate Oracle Payments module (IBY). Many customizations you might have had for that functionality can be retired instead of re-implemented because the new product offers significant configurability, and features were added as standard that previously may have required customization to achieve.

    For further information, see Note 1292611.1.  Happy reading and upgrading!


    Related Articles

    Thursday Oct 14, 2010

    Understanding Support Windows for E-Business Suite Releases

    [December 9, 2010 Update:  Your feedback led us to review this policy.  In response to your comments, we've made a number of important changes to relax these support policies.  These changes are published in Version 2 of the E-Business Suite Error Correction Support Policy released earlier this month.  For a summary of these changes, see this blog article.]

    E-Business Suite support is governed by two interlocking support policies:   
    1. Oracle's Lifetime Support Policy
      Specifies support dates for major EBS release codelines (e.g. EBS, 12.0, 12.1) -- and by implication, the latest EBS patchset for a given codeline. The Lifetime Support Policy presents support definitions and dates for three different levels of support:  Premier, Extended, and Sustaining. 

    2. E-Business Suite Error Correction Support Policy (Note 1195034.1)
      Specifies support dates for EBS release update packs for a given EBS releases codeline covered by Premier Support.  Examples of EBS release update packs (RUPs) include EBS 12.0.2, 12.0.3, 12.0.4, 12.0.5, 12.0.6, 12.1.2, 12.1.3.  
    Together, these two documents present actual support dates or formulas by which you can derive support dates.  The second document is new and introduces a new policy:  
    Oracle Development provides bug fixes for the current EBS release update pack for 18 months after the next release update pack is released.  
    This is called the grace period.  The grace period is designed to give you adequate time to upgrade to the latest EBS release update pack.

    A RUP is supported for the duration of its 18 month grace period even if multiple new RUPs come out during that period.  The 18 month grace period will always be honoured for its full duration.
    Translating support policies to support windows for specific EBS releases

    If you read both documents and parse things out carefully, you can derive the following snapshot of current support dates for the following releases:
    • EBS
      This is the latest patchset on this EBS codeline, so the Lifetime Support Policy applies.
      Premier Support runs to November 30, 2010; Extended Support to November 30, 2013.
      Also remember that your EBS environment must have a certain minimum level of patches to be eligible for Extended Support.

    • EBS 12.0.6
      This is the latest release update pack on the EBS 12.0 codeline, so the Lifetime Support Policy applies.
      Premier Support runs to January 30, 2012; Extended Support to January 30, 2015.

    • EBS 12.1.1
      This isn't the latest release update pack on the EBS 12.1 codeline, so the Error Correction Support Policy applies.  The grace period runs 18 months after the release date of EBS 12.1.2 in December 2009.  The grace period for EBS 12.1.1 is January 2010 to June 2011.  New bug fixes for EBS 12.1.1 are provided until June 2011.

    • EBS 12.1.2
      This isn't the latest release update pack on EBS 12.1 codeline, so the Error Correction Support Policy applies.  The grace period runs 18 months after the release date of EBS 12.1.3 in August 2010.  The grace period for EBS 12.1.2 is September 2010 to February 2012.  New bug fixes for EBS 12.1.2 are provided until February 2012.

    • EBS 12.1.3
      This is the latest release update pack on the EBS 12.1 codeline, so the Lifetime Support Policy applies.
      Premier Support runs to May 30, 2014; Extended Support to May 30, 2017.
    Note that EBS 12.0.4 isn't listed above.  EBS 12.0.4 was supported for 18 months after EBS 12.0.6 was released in November 2008.  The grace period for 12.0.4 ran from December 2008 to May 2010 and is now concluded.  No new bug fixes for 12.0.4 are available now.

    What about E-Business Suite technology stack components?

    Things get more complicated when one considers individual techstack components such as Oracle Forms or the Oracle Database.  If you're interested in learning more about the interlocking EBS+techstack component support windows, see these two articles:
    Related Articles

    Monday Oct 04, 2010

    New Video Primers on EBS Patch Wizard Now Available

    Patching is a perennially hot-topic for E-Business Suite system administrators.  For those of you still running Oracle E-Business Suite Release 11i, patching is especially important as we near the transition between Premier and Extended Support at the end of November 2010

    If you're new to EBS system administration, and even if you're a veteran DBA, you might find two new short training videos useful:
    These two videos were produced by Oracle Support.  The first provides a great introduction and review of EBS Patch Wizard basics in just over nine minutes.  The second provides a three-minute demonstration of the new capabilities for reporting on the minimum baseline patch requirements required to be eligible for 11i Extended Support. 
    What's notable about both of these videos is that they actually show you the Patch Wizard in action, and they're really short and sweet.  Highly recommended.

    Related Articles

    Tuesday Aug 24, 2010

    A Primer on Hardware Sizing for Oracle E-Business Suite

    [Read More]

    Sunday Aug 08, 2010

    EBS Sysadmin Primer: Oracle BI Discoverer 11gR1

    [Editor: This is the fourth in a multi-part series from Nirzari Raichura, a senior member of our ATG Certification team, on essential Fusion Middleware concepts and tools for the EBS sysadmin]

    Oracle Business Intelligence Discoverer is an ad-hoc query, reporting, analysis, and Web-publishing tool that allows end-users to work directly with Oracle E-Business Suite OLTP data.  We certified Discoverer 11g version (a.k.a. Patchset 2) with the E-Business Suite a few weeks ago.

    With that recent certification, I think it's time to cover the installation and configuration of Discoverer 11g with E-Business Suite.  Discoverer 11g's integration with the E-Business Suite works identically to Discoverer 10g, and all of the business intelligence functionality continues to work as in previous Discoverer releases.  The major changes in this release come from Discoverer's installation dependencies on Oracle Application Server components.

    As with other Fusion Middleware components, Oracle Weblogic Server is the required application server for Discoverer 11g.  Like Oracle Identity Management 11g, Discoverer is loosely-coupled with Fusion Middleware's database and application server components. 

    Discoverer 11g Install comes bundled with Oracle Portal, Oracle Forms, and Oracle Reports, as in previous releases like Discoverer 10g.  Since it is loosely coupled with other Fusion Middleware components, you need to install a number of prerequisites prior to discoverer 11g install.

    All of these middleware components have to be at the same version level to work together.  I have summarized these dependencies in the following table:

    Table summarizing Discoverer 11g prerequisites
    Related Articles

    Thursday Jul 22, 2010

    EBS Sysadmin Primer: Oracle Identity Management 11gR1

    [Editor: This is the third in a multi-part series from Nirzari Raichura, a senior member of our ATG Certification team, on essential Fusion Middleware concepts and tools for the EBS sysadmin]

    Oracle Identity Management (OIM) 11gR1 is part of Fusion Middleware 11gR1.   Oracle Identity Management 11gR1 provides the following components as part of its default installation:
    Oracle Directory Services Components
    • OID - Oracle Internet Directory
    • DIP -  Oracle Directory Integration Platform
    • OVD - Oracle Virtual Directory
    Oracle Identity Federation Components
    • OIF - Oracle Identity Federation
    Management Components
    • EM - Enterprise Manager
    • ODSM - Oracle Directory Service Manager

    In order to use Oracle Identity Management 11gR1 with E-Business suite, you need OID and DIP products at a minimum.  Oracle Identity Management 11gR1 doesn't contain Oracle Single Sign-on.  You have the choice of either of the following two tools for for authentication: 
    • Oracle Single Sign-On 10gR3
    • Oracle Access Manager 10gR3

    Oracle Access Manager 10gR3 is the preferred authentication solution going forward.  However, if you have plans to integrate any other products like Oracle Portal, Forms, Reports or Discoverer with E-Business Suite, you must select the Oracle Single Sign-On 10gR3 option. These products have hard dependencies on Oracle Single Sign-On 10gR3 and cannot be authenticated directly by Oracle Access Manager (you can do so indirectly, but that's a topic for a future article).

    If you have already integrated your E-Business Suite environment with Oracle Single Sign-On and Oracle Internet Director 10gR3, you can upgrade Oracle Internet Directory 10gR3 to Oracle Internet Directory 11gR1 (which is part of Oracle Identity Management 11gR1). Your existing integration remains intact after the upgrade.

    Oracle Identity Management 11gR1 Integration with E-Business Suite using OSSO 10gR3

    Unlike Oracle Internet Directory 10g, which is tightly integrated with with Oracle Application Server 10g and and the Oracle database (to store its metadata repository), Oracle Identity Management 11gR1 provides various integration options. 

    There is an option to manage it through the Oracle Fusion Middleware management framework by registering it with a local or a remote WebLogic Server administration domain.  You can do this during installation or via the command-line after installation. As I mentioned in my previous blog article, you can also install and configure it without WebLogic Server. In that case, you can manage Oracle Internet Directory using command-line tools and ODSM.

    This table describes the components required for Oracle Identity management 11gR1 installation:

    Useful Tools to administer and manage OIM 11gR1



    Default Value

    Oracle Enterprise Manager Fusion Middleware Control


    Oracle Directory Services Manager (ODSM)


    Oracle WebLogic Server Administrative Console


    Command-Line Utilities



    Standard LDAP utilities



    WebLogic Scripting Tool (wlst)


    OIDCTL For backward compatibility


    Related Articles

    Tuesday Jun 29, 2010

    An Oracle Fusion Middleware 11g Primer for EBS Sysadmins

    Oracle E-Business Suite Release 11i runs Oracle9i Application Server as its internal application tier.  Oracle E-Business Suite Release 12 runs Oracle Application Server 10g.  Both EBS 11i and 12 can optionally be integrated with externally-deployed Fusion Middleware 11g components such as Oracle Internet Directory, Discoverer, Portal, Oracle Business Intelligence Enterprise Edition, and others.

    Oracle Fusion Middleware 11g is Oracle's latest suite of related and interoperable application tier server products.  Some Fusion Middleware products have dependencies on other Fusion Middleware products.  As an E-Business Suite DBA or systems administrator, it is essential that you have a good conceptual understanding of Fusion Middleware 11g concepts before jumping into administration or installation tasks. 

    Fusion Middleware 11g overview diagram showing development tools identity management oem bi and other components

    This information is covered in the Fusion Middleware 11g guides themselves, of course, but it's spread across many different documents.  This is the first in a series of articles in which I'll cover the essential concepts that E-Business Suite sysadmins need to know about Oracle WebLogic Server, Webcenter, Oracle Internet Directory, Portal, and Discoverer.  These concepts are important for Fusion Middleware architectural design, installation, administration, integration, configuration and troubleshooting.

    Key Fusion Middleware 11g Concepts

    Oracle WebLogic server (WLS) is the application server for Oracle Fusion Middleware 11g.  Most Fusion Middleware components require WLS, with notable exceptions being Oracle Internet Directory (OID) and Oracle Virtual Directory (OVD). Oracle Internet Directory and Oracle Virtual Directory can be configured with or without a WebLogic domain.

    Fusion Middleware components are divided into two types:

    • Java Components:  Deployed as one or more Java applications and a set of resources.  Examples: Oracle SOA Suite, Oracle WebCenter. 
    • System Components:  A manageable process that is not deployed as a Java application.  System components are managed by Oracle Process Manager and Notification (OPMN).  Examples: Oracle Internet Directory, Oracle Virtual Directory, Oracle HTTP Server, Discoverer, Forms & Reports.

    What's in a typical Fusion Middleware environment?

    A typical Fusion Middleware environment includes the following:

    1. Fusion Middleware Home (MW_HOME)
    2. Oracle WebLogic Server Home (WLS_HOME)

    1.  Fusion Middleware Home (MW_HOME)

    • A top level directory for all Fusion Middleware products installed on same machine, including WebLogic Server..
    • Created at time of WebLogic Server installation.
    • Serves as a repository for common files used by multiple Fusion Middleware products installed on the same machine.

    TIP:  Do not include spaces in the name of your Middleware home directory. If the name of this directory contains spaces, the CLASSPATH may not be resolved properly. 

    2.  WebLogic Server Home (WLS_HOME)

    • A WebLogic Server home containing binary files necessary to host a WebLogic Server.
    • Created under Fusion Middleware Home at time of WebLogic Server installation.
    • Contains mostly 'read only' files until either patched or upgraded

    TIP:  You can install only one instance of each version of a WebLogic Server product in a single Middleware Home directory.


    • Contains installed files necessary to host a specific product. For example, the WebCenter Oracle home contains a directory that contains binary and library
      files for Oracle WebCenter.
    • Can be created before product install, but if not, will be automatically created by the installer. It must reside under Middleware Home directory.
    • Contains mostly 'read only' files until either patched or upgraded
    • Each ORACLE_HOME can be associated with multiple Oracle instances or Oracle WebLogic Server domains 


    • Contains modifiable files such as configuration files, log files, and temporary files for one or more system components.
    • System components in an Oracle instance must reside on the same server.
    TIP:  You can install this anywhere on the same server; it need not be within the Middleware home directory.

    Key Oracle WebLogic Server Concepts

    To manage an Oracle WebLogic Server instance, you need to understand the following concepts:

    1. WLS Domains
    2. Administration Server
    3. Managed Server
    4. Default Domain Directory
    5. Farm

    WLS Domain

    • A group of logically related Oracle WebLogic Server resources and services.
    • You can use a single Oracle WebLogic Server installation to create and run multiple domains, or you can use multiple installations to run a single domain.

    Administration Server

    • A special Oracle WebLogic Server instance which is the central point from which configuration and management of all resources in the domain occur.
    • Each Oracle WebLogic Server domain must have one server instance that acts as the Administration Server.
    • Can be used to deploy other components, but it is not recommended 

    Managed Server

    • To deploy additional Fusion Middleware products such as SOA Suite, WebCenter, or Oracle Internet Directory, you usually should configure an additional domain instance: a Managed Server
    • You can configure this domain either during or after product install.
    • You can configure separate domains for different Fusion Middleware components.  Example: one domain for SOA Suite, one for WebCenter, and one for Oracle Internet Directory.  Alternately, you can have a single domain for multiple components; depending on your requirements
    • You can configure managed servers as clustered and non-clustered
    • In a cluster, most resources and services are deployed identically on each Managed Server instance and are running simultaneously and working together
    • All Managed Servers in a cluster must reside in the same domain; you cannot split a cluster over multiple domains
    • The key difference between clustered and non-clustered Managed Servers is support for failover and load balancing

    Default Domain Directory

    • By default, Oracle WebLogic Server creates domain directories under the MW_HOME/WLS_HOME/user_projects/domains directory
    • It can reside anywhere; it need not be within the Middleware home directory.
    • A domain is a peer of an Oracle instance. Both contain specific configurations outside of their Oracle homes 


    • A collection of components managed by Fusion Middleware Control.
    • Can contain Oracle WebLogic Server domains, one Administration Server, one or more Managed Servers, and the Oracle Fusion Middleware components that are installed, configured, and running in the domain.

    Coming up next in this series:  EBS Sysadmin Primer: Oracle Fusion Middleware 11g Management Tools.


    Related Articles

    Friday May 28, 2010

    New Whitepaper: Advanced Compression 11gR1 Benchmarks with EBS 12

    [June 23, 2010 Update:  Our Server Technologies team has just released Note 1061366.1 that lists recommended Advanced Compression patches applicable to all customers, including E-Business Suite environments]

    In my opinion, if there's any reason to upgrade an E-Business Suite environment to the 11gR1 or 11gR2 database, it's the Advanced Compression database option.  Oracle Advanced Compression was introduced in Oracle Database 11g, and allows you to compress structured data (numbers, characters) as well as unstructured data (documents, spreadsheets, XML and other files).  It provides enhanced compression for database backups and also includes network compression for faster synchronization with standby databases.

    In other words, the promise of Advanced Compression is that it can make your E-Business Suite database smaller and faster.  But how well does it actually deliver on that promise?

    Apps 12 + Advanced Compression Benchmarks now available

    Three of my colleagues, Uday Moogala, Lester Gutierrez, and Andy Tremayne, have been benchmarking Oracle E-Business Suite Release 12 with Advanced Compression 11gR1.  They've just released a detailed whitepaper with their benchmarking results and recommendations.

    This whitepaper is available in two locations:
    Vision Database:  Up to 68% compression and up to 36% improved performance

    The results, even with our EBS Vision demonstration database, were impressive:
    • Reduced 21.9 GB of tables down to 6.9 GB (68% reduction, average 3:1 compression ratio)
    • Self-service performance improved up to 36%
    • Purchasing performance improved up to 10%
    • Order-to-Cash batch flow performance improved up to 33%
    • Payroll performance improved up to 25%
    They also found some other interesting effects:
    • Some SQL execution plans changed, reducing performance
    • Performance was improved at the cost of up to 6% increased CPU usage, with the variance depending upon how much DML is performed
    • In the case of the Order-to-Cash batch flow, the average CPU consumption actually decreased by 7%
    Line chart showing order to cash batch flow cpu usage for Oracle 
E-Business Suite Release 12 and advanced compression

    Oracle using this in production with EBS 12 today

    We can now share the news that we've been using Advanced Compression in our Oracle Global Single Instance (GSI) production environment since 2009.  This same team has been working to analyse the results of using Advanced Compression with our Oracle E-Business Suite Release 12 global single instance that we use to run Oracle's own business. 

    The results there are very impressive:
    • Reduced EBS 12 database size from 17 Terabytes to 13 Terabytes
    • Compressed ~260 tables and over 700 associated indices and LOBs after migrating to SecureFiles
    • Total space saved: 68 TB across our primary, standby, and associated testbeds
    Other E-Business Suite-specific observations about Advanced Compression

    This whitepaper makes detailed E-Business Suite-specific observations in the following areas:
    1. Index compression
    2. Recommended patches
    3. SQL Plan regression analysis
    4. DML intensive operations
    5. Row chaining on UPDATE transactions
    6. ITL contention
    7. High transaction tables
    8. SecureFiles LOB compression
    The whitepaper concludes with specific recommendations on planning your Advanced Compression conversion in your E-Business Suite environment, and then lists all of the tables compressed in the Vision testbed as well as Oracle's own EBS 12 production instance.

    Have you used Advanced Compression with EBS?

    Naturally, compression ratios and performance impacts or benefits will vary for every Apps environment.  If you've used this technology, we're very interested in hearing about your experiences with Advanced Compression in your environment.  You're invited to share your experiences here or drop me an email directly.

    Related Articles

    Tuesday May 11, 2010

    EBS + 11g Database Upgrade Best Practices Whitepaper Available

    I returned from OAUG/Collaborate with a cold and multiple overlapping development crises.  Fun.  Now that those are (mostly) out of the way, it's time to get back to clearing out my article backlog. 

    Premier Support for the 10gR2 database ends in July 2010.  If you haven't already started planning your 11g database upgrade, we recommend that you start soon.  We have certified both the 11gR1 ( and 11gR2 ( databases with Oracle E-Business Suite; see this blog's Certification summary to links to articles with the details.

    Our Applications Performance Group has reminded me that they have a whitepaper loaded with practical tips intended to make your 11g database upgrade easier.  No vacuous marketing rhetoric here -- this is strictly written for DBAs.  A must-read if you haven't already upgraded to either 11gR1 or 11gR2, and highly recommended even if you have. 

    You can download this whitepaper here:
    This whitepaper covers:
    • Pre-upgrade tips
      • Gather dictionary statistics
      • Manage CBO statistics
      • Gather performance metrics
      • Save execution plans
      • Test (including capturing and replaying workloads)
    • Post-upgrade tips
      • init.ora parameters
      • Gather statistics
      • Disable automatic optimizer statistics collection
      • Plan stability using SQL Plan Management (SPM)
      • Detect and tune performance changes using SQL Performance Analyzer (SPA)
      • Real-time SQL monitoring
      • Incident packaging service
    • New 11g Performance-related features
      • Optimizer enhancements
      • Partitioning enhancements
      • Advanced Compression
    • Fixes and workarounds for known issues
      • Mandatory patches
      • Options fixes and workarounds
    E-Business Suite Benchmarks Also Available

    The Applications Performance Group is also responsible for our Oracle Applications Standard Benchmark (OASB), a standard workload that tests the performance and scalability of Oracle Applications and provides metrics for the comparison of Oracle Applications performance on different system configurations.  Copies of independently-audited E-Business Suite benchmarks for both Oracle E-Business Suite Release 11i and 12 are available here:
    Related Articles

    Friday Apr 16, 2010

    The Scoop: Oracle E-Business Suite Support on 64-bit Linux

    Linux tux-large.jpg
    This article addresses frequently asked questions about Oracle E-Business Suite (EBS) 64-bit Linux support.

    Q:  Which 64-bit Linux OSs are supported for EBS?

    A: Beginning with Release 12, we support the following 64-bit operating systems for both application and database tiers on x86-64 servers:

    • Oracle Enterprise Linux
    • Red Hat Enterprise Linux
    • SUSE Linux Enterprise Server
    For EBS Release 11i (and again in Release 12), when the application tier is installed on a certified platform, additional platforms (including the above) may be used for a 64-bit database tier on x86-64 servers. This is an example of a mixed platform architecture (Release 12), or a Split Configuration (Release 11i).

    Q:  I understand that the EBS application tier code is 32-bit, even for the 64-bit Linux OS -- is this the case?
    A: It is true that the majority of executables provided as part of our release media on the application tier are 32-bit (as are the Fusion Middleware libraries and objects they depend on).  However, the 'Planning' products have large memory requirements and therefore are 64-bit compiled to take advantage of the larger memory space afforded by the 64-bit OS'es.

    Q:  How do I install EBS on 64-bit Linux?
    A:  For new installations of EBS Release 12 on supported 64-bit Linux operating systems, you can use Rapid Install as directed in "Oracle Applications Installation Guide: Using Rapid Install" to install the database and application tiers.

    For Database Tier Only platforms in a mixed platform architecture, you can use Rapid Install as directed in "Oracle Applications Installation Guide: Using Rapid Install" to install the database and application tiers on supported platforms, and then migrate the database tier to a certified 64-bit operating system.

    Q:  How do I migrate EBS Release 12 from 32-bit Linux to 64-bit Linux?

    A:  Please refer to Migrating Oracle E-Business Suite R12 from Linux 32-bit to Linux 64-bit (Note 471566.1) for instructions on how to migrate EBS from 32-bit to 64-bit Linux.

    Q:  How do I migrate an existing EBS database to 64-bit Linux?

    A:  To migrate an EBS database to a certified 64-bit Linux operating system on x86-64, refer to one of the following documents:

    For EBS Release 11i:

    For EBS Release 12:
    Q:  How do I migrate EBS Release 12 on a non-Linux platform to 64-bit Linux?
    A:  There is no documentation that covers the direct migration from a Windows or UNIX application tier directly to 64-bit Linux.  However, the document Application Tier Platform Migration with Oracle E-Business Suite Release 12 (Note 438086.1) contains instructions for migrating to 32-bit Linux, and Migrating Oracle E-Business Suite R12 from Linux 32-bit to Linux 64-bit (Note 471566.1) contains the additional steps to configure your environment for 64-bit Linux.  Pondering this question just now gave me the idea to write a new white paper, which will presumably eliminate several steps from either document and insure a smooth migration process.  Stay tuned to this space for more information on this upcoming paper.

    Q:  How do I patch EBS on Linux 64-bit?

    A: The EBS 32-bit Linux application tier patches are applicable for 64-bit Linux OSes as well.  From the Oracle support portal, you can do a search by patch number to bring up the 32-bit patch.  Note that if you click on the informational icon to the left of the Platform pulldown menu for this patch, it brings up a page stating:

    For Oracle Applications Release 12 on Linux x86-64, queries will return a Linux x86 patch. This patch may be applied to both 32-bit and 64-bit operating systems.

    Q:  What are the benefits of running EBS Release 12 on 64-bit Linux?

    A: Theoretically, 64 bit architectures allow for "2 to the 64th power" bytes or 16 exabytes of RAM, and while individual operating systems and hardware architectures impose constraints (for instance, the maximum RAM is 1 terabyte on x86-64), you are unlikely to hit this memory limit with today's applications. 

    For 32-bit compiled code, even though the process address space is limited to approximately 3 GB (even on the 64-bit OS), with overall addressable space up to 1 terabyte you'll be able to run many more processes.  This is an excellent model all around for larger customers wanting to consolidate their hardware or scale up.

    Q:  Can we (or why can't we) run EBS Release 11i on 64-bit Linux?

    A:   We support the use of 64-bit Linux OS'es in the EBS database tier in a 'split configuration' or 'database tier only' configuration for 11i, wherein the application tier can be on any certified EBS platform and the database tier can run additional database certified platforms (like 64-bit Linux).  Customers wanting headroom for the RAM-intensive DB processes can run their database tier on Linux 64-bit (in a split tier configuration), and if needed spread the application tiers (CM, Forms, Web) across multiple middle tier machines to distribute the load amongst the 32-bit OS'es.

    As to why we do not support EBS Release 11i on 64-bit Linux, there are several reasons:  a)  it doesn't "just run";  b) there is no third party support; c) given the costs, we chose to chose to focus our resources on EBS Release 12 and beyond.  Let me explain.

    Contrary to what you might think, you cannot necessarily run 32-bit code on 64-bit Linux without a bit of tweaking.  On the technical front, you would need to install the 32-bit OS libraries and deal with potential conflicts between 32-bit and 64-bit OS packages, including file overwrites.  Note that when we introduced 64-bit OS support in EBS Release 12 we made changes to all of the product makefiles, carefully analyzed and laid out both the 32-bit and 64-bit package dependencies, modified installation, configuration and cloning software for OS recognition and proper file locations, and conducted extensive testing.  Each new release requires this process to be repeated, and each new release package requires an independent packaging effort.

    In addition, for 64-bit Linux support we've established a 64-bit infrastructure across Oracle teams (in support, engineering, release, QA and certification teams).  This infrastructure investment was made for EBS Release 12 and higher.

    Also note that EBS Release 11i has an aging technology infrastructure, and neither Oracle nor third party tool versions used in EBS Release 11i are explicitly supported on the 64-bit operating system in 32-bit mode.

    Call us old-fashioned if you will, but given these limitations, because of our support commitment to you and what's behind that commitment we will only support EBS Release 12 forward on 64-bit Linux.

    Related Articles

    Tuesday Apr 06, 2010

    How Does AutoPatch Handle Shared E-Business Suite Products?

    Space... is big. Really big. You just won't believe how vastly hugely mindbogglingly big it is.
    ~ Douglas Adams

    Douglas Adams could have been talking about the E-Business Suite.  Depending upon whom you ask (and how you count them), there are between 200 to 240 products in Oracle E-Business Suite. 

    The products that make up Oracle E-Business Suite are tightly integrated. Some of these products are known as shared or dependent products. Installed and registered automatically by Rapid Install, such products depend on components from other products for full functionality.

    For example:
    • General Ledger (GL) depends on Application Object Library (FND) and Oracle Receivables (AR)
    • Inventory (INV) depends on FND and GL
    • Receivables (AR) depends on FND, INV, and GL
    It can sometimes be challenging to craft a patching strategy for these types of product dependencies.  To help you with that, our Applications Database (AD) team has recently published a new document that describes the actions AutoPatch takes with shared Oracle E-Business Suite products:
    This document complements the respective Oracle Applications Maintenance Utilities guides for both Apps 11i and 12 with additional information about:
    • Product dependencies and AutoPatch actions
    • File driver files
    • Installed products
    • Shared products
    Related Articles

    Friday Mar 12, 2010

    New Whitepaper: Planning Your E-Business Suite Upgrade from Release 11i to 12.1 (Second Edition)

    [Editor:  This guest article has been contributed by Anne Carlson]

    Premier Support for Oracle E-Business Suite Release 11i ends in November 2010.  At Oracle OpenWorld last fall, it was standing room only at several EBS upgrade sessions.  Responding to the increased interest in upgrades, I set to work on a new Release 12.1 version of our popular whitepaper, Best Practices for Adopting E-Business Suite, Release 12 (Note 580299.1).

    Here is that new whitepaper, which features the latest Release 12.1 upgrade planning advice from Oracle's Support, Consulting, Development and IT organizations:
    The paper is directed at IT professionals who are planning, managing, or running a Release 12.1 upgrade project.  After briefly reviewing the Release 12.1 value proposition, the paper launches into specific upgrade planning tips to help you:

    Understand the factors that can affect your project's duration
    • Decide your project scope, and avoid missteps that can needlessly increase your scope
    • Assemble the right project team
    • Develop a robust testing strategy
    • Leverage all of the Oracle Support resources available to you
    • Identify the Oracle tools that can improve your upgrade and maintenance experience
    • Become familiar with the full range of Oracle's information resources
    To suggest other upgrade planning topics that you would like to see addressed, please leave a comment or send an email to:


    Related Articles

    Thursday Mar 11, 2010

    A Primer on Migrating Oracle Applications to a New Platform

    In Support we field a lot of questions about the migration of Oracle Applications to different platforms.  This article describes the techniques available for migrating an Oracle Applications environment to a new platform and discusses some of the common questions that arise during migration.  This subject has been frequently discussed in previous blog articles but there still seems to be a gap regarding the type of questions we are frequently asked in Service Requests.

    Some of the questions we see are quite abstract. Customers simply want to get a grip on understanding how they approach a migration. Others want to know if a particular architecture is viable. Other customers ask about mixing different platforms within a single Oracle Applications environment.   

    Just to clarify, throughout this article, the term 'platform' refers specifically to operating systems and not to the underlying hardware. For a clear definition of 'platform' in the context of Oracle Applications Support then Terri's very timely article:
    The migration process is very similar for both 11i and R12 so this article only mentions specific differences where relevant.

    1. Why Have a Migration Process at All?

    Some customers have asked why there is a migration process at all. Surely they say it would be easier just to perform a fresh install of the E-Business Suite on the target environment and then perform an export/import of the database.

    The above process is reliant on the fresh install you perform exactly matching the patching levels and technology stack levels of the environment you are migrating from. The database contains tables with information regarding files in your APPL_TOP. If you mix a fresh application tier install with an already established database, there will be a mismatch between these tables and the objects they describe. This will cause problems during later patching. The same issue applies regarding Java objects in the database and the files contained in the JAVA_TOP. For these reasons, you should never consider mixing an application tier with an unmatched database tier.

    Although the migration process may appear quite time consuming and linear, much of it can be done in advance. With careful planning, your production environment downtime can be limited to little more than the time it takes to export and import the database and the time taken to apply several key patches. The majority of the application tier migration can be done in advance whilst your production environment is still up and available for updating by users.

    2. Migrating the Database Tier to a New Platform

    If you plan to migrate both the application and database tier to a new platform, the flow of the documentation will follow more logically if you migrate the database tier before the application tier however there's no particular reason why you should not migrate the application tier first.
    Tip:  If migrating the database tier first, make sure the source application tier is updated to connect to the migrated database tier before migrating the application tier. This is because the application tier migration process is only updating the application tier configuration, and assumes the database connection values are the same as source. 
    There are several different ways to migrate the database tier. Using the basic export/import tool was the only way up until the release of 10g. With 10gR1 came the introduction of the datapump utility which looks similar to export/import but with useful enhancements and improved performance.

    With 10gR2 came the introduction of cross-platform transportable tablespaces and transportable databases. At time of writing, transportable database functionality is certified for use with Oracle Applications for Release 11i and for Release 12Cross-platform transportable tablespace (XTTS) is still currently part of an Early Adopter Program (EAP). Version 11g of the database supports both datapump and transportable database migrations.

    Using transportable database as a means to migrate your database is dependent on both platforms having the same "endian" format. The following SQL query run on your source database will tell you if your target platform is compatible.
    SQL> select platform_name from v$db_transportable_platform;
    Transportable database uses the Recovery Manager (RMAN) Convert Database functionality to migrate the database to the new platform. It's not supported to use RMAN outside documentation written specifically for Oracle Applications to perform your database migration.

    One rule that applies to all the above migration methods is that only complete database migrations are supported. It is not supported to perform partial database migrations or complete migrations by using a "schema by schema" approach.

    If using export/import, there are some parameters that are not used in the default parameter file supplied such as named pipes and direct=y. This generally means they are untested in the Oracle Applications environment and, although they may work, you should generally be wary of using parameters that are not specifically documented as being Oracle Applications friendly.

    If migrating from a 32-bit platform/database to-64 bit, then assuming you install a 64 bit Oracle home on your target environment, the conversion to a 64 bit database is done automatically. No additional conversion is required to enable 64 bit functionality. Similarly, if you are migrating a 64 bit database to a 32 bit platform the downward conversion is performed implicitly.

    You should also remember that it is generally only possible to migrate Oracle Applications databases of the same versions. There are only very limited circumstances where you can upgrade the database as part of the migration. Version compatibilities are discussed at the start of each database migration Note. 

    It's inevitable with Applications databases that export files are going to be large. Datapump supports the ESTIMATE_ONLY parameter that can be used at the command line to estimate the size of the datapump export files that will be generated.

    3. Migrating the Application Tier to a New Platform

    The main notes to follow are:
    These notes explain how to migrate the Apps application tier to a new platform. The 11i note can be used to migrate to all supported Unix and Linux platforms, not just Linux. However, these Notes cannot be used to migrate the application tier to a Windows platform.

    The first section of the Notes covers the prerequisite requirements of the migration. This migration method requires AutoConfig and Rapid Clone.

    The final step in Section 1 requires you to run Maintain Snapshot in adadmin. This must be run, and it must run successfully. Snapshot information is stored in the following tables:
    The migration requires you to create a manifest of your application tier file system based on the Snapshot taken in the preceding step. This manifest is then uploaded to My Oracle Support and is used to generate a custom migration patch. The custom migration patch created is specific to your upgrade only and contains all the files contained in the APPL_TOP that are binary specific to your new target platform. This patch is therefore applied in your new environment.

    When performing the application tier migration, you are required to install a new application tier technology stack. These are the Developer and Application Server Oracle homes. This is a good opportunity to install the latest version. For example, if you are migrating an 11.5.9 environment, you can still install an application tier technology stack.

    The same rule applies with the R12.0 and the R12.1 technology stack. There is no requirement to upgrade to 12.1 if you wish to use a 12.0 technology stack. Remember, even if you are maintaining your existing technology stack versions you will still need to download and build a new installation staging area for your new target platform.

    Remember to check all the patches you have applied to the source technology stack previously as it is conceivable you have applied patches on your old technology stack that have not been applied to the newly built technology stack. 

    4. Partial Migration to a New Platform

    There's no particular reason not to migrate the database or application tier in isolation to a new platform. It may be, for example, that you are currently running the E Business Suite on a single node and you're encountering resource or performance problems. You therefore decide to migrate Forms and web application tier processing to a new node which is running on a different platform to your current environment. This is generally described as a split configuration. You should be able to just follow the same Notes to perform this migration.
    Tip:  Remember, if you only migrate Forms and Web services to the new platform, in your new environment you will now have to download and apply each E-Business Suite patch twice (once for each platform) as you will  still have concurrent processing being handled on the database tier.
    For the above reason, if you're planning to run a split configuration, I would always tend to advise running all application tier services (including admin and concurrent processing) on one platform and using the other platform exclusively as a database tier. This means E-Business Suite patches only need to be applied once at the new application tier level.
    In the early days of 11i there was a perceived performance advantage to having the database and concurrent processing on the same node. This is no longer an architectural requirement, given the vast improvements in network bandwidth.  You are free to locate your batch processing services on a different physical server than your database tier.

    There is an additional maintenance overhead of running multiple application tiers on different platforms, so you should take that incremental cost into consideration when planning your architecture. In all cases, you should always locate all nodes in the same data centre and ensure the fastest available network connection between nodes. This configuration should also be more scalable allowing easier introduction of additional nodes at both application and database tier levels.

    The above conditions regarding concurrent processing and the database tier apply equally to Apps 11i and 12.

    5. Sharing the Application Tier

    If you're contemplating a migration and are using multiple application tiers then this is often a good opportunity to implement a shared application tier architecture. A shared application tier means storing a single application tier filesystem on a shared disk accessible to all application  tier nodes. Each application tier node continues to run all or a subset of application tier services however all application tiers access the same single disk subsystem. This reduces maintenance as application tier patches only need to be applied once and therefore may reduce future upgrade or patching downtime.

    If you are running multiple application tiers in your source environment (on the same platform) and plan to use a shared application tier on your target environment then you should merge your application tiers on the source environment before migrating. This means only having to migrate a single application tier. The merge process is described in Note 233428.1 for 11i.

    In R12 all applications tiers have a full application tier file system installed, even if the application tier is only configured to run a subset of application tier services. This means there is no need to merge application tiers in the same way as was required with 11i.   

    A shared application tier can be configured in conjunction with third party software and hardware load balancers.

    Top Five Migration Tips

    So to conclude, here's a top five list of things to consider when migration Oracle Applications to a new platform:
    • Perform as much of the migration as possible outside of the production system downtime
    • Consider a shared application tier configuration if you plan to use multiple application tiers
    • Place all nodes in your E-Business Suite environment in the same data centre regardless of the location of your users
    • If using a split configuration, do not feel compelled to retain concurrent processing on the database tier
    • Use transportable database functionality to migrate the database tier if your source and target platforms have the same endian format

    Related Articles

    Saturday Mar 06, 2010

    E-Business Suite Release 12.1.1 Consolidated Upgrade Patch 1 Now Available

    Oracle E-Business Suite Release 12.1.1 Consolidated Upgrade Patch (CUP1) is now available in My Oracle Support.  This patch is now mandatory for customers who are upgrading to Release 12.1.1 from the following releases:
    • Oracle E-Business Suite Release 11i version 11.5.9 (base, CU1, CU2)
    • Oracle E-Business Suite Release 11i version 11.5.10 (base, CU1, CU2)
    You can download it here:

    What is Oracle E-Business Suite Consolidated Upgrade Patch 1 for Release 12.1.1?

    The Consolidated Upgrade Patch 1 (CUP1) for Release 12.1.1 combines critical upgrade error corrections and upgrade performance improvements from Release 11i into a consolidated suite-wide patch.

    Who should use it?

    Customers who are upgrading to Release 12.1.1 from Release 11.5.9 (base, CU1, CU2) or Release 11.5.10 (base, CU1, CU2) should apply Release 12.1.1 CUP1.

    How does it differ from the Family Consolidated Upgrade Patch (FCUP) in Release 11i?

    In Release 11i, Family Consolidated Upgrade Patches (FCUP) were the release vehicles used to ship consolidated upgrade-related patches from all products within a product family.  In R12, the term Consolidated Upgrade Patch (CUP) has been coined to ship critical upgrade error corrections and upgrade performance improvements across all the product families in Oracle E-Business suite.

    How do you apply Release 12.1.1 CUP1?

    For instructions on applying this patch, see the "Notes for Upgrade Customers" section in:
    Can this patch be applied by customers who are upgrading to Release 12.1.1 from an earlier version of Release 12?

    No.  Release 12.1.1 CUP1 is applicable only if you are upgrading your E-Business Suite Release 11i instance to Release 12.1.1.  If your Oracle E-Business Suite instance is already at Release 12 or higher (e.g. Release 12.0.4), you should not apply Release 12.1.1 CUP1.

    Can I apply Release 12.1.1 CUP1 to Release 12.1.1?

    No.  If your environment is already at the Release 12.1.1 level, you do not need this patchset.  You should apply Release 12.1.1 CUP1 only while upgrading a Release 11i Oracle E-Business Suite instance to Release 12.1.1

    Is Release 12.1.1 CUP1 mandatory for upgrading to Release 12.1.1 if I have done multiple test upgrades and am close to "Go-Live"?

    If you have already performed multiple test upgrades without Release 12.1.1 CUP1 and are close to completing User Acceptance Testing prior to your actual production upgrade, it is not mandatory to apply the patch.

    Oracle will continue to provide patches for Oracle E-Business Suite Release 12.1.1 environments that do not have the Release 12.1.1 CUP1 patchset.

    How is the Consolidated Upgrade Patch (CUP) different from other release vehicles?

    With the introduction of this patchset, there are now five types of release vehicles for the E-Business Suite:
    1. Rapid Install
    2. Maintenance Pack
    3. Product Family Release Update Pack
    4. E-Business Suite Release Update Pack
    5. Consolidated Upgrade Patch
    Rapid Install

    With Rapid Install (RI), you can install a fully configured Oracle E-Business suite system, lay down the file system and configure server processes for an upgraded system, or install a new database tier or application tier technology stack.

    Release 12 Rapid Install versions are
    • Release 12.0.0
    • Release 12.0.4
    • Release 12.1.1
    Maintenance Pack

    A Maintenance Pack (MP) is an aggregation of patches for all products in Oracle E-Business Suite. It is a feature-rich release which combines new functionalities along with error corrections, statutory/regulatory updates, and functionality enhancements, etc.

    The Release 12.1.1 Maintenance Pack can be used to upgrade an existing Oracle E-Business Suite Release 12.0.x environment to Release 12.1.1

    Product Family Release Update Pack

    Product Family Release Update Pack (RUP) is an aggregation of patches on a given codeline created for all products in a specific product family for a specific point release. RUPs are generally cumulative in nature.

    Examples of Product Family Release Update Packs released in Release 12.0:
    • R12.ATG_PF.A.Delta.4
    • R12.FIN_PF.A.Delta.5
    • R12.ATG_PF.A.Delta.6
    • R12.HR_PF.A.Delta.7
    Examples of Product Family Release Update Packs released in Release 12.1:
    • R12.AD_PF.B.Delta.2
    • R12.ATG_PF.B.Delta.2
    • R12.CC_PF.B.Delta.2
    • R12.SCM_PF.B.Delta.2
    E-Business Suite Release Update Pack

    An E-Business Suite Release Update Pack (RUP) is an aggregation of product or product family RUPs on a given codeline created across Oracle E-Business Suite after the initial release. Like product family Release Update Pack, E-Business suite Release Update Pack is cumulative in nature.

    Examples of E-Business Suite Release Update Packs
    • Release 12.0.4
    • Release 12.0.6
    • Release 12.1.2
    Consolidated Upgrade Patch

    A Consolidated Upgrade Patch is a collection of critical fixes that improve the performance and stability of the upgrade process from Release 11i to Release 12.1.1.
    Related Articles

    Tuesday Jan 05, 2010

    New Whitepaper: Symmetrical Network Acceleration with EBS 12

    Andy Tremayne, my esteemed colleague and fellow blogger, has published a new whitepaper that discusses the effects of network acceleration appliances on traffic optimization for E-Business Suite environments: 
    From Andy's crisp prologue:
    Network appliances can be used to reduce bandwidth and latency effects through the use of data stream compression and object caching. The focus of this whitepaper is the deployment of Oracle E-Business Suite across an enterprise wide area network (WAN). Internet-facing applications may benefit from other specialized technologies such as Internet based Content Delivery Networks (CDN) and Internet-based network optimization strategies such as caching, route optimization, and protocol optimization.

    The two main types of acceleration appliances are classed as Asymmetric and Symmetric. Asymmetric acceleration uses a centrally-located single appliance whereas Symmetric acceleration requires an appliance at either end of a network link, or in some cases, a single central appliance and corresponding software client on each remote computer.

    Architecture diagram showing network appliances linking geographically dispersed locations to the E-Business Suite

    As is Andy's wont, this whitepaper is packed with thoughtful analysis, architectural insights, recommendations, diagrams, in-depth quantitative benchmarks, and detailed charts that compare:
    • Traffic reduction improvements for different transaction types
    • Socket to servlet data transfer rates
    • Response times in optimized and unoptimized testbeds
    • Traffic reduction for low network bandwidth activities
    • Optimization results for high network bandwith activities
    This whitepaper is critical reading for network architects grappling with the challenges of providing E-Business Suite access to geographically-diverse locations.

    Related Articles

    Monday Dec 07, 2009

    Oracle E-Business Suite Install and Cloning Best Practices (OpenWorld 2009 Recap)

    Experienced E-Business Suite systems administrators know that there never seem to be enough EBS testbeds for everyone.  It doesn't take long for an Apps sysadmin to realize that having a solid understanding of the various options for building and cloning EBS environments is an essential part of his or her toolkit.  

    Flow diagram showing adpreclone process and what it does on the EBS database tier
    If you've been wondering about the different options for building EBS environments, look no further.  Max Arderius is a member of our Applications Technology Group.  His OpenWorld session covered the E-Business Suite's Rapid Install and cloning techniques in detail:
    Max drilled into the following topics in his presentation:
    • Installing the E-Business Suite
      • Rapid Install overview
      • Standard vs. Express Install
      • Filesystem implications of upgrading and existing system
      • Upgrade considerations
      • Installation of the latest Applications technology stack
    • Cloning techniques
      • Overview of cloning tools: Rapid Clone vs Application Management Pack
      • Details of Rapid Clone process
        • What does on the database and applications tiers
        • What happens during the cloning process
        • What does on the database and applications tiers
        • Comparison of command line options
        • configuration command
      • Application Management Pack cloning process
        • Comparison of Application Management Pack cloning options
        • Source-to-image, image-to-target cloning
        • Hot cloning
        • Real Application Clusters (RAC) cloning
        • Data scrambling during the cloning process
      • Custom cloning techniques
        • Source-to-target direct synchronization
        • Cloning using rsync
        • Maximum Availability techniques using Oracle DataGuard and rsync to a standby database
        • OracleVM cloning using functional technical VM templates
    • Best practices
      • Pointers to useful resources
      • Comparison of using media vs. staged images
      • Remote installation best practices and considerations
      • Fully qualified hosts and file permissions
      • Resource limits and kernal parameters
      • Temp directories and swap spaces
      • Techstack registration
      • Global inventory and multiple inventories
    Listening to the Session

    If you registered for OpenWorld, here's a link to the OpenWorld On Demand page where you can download the presentation or listen to the live recording of this session.

    Related Articles

    Wednesday Nov 18, 2009

    Critical Data Protection + Security in EBS (OpenWorld 2009 Recap)

    Everyone gives lip service to the importance of security, but it's often relegated to the back-burner in actual practice.  For example, my anecdotal experience is that when conference attendees are polled about Critical Patch Updates, usually fewer than 50% of the respondents state that they're up-to-date on the latest CPU.

    One potentially complicating factor is that there are many things that one can do to secure the E-Business Suite, and it may be hard to know where to start.  At minimum, all Apps DBAs should be intimately familiar with these documents:
    There are many other security-related Oracle products that you can use with your E-Business Suite environment, too.  Eric Bing and Robert Armstrong profiled all of the latest security-related tools and options that are relevant to E-Business Suite users in their recent OpenWorld 2009 session:


    Eric and Robert cover the following topics in their presentation:
    • Business drivers and security challenges
      • Database Defense-in-Depth
      • Options for monitoring, access control, and encryption & masking
      • End-to-end security strategies
    • Building a secure E-Business Suite configuration
      • Password policies for Apps and DB accounts (and reference notes)
      • Security profile option settings and recommendations
      • FND Validation Level feature
      • Fixed Key profiles
      • Non-reversible password hashing
    • Externalizing EBS security from the apps tier
      • Apps schema access via SOA Suite Apps Adapter
      • Application Data Source implementation
      • Java Authentication & Authorization Service (JAAS) for E-Business Suite
      • Using Oracle Access Manager
    • Other EBS security integrations and technologies
      • Oracle Audit Vault and client identifiers
      • Oracle Database Vault and segregation of duties
      • Oracle Transparent Data Encryption (TDE) for columns and tablespaces
      • Oracle Label Security (OLS) and Virtual Private Database (VPD)
    • Future directions for E-Business Suite security
    Listening to the Session

    If you registered for OpenWorld, here's a link to the OpenWorld On Demand page where you can download the presentation or listen to the live recording of this session.

    Related Articles

    Tuesday Nov 17, 2009

    E-Business Suite Technology Essentials (OpenWorld 2009 Recap)

    I'm part of the Applications Technology Integration group within the E-Business Suite Development division.  One of this team's responsibilities is to ensure that new Oracle technologies are integrated into -- or work with -- the E-Business Suite. 

    Lisa Parekh leads our team, and every year she manages to pack a survey of the increasingly-broad EBS technology stack landscape at OpenWorld into her session.  If you're interested in getting a quick overview of everything that we consider important about the latest EBS technology stack capabilities, download her presentation here:
    Lisa covers the following topics in her presentation:
    • E-Business Suite technology stack priorities
    • Oracle E-Business Suite Release 12's three-tier architecture
    • Supported R12 browsers
    • Application Server Tier components and layout
    • Standard and optional 10gR2 and 11g Database features
      • Partitioning, compression, tablespace encryption
    • Exadata V2 
    • External optional Fusion Middleware certifications
    • R12 User Interface improvements 
    • Secure Enterprise Search
    • WebCenter integration
    • Single Sign-On and Oracle Internet Directory integration
    • Third-party authentication and LDAP integration
    • SOA enablement and integration
    • Application Integration Architecture
    • Business Intelligence
      • Oracle Business Intelligence Enterprise Edition (OBIEE)
      • Oracle Business Intelligence Applications (OBIA)
    • BI Publisher
    • Systems management capabilities via Oracle Enterprise Manager
      • Application Management Pack
      • Application Change Management Pack for Oracle E-Business Suite
      • Wizards and AutoConfig 
    • Virtualization and Oracle VM
      • Coming soon: Oracle VM templates for the E-Business Suite 12.1.1
    • Technology Uptake Guidance
      • Upgrading to R12.1
      • Database upgrade options
      • New certifications coming
    Listening to the Session

    If you registered for OpenWorld, here's a link to the OpenWorld On Demand page where you can download the presentation or listen to the live recording of this session.

    Related Articles

    Tuesday Nov 10, 2009

    To Customize or Not to Customize?

    Any customer can have a car painted any colour that he wants so long as it is black.
    ~ Henry Ford

    Ford's now-famous words seem a little quaint today.  We live in the Golden Age of the Consumer, where virtually everything can be customized or personalized in some way.  If you can customize mass-produced consumer goods, it seems reasonable to expect that you should be able to customize something as strategic and mission-critical as an enterprise resource planning system, too.  But just because you can, does this mean that you should?

    Personalizations are Persistent

    The E-Business Suite has acquired increasingly-powerful personalization features over the years.  These features allow you to personalize existing EBS screens with your own branding, corporate logos, colour schemes, field names, explanatory messages, and more.  My fellow blog authors have previously written about personalization options here (for Forms personalization) and here (for OA Framework personalization). 

    These types of personalizations are metadata-driven, which means that they are preserved and work even when the underlying screens are updated by EBS product teams via new patches.  This is the primary benefit of using the standard Apps personalization features: your changes are persistent and will continue to work even if the underlying screens are patched at a later date. 

    Going Beyond Personalizations

    You might have a unique service offering, product, or business process.  You might need to capture or manage information about your business, products, or customers in a way that differs markedly from the way the E-Business Suite's designers originally intended. 

    From a system administrator's perspective, you might need to deploy the E-Business Suite in an architecture, topology, or system configuration that aren't supported via AutoConfig yet. 

    The E-Business Suite's personalization features, while useful, may not be sufficient to meet these types of specialized requirements.  At this point of your analysis, it will be useful to consider the advantages, disadvantages, and implications of customizing your the E-Business Suite in an invasive way.

    There are many ways of customizing or extending your EBS environment.  These include:
    • New business rules or data transformations
    • New or custom screens
    • Integrations with external systems
    • Use of third-party utilities or extensions
    • Creation of new reports
    • Creation of new workflows
    • Integrations with standalone APEX applications
    All of these customizations need to be considered in terms of their invasiveness.  The more invasive the change, the greater the long-term implications.

    Advantages of Customizations
    1. Functionality meets your requirements more closely
    Disadvantages of Customizations
    1. More costly than deploying a "plain vanilla" solution
    2. Requires specialized development skills
    3. May require updates, testing, and maintenance whenever:
      • New EBS patches are released
      • New architectures are deployed
      • New technology certifications are released
    4. Increases support complexity and overhead
    5. Can potentially complicate upgrades to new EBS releases
    Understanding the Implications of Customizations

    As regular readers of this blog know, we frequently release new technology stack patches, certifications, architectures, and systems management features.  Apps product families (e.g. Financials, Supply Chain, Human Resources, etc.) aren't standing still, either.  They're constantly updating their products with new features and enhancements, too.

    Let's assume that you have the resources to address the first two potential issues of increased cost and skills.  What remains are the implications of keeping up with your friendly developers at Oracle:

    Testing Implications

    I've spoken with a number of customers who tell me that their customizations have prevented them from applying the latest ATG Rollup or upgrading to the latest database release.  They might have had staff to perform the original customizations years ago, but they no longer have the capacity to regression test their environments with new patches or technology stack components.  In some cases, formal development records detailing the customizations have been lost, making it extremely difficult to perform any impact analyses or tests.  These customers can't go forward, and they can't undo their customizations, either.  These customers are stuck.

    If you've customized your E-Business Suite environment in some way, you need to ensure that every new certification, patch, or newly-supported architectures work in your customized environment.  Depending upon what you're considering introducing into your environment, you may need to perform functional tests, performance benchmarks, scalability testing, and even security reviews.  If you're thinking of customizations, it is extremely important not to underestimate the costs of maintaining and testing them.

    Support Implications

    If I were an IT manager considering customizing the E-Business Suite, the primary factor affecting my decision would be the support implications.  Oracle certifies and supports generic E-Business Suite environments.  If you invasively customize your system in some way, you should understand and plan for the fact that Oracle can only provide patches for issues that can be reproduced in uncustomized, "plain vanilla" E-Business Suite environments.

    Customers who can succinctly describe their customizations when logging Service Requests with Oracle Support will have a distinct advantage over those customers who wait for Oracle Support to stumble over a customization. 

    Upgrade Implications

    Premier Support for E-Business Suite Release 11i ends in November, 2010.  At OpenWorld this year, it was abundantly clear that many of you are planning your upgrades to E-Business Suite Release 12 now. 

    If you've customized your Apps 11i environment in some way, your Apps 12 upgrade plan needs to consider whether those customizations are still needed.  Given the many new features in EBS 12, it's entirely possible that your customizations may now be redundant or obsolete.  One major Apps 11i customer with several thousand customizations observed that at least half of those were already built directly into R12, obviating the need for forward-porting.
    Tipping the Scales

    I've had the pleasure of working with countless EBS customers over the years.  My impressions are that systems administrators with uncustomized Apps environments are generally more-receptive to keeping up with the latest patches, are more willing to consider upgrades and trying new technologies.  This makes a lot of intuitive sense.

    As a battle-scarred Oracle developer, I would venture that very few customers can justify the extremely-high costs and long-term systems management implications that come along with invasive customizations. 

    That said, every customer has their own business case for customizations.  Your mileage will vary.  Everyone going through this analysis will have their own factor weightings, costs, and benefits of customizing their EBS environments.

    I'd be interested in hearing your war stories about customizations, both good and bad.  Feel free to share them in a comment or by dropping me a line. 

    Related Articles

    Wednesday Sep 23, 2009

    Field-Tested Advice for Smooth EBS Upgrades

    Premier Support for Oracle E-Business Suite Release 11.5.9 ended in June, 2008.  If you are currently running 11.5.9 or earlier and your immediate plans do not involve an upgrade to Release 12, then it's a good idea to move up to the terminal release of Apps 11i: This will ensure you remain supported and can make the most of any technology stack and functional upgrades. 

    A lot of what you do as part of an upgrade to will also ease your transition to Release 12, so this upgrade can be considered as a Release 12 prerequisite exercise, too. Critical patch updates, roll-up patchsets (RUPs) and new technology stack certifications are still being released for Apps, and the more up-to-date your system is, the easier it will be to apply these when they come along.  This article takes you through some of the best tips from Oracle Support to ensure a successful upgrade to EBS

    Screenshot patch 3480000.png
    Tip #1: Give Yourself Enough Time

    The first and most important piece of advice is to give yourself enough time. If you have not done an upgrade like this, then don't create a project plan with fixed dates and times until you have a good feel for what the upgrade will involve and how long it will actually take. Your current E-Business Suite release and database version will dictate how much work you have to do. Not surprisingly, if you are running Apps 11.5.2 on the Database, you will have your work cut out for you.  If you are on 11.5.9 and, then your job will be much easier.

    We talk to a few customers who have decided how long they have to complete the entire project before even contemplating what work is required. Don't fall into this trap. Nobody likes working with a gun to their head, least of all, one that they're holding themselves.

    Remember this is not just a technical upgrade. The Maintenance Pack has functional and technical implications.  Even if the upgrade is not motivated by functional requirements, it will certainly require User Acceptance Testing.

    Tip #2: Read the Documentation Beforehand

    Engineers in Oracle Support would be the first to admit that navigating through a combination of Oracle manuals, Notes from My Oracle Support and adpatch readme files and then corralling all that information into a coherent upgrade strategy can be an intimidating task. The temptation to use documentation that is not specifically written for the E-Business Suite or to devise an upgrade strategy of your own can sometimes look very appealing.

    It's not difficult to find a document that appears to apply to your circumstances but then have Oracle Support tell you that you need to be following a different document.  Documentation that is specific to Oracle Applications exists for upgrading just about every component of the technology stack. If, for example, you can't find the Note that talks about upgrading or patching Developer 6i (Note 125767.1) then raise a Service Request (SR) with Oracle Support.

    Tip #3: Don't Take Any Undocumented Shortcuts

    We're sometimes asked, "What if I ignore Step X of my upgrade? Will it still work?" This is an almost-impossible question to answer.  In Oracle Support, we're not insensitive to questions such as this, but the reality is that we will probably not be able to give you a clear and unambiguous answer.

    Our published documentation is designed to achieve a successful upgrade. It is not tested by trying to perform the upgrade steps in a different order or by deliberately omitting steps to see how the upgrade will turn out.  You should perform all steps in the upgrade documentation unless you have a clear reason not to, or clear guidance from Oracle Support that a step can be omitted.

    Given the above, it's also no surprise that a common question we get from customers is "Here is my upgrade plan. Can you go through it and tell me if it's OK?"  This is a perfectly understandable question to ask but sometimes a tough one to answer, especially if the upgrade includes platform migrations, technology stack updates, and Oracle Applications upgrades. 

    We'll try to do out best, but it's difficult for us to give an unconditional endorsement of an upgrade plan that greatly varies from our documentation. Circumstances may sometimes force you to perform upgrade steps in a non-standard order. We're always happy to discuss variations, but it is unlikely we will be able to give you a carte blanche endorsement of an entirely bespoke upgrade, since we are unlikely to have ever attempted an upgrade in the way you might describe.

    Tip #4: Get the Latest Patches and Maintenance Tools

    Start by reading Note 316365.1: the Maintenance Pack documentation. This has all the major steps you may or may not need.  The Upgrade Manual Script for the Maintenance Pack (TUMS-MP) will also create a report listing the steps which are required -- specific to your system -- therefore telling you what steps can be omitted.

    Apply the latest AD patchset as early as possible in the upgrade.

    Whenever you see a patch specified in documentation do not assume this is the latest incarnation of this patch. Check on My Oracle Support to see if it has been superseded. If it has, apply the latest version whenever possible.

    Implement AutoConfig if you have not done so already.  If AutoConfig is only implemented on the application tier, then implement it on the database tier without delay.

    Install and run the Technology Stack Validation Utility. If this reports any errors then, instead of trying to address each issue individually, I'd encourage you to just go to Note 146468.1 and build new 8.0.6 and iAS ORACLE_HOMEs using the install media. This will save you time.

    Tip #5: Switch to the Oracle Applications Tablespace Model (OATM)

    OATM is the latest Oracle Applications tablespace model. Instead of having separate tablespaces for each product, it converts your system to use a greatly reduced number of tablespaces. This is installed by default in fresh installations from 11.5.10 onwards. It will almost certainly reduce the overall footprint of the database, will simplify administration, may improve performance, and is mandatory for Release 12.

    It will take some time to migrate all your database objects to the new tablespaces, but the benefits are worthwhile. The opportunity to optimise a database that may have been running for several years should not be underestimated.

    Tip #6: Configure database for new products and new tablespace requirements

    With each Maintenance Pack release there tend to be some new products introduced.  These products have to be "spliced" into your existing database and APPL_TOP.  Pay particular attention to the patch readme and complete all steps.  You cannot avoid adding these new products simply because you do not anticipate licensing or using these products.  This is a mandatory step. 

    Tip #7: Upgrade the database (conditional) 

    Releases 10gR2 and 11gR1 are currently supported for the E-Business Suite.  If you're running an earlier database release, you need to upgrade to at least 10gR2, and preferably 11gR1.  You can currently upgrade to E-Business Suite Release 12 only if you are already running Database Version 10gR2 or 11gR1.

    There are specific Notes for Oracle Applications users when upgrading the database:
    The default method is to use the Database Upgrade Assistant (DBUA) to upgrade Oracle Applications databases.  The upgrade will invalidate a large number of objects in the database.  You need to decide whether you want DBUA to compile these automatically or whether you want to compile them manually later.  You can configure DBUA accordingly before starting the upgrade.  If you're currently on 10gR1 or an early release of 10gR2 then take the opportunity to upgrade to or 11gR1.

    Install the Data Mining and OLAP options as instructed. This is a mandatory step, even if you're not using products that require those options.

    Tip #9:  Monitor the Upgrade Driver

    The main part of the upgrade to EBS is performed by the upgrade driver supplied in patch 3480000. This should complete without error -- no jobs should be skipped or ignored. If you find yourself having to skip jobs without a very good reason, this suggests something that should have been performed earlier has been omitted or has failed.  Skipping a job may have consequences for subsequent jobs as data or objects may be accessed by several workers during the upgrade driver.

    Accept the default number of workers unless you have a good reason not to. Substantially increasing or decreasing the number of workers you use may affect the performance of the upgrade driver.  While it may be a worthwhile exercise to experiment with the number of workers you use, you should always use the default number as your benchmark for performance.

    Tip #10: Rehearse Your Upgrade Process Thoroughly

    As Support engineers, we generally advise performing a minimum of three test upgrades prior to performing a production upgrade. This means three complete upgrades from start to a successful conclusion. This iterative process allows you to find possible pitfalls during the production upgrade and have workarounds ready.  If you encounter issues during your production upgrade that were not encountered in testing then -- and I apologise for being blunt here -- you probably have not done enough testing. The production upgrade should mostly be a formality, not the most stressful phase of the whole project. 

    We often talk to customers who encounter a series of errors during one of their test upgrades. For each error, a workaround is found and the test upgrade proceeds. The workaround may involve applying a patch that should have been applied earlier in the upgrade, perhaps resizing a tablespace during a patch, or changing a value in an initialisation file or something similar. These errors should be noted and then another test upgrade performed with these workarounds in place so the error no longer appears. There can come a point during a test upgrade where an error is encountered and several things are tried before the successful workaround is found.  If you find yourself in this position at several times within the same test upgrade, it is often advisable to start a new test upgrade and not continue with this test upgrade. This is because this particular test upgrade (usually very early in the project) is no longer representative of what you would actually do in your production upgrade, therefore invalidating your initial testing conditions.  As Oracle Support engineers, we don't advise this lightly. Sometimes the best advice is to give up and start again.

    Because of the above, it's advisable that during each test upgrade, you backup the system at each major step in the upgrade.  If you then encounter a problem during an upgrade that results in your abandoning that particular step, you only need to revert back to the latest backup rather than rewinding to the start of the upgrade.

    Rehearsing your upgrade also allows you to fine tune the process. Testing should give you the chance to record the whole upgrade with each step documented and timed. With this upgrade documentation you may see stages where, for example, you can merge patches into a single step. You can use adpatch command line parameters to avoid generating forms or reports in the middle of an upgrade that are perhaps going to be updated and compiled again further along in the same upgrade by another patch. Refinements like this will reduce the time of the overall upgrade. This refinement process is how you manage to turn your first test upgrade that might take two weeks into a production upgrade that you have to complete in 36 hours for example.   

    All test upgrades should be performed on a very recent clone of your production environment.

    Tip #11: Be Aware of Database Tuning Opportunities

    We're sometimes asked whether fine tuning of database parameters or other components of the technology stack can enhance the performance of the upgrade. There are some pointers within the documentation suggesting when you can do this. I personally find that careful refinement and optimising of all the steps that you perform during the upgrade as a whole will reveal more opportunities to reduce the time the upgrade takes than specific database tuning. That said, it never hurts to look out for opportunities to optimise database performance.

    Wrapping Up:  Upgrade Myths

    So finally, here are the top 5 myths (from an Oracle Support perspective) about upgrading to E-Business Suite
    Myth #1:  Shortcuts are safe

    There are no safe shortcuts.  This upgrade can't be done by performing a fresh install of, linking this installation to your 11.5.x database and then applying the database portion of the Maintenance Pack. It's a nice idea, but it is a flawed strategy

    Myth #2:  You can safely ignore adpatch worker failures

    No, this is very dangerous.  It is not acceptable to skip worker failures in adpatch because the errors are in products you do not intend to use.

    Myth #3:  You can export from an old database version to a higher one

    It is (generally) not supported to upgrade an Applications database by exporting from one database version (8i for example) and importing into a fresh empty database of a later version.

    Myth #4:  You can ignore unused products

    It is not acceptable to ignore the installation of new products just because you do not intend to use those products. 

    Myth #5: You can live without AutoConfig

    AutoConfig must be implemented on the database tier -- this is mandatory and will improve your quality of life
    Good luck with your upgrade!

    Related Articles

    Tuesday Sep 22, 2009

    Six Options for Getting Help for E-Business Suite Issues

    [Sept 24, 2009 Update: Removed references to the Oracle Critical Accounts program.]

    Some E-Business Suite implementations go smoothly.  Some don't.  Even battle-scarred veteran Apps sysadmins have to call upon Oracle for help at some point.  One of the most-surprising things I hear from customers is that many of you don't know what options exist for you to get help when you need it.  Depending on your circumstances, there's a wide range of alternatives that may work for your needs.

    Taking the wrong approach can waste a lot of time and efforts on all sides.  If you need help, here's a list of the best options for ensuring that you get the help that you need:
    1. Do your homework
    2. Log a Service Request (SR)
    3. Escalate your Service Request with Support
    4. Escalate with your Oracle account manager
    5. Get a Service Delivery Manager assigned
    6. Register with the Applications Development Customer Program
    Oracle Advanced Customer Services.png

    Option 1: Do Your Homework

    A good way of wasting time is to log a Service Request before you've searched for the answer yourself.  Google is your friend, of course, so running searches should always be your first step.

    As an aside: I am repeatedly bemused by the emails I receive from people who haven't done even the most-rudimentary web searches.  Interestingly, this includes questions from Oracle staff who should (presumably) know better. 

    Oracle resources that you should search before logging an EBS Service Request:
    The Knowledge tab on My Oracle Support is your entry-point into the collective published body of knowledge from Oracle Development, Support, and Consulting.  It almost goes without saying that you should search for your issue here.  The only caveat is that the Knowledge repository is extremely wide-ranging and deep, and can potentially be intimidating to explore for new users.  Stick with it, though; this is the definitive resource for all Oracle product issues.

    It's important to remember that all Oracle bloggers are doing this in their spare time.  If they're brave enough to reach out to customers, you should remember that Oracle bloggers have varying amounts of bandwidth available to answer your questions.  My fellow bloggers on my E-Business Suite Technology Stack blog are always happy to help with your Apps techstack questions, but we hope that you've searched our site for answers before you post your question.

    Forums are a different matter.  Remember that these public forums are monitored by your customer peers and occasionally someone from Oracle.  These forums yield answers that may vary in quality.  Some of these -- like the impressive Apps R12 Upgrade and OA Framework forums -- have a dedicated and superb group of volunteers who provide crisp and accurate answers to all questions posted.  Others, not so much.

    If these sources solve your problem, great.  If not, then your next step is to get an answer from an authoritative source:  Oracle Support.  If you have a time-sensitive issue for which you need a guaranteed and authoritative response, your best bet is to log a formal Service Request with Oracle Support.

    Option 2: Log a Service Request

    Logging Service Requests (formerly Technical Assistance Requests or TARs) is a necessary first step for any conversation with anyone within Oracle about a particular technical issue.  You log Service Requests via My Oracle Support.  Service Requests are always the starting point for all technical issues. 

    Many of you post conceptual or architectural questions here.  This blog's panel of authors are always happy to answer those questions.  However, this blog isn't really set up to handle diagnostics and investigate technical issues; that's Oracle Support's job. 

    If you email us directly or post a question about a specific technical issue that you're encountering, our first follow-up question will inevitably be, "What's your Service Request number?"  If necessary, we can help the Oracle Support engineer get to the bottom of your issue -- but only if you've logged a Service Request first. 

    The key thing to remember about Service Requests is that the quality of Oracle's assistance depends upon the quality of information that you provide.  Garbage in, garbage out.  Make sure that you provide a good description of the problem, detailed error messages, logs, information about your environment, screen captures, results of your own investigations and tests, and reproducible test cases. 

    Option 3: Escalate Your Service Request with Support

    If your Service Request is getting bogged down for some reason, or is going off in a direction that doesn't seem quite right, it may be time to escalate your case.

    Chris Warticki, a fellow Oracle blogger from Support, has written an excellent article on the Support Escalation process.  I strongly recommend that you check out his article; he makes many insightful comments about how to escalate your issue effectively.  To summarize his key points:
    • Speak with the Oracle Support Escalation Manager (formerly the Duty Manager).
    • Review your concerns.
    • Work up an action plan.
    • Follow up on the agreed-upon actions.
    • Ask the Escalation Manager to follow up with Development on associated bugs.
    Option 4: Escalate with Your Oracle Account Manager

    Escalating through the regular Support channel doesn't always work as well as it might.  If you still find yourself struggling after doing that, then there are other options.

    Some customers may think of Oracle account teams as being useful only when negotiating licencing contracts.  From my vantage in Apps Development, I see Oracle account teams quite differently.  I consider your Oracle account manager to be your advocate and your ombudsman within Oracle.  If you're having difficulty getting any issues resolved through the official channels (e.g. via escalating Service Requests), then your Oracle account manager is your next call.  Your Oracle account manager can escalate a Service Request with management teams in Oracle Support and Development.

    That's the theory, at least.  The reality is that some Oracle account managers may be relatively new to their jobs, so you may need to encourage them to seek help via internal Oracle channels on this.  Oracle account managers should be motivated to help you resolve issues, since happy customers tend to be more willing to do repeat business than unhappy ones.

    Option 5: Get a Service Delivery Manager Assigned

    This option isn't for everyone, but you should at least know that it exists.  It is possible for you to work with your Oracle account manager and Oracle Advanced Customer Services to get a Service Delivery Manager assigned to your organization.  A Service Delivery Manager can act as your primary contact within Oracle Support, and can help escalate Service Requests, engage Development teams, and coordinate responses from multiple groups for complex issues.

    My experience is that this option is very useful for large, complex organizations who have equally large, complex, and time-sensitive E-Business Suite projects underway.  In situations where you're logging a large number of interrelated or overlapping Service Requests against many different Oracle products, having a Service Delivery Manager can be useful in keeping track of everything.  Service Delivery Managers can also hold regular status calls to review your open issues, and can escalate open Service Requests directly to Oracle Development teams.

    It's also important to note that Oracle Advanced Customer Services offers the option of technical teams that can be engaged proactively to provide guidance and hands-on services that may help avoid Service Requests entirely. 

    Option 6: Register with the Applications Development Customer Program

    Another customer support program within the E-Business Suite division exists:  the Applications Development Customer Program. 

    The Applications Development Customer Program is primarily responsible for managing the Applications development portion of key customer projects and customer escalations. This involves engaging development resources across the Applications Suite Development Division, coordinating with Oracle Support and Oracle Consulting, and keeping Oracle executive management up to date on the most strategic customer projects and most critical escalations.

    Your Oracle account manager can help get your organization registered with this program.  If your Oracle account manager is unfamiliar with this program, he or she can find out more at this internal Oracle Applications Development Customer Program website (also no external customer access).

    Be Proactive, Be Assertive, Be Persistent

    My experience is that large, complex organizations benefit from registering with both the Critical Accounts Program and the Applications Development Customer Program before embarking upon major upgrades.  For example, if you're planning on upgrading from Oracle E-Business Suite Release 11i to 12, it would be worth considering getting registered before you start your project.

    The advantages of being proactive are legion:  you get a predetermined escalation path, Development organizations become familiar with your requirements and environment before you start logging Service Requests, and you effectively prime the pump in case you run into issues.

    And lastly: be assertive, and don't give up.  I see Service Requests where customers have only just begun to investigate an issue with Support and/or Development... only to have the customer disappear.  Some customers just stop responding to requests for more information in their Service Requests. 

    I find this a bit mystifying.  As you can see, if you're not getting what you need to resolve your issues, there are many options for getting help.  Be persistent and escalate up the channels as needed.

    Related Articles

    Tuesday Sep 15, 2009

    Recommended Database Parameters Updated for EBS 12

    Close on the heels of our recent updates to the recommended EBS 11i Database parameters, our database and applications performance architects have published updates for EBS Release 12. The updated note is now available here:

    Our architects have refreshed a large number of recommended settings based upon customer feedback and their ongoing performance and scalability tests.


    New updates

    • Removal of Application Upgrade Considerations section.
    • Addition of Advanced Queuing (AQ) note to common parameters.
    • Addition of note to the job_queue_processes
    • Addition of diagnostic_dest to 11gR1-specific parameters.
    • Addition of background_dump_dest, user_dump_dest, core_dump_dest to 11gR1 removal list.
    • Addition of plsql_native_library_dir, plsql_native_library_subdir_count, plsql_optimize_level to 11gR1 removal list.
    • Addition of #MP to _optimizer_autostats_job=false.
    • Updates to undo_retention section.
    • Addition of Timed_Statistics.
    • Addition of nls_language, nls_length_semantics, _sqlexec_progression_cost.
    • Removal of nls_length_semantics.
    • Removal of SGA_TARGET from Sections 2, 3, and 4, as this is in the common parameters.
    • Removal of db_block_buffers row from sizing table.
    • Updates to "Specific Notes on Table."
    • Updates to common parameters introduction.

    As we've noted before, these changes are extremely important and can have profound impact on the performance of your Apps database.  All Apps DBAs should spend some quality time comparing your current database settings with the latest recommendations in this document.

    Related Articles

    Thursday Aug 27, 2009

    Turbocharging Your EBS 12.0 Techstack Upgrade

    [Oct 4, 2010 Update:  Since this article was published last year, there have been several updates to the patches list for the respective Oracle Homes (10.1.2, 10.1.3 and based on customer issues and internal testing. The Rapid Install content for those Oracle Homes has not been updated with the same updates.  Hence, the patches delivered by the EBS 12.1.1 Rapid Install will not be the latest baselines available for those technology stack components.  If you use this Rapid Install method, you still will need to refer to the respective documents to apply the latest patches added after the EBS 12.1.1 Rapid Install was released.  For pointers to those documents, see the individual listings for the respective techstack components in this certification summary.]

    All three of the major new technology stack components included in Oracle E-Business Suite Release 12.1.1 are also certified with Release 12.0.  You could manually upgrade each of these R12.0 techstack components yourself.  But now that Release 12.1.1 is out, why bother with that time-consuming approach when there's an easier and faster way?

    You can use the EBS 12.1.1 Rapid Install to upgrade just the application and database tier technology stack components in your existing EBS 12.0 instance. Your technology stack components are upgraded to the same versions delivered with EBS 12.1.1 while leaving your EBS 12.0 product code (e.g. Financials, Supply Chain) untouched.


    Running the Rapid Install with the -techstack option

    Using the rapidwiz -techstack option with the EBS 12.1.1 Rapid Install provides options to upgrade the applications and database tier components for the following ORACLE_HOMEs:
    1. Application Server 10g OC4J to (Applications tier)
    2. Application Server10g Forms and Reports to (Applications tier)
    3. Database Release 10gR2 to 11gR1 version (software and configuration files only on the DB tier. DB upgrade and post install steps to be performed separately)
    From the first screen below, you can select the respective tier and proceed with the upgrade.


    1. Upgrading the Database Technology Stack

    Before selecting the database tier technology stack upgrade, make sure that your environment meets the minimum operating system prerequisites for running the 11gR1 Database.

    If you choose the database tier upgrade, the wizard takes inputs for the Database host, Oracle SID, ORACLE_HOME and OS user related inputs.


    It creates the new ORACLE_HOME with the associated Release 12.1.1 patches for the 11gR1 Database.  The installation then proceeds with installing the 11gR1 database software and the required configuration files for the E-Business Suite.


    After the installation and configuration is complete, you need to complete the remaining DB upgrade steps using Section 1 and Section 2 of Interoperability Notes for 11gR1 with EBS R12.

    2. Upgrading the Applications tier Technology Stack

    If you choose to upgrade your applications tier, the Rapid Install wizard requires the CONTEXT file for your existing configuration. Point the wizard to the Application tier context file for your applications tier, e.g. $INST_TOP/appl/admin/<context name>.xml.


    The wizard identifies the respective ORACLE_HOMEs from the context file and proceeds to upgrade these components.


    After validating and confirming the information, the installer proceeds to upgrade the components in the two Oracle Application Server 10g 10.1.3 and 10.1.2 ORACLE_HOMEs.


    After all of the new Oracle Application Server 10g files are laid down in your filesystem, the Rapid Install wizard validates the installation. A green tick on the Validation window means the installation passed the post-install checks.


    Once you've run this upgrade on all of the Application tier nodes in your EBS instance, you're done!  Automated, validated, and fast.

    Related Articles

    Tuesday Aug 25, 2009

    Distinguishing Between E-Business Suite 12.1 and 12.0 Patches

    Sometimes our release processes get ahead of our internal infrastructure.  This happened when we released Oracle E-Business Suite Release 12.1.1.  We discovered post hoc that it was not possible to distinguish between patches intended for Apps 12.1 and those intended for Apps 12.0 in the "Patches & Updates" function in My Oracle Support and Metalink.  Whoops -- clearly suboptimal.

    This issue was resolved in mid-July, when the Patches & Updates function got a brand-new "Compatible With" column:

    The new "Compatible With" column clearly distinguishes between the patches for each Release 12 codeline now.

    Don't Mix and Match R12.0 and R12.1 Patches

    This distinction is important.  You shouldn't attempt to apply an R12.1 patch against your R12.0 instance, or vice versa.  If you tried to do that, you'd see a somewhat-cryptic error message like this:
    AutoPatch error:

    This patch is not compatible with your current codelines.

    This patch is compatible with: entity 'gl' - codeline 'R12.GL.A'.
    Your current on-site codeline for the entity 'gl' is: 'R12.GL.B'.

    You should not apply this patch.

    Apply an equivalent patch that is compatible with your
    current codelines instead.
    Sorting Patches Out After They've Been Downloaded

    It's now easy to tell patches apart on the "Patches & Updates" download screen, but how can you tell them apart after they've been downloaded?  It's pretty simple. You can identify the codeline for a given patch by the letter in the third-digit:
    • Patches for EBS 12.0 will show an 'A' (e.g. "8414069.R12.AR.A")
    • Patches for EBS 12.1 will show a 'B' (e.g. "8414069.R12.AR.B")
    For more tips about telling these patches apart, see:

    Monday Aug 24, 2009

    OPatch Essentials for Apps Sysadmins

    All EBS administrators must become very familiar with the OPatch utility.  OPatch is used to patch the ORACLE_HOMEs in EBS Application and Database tiers.  Security fixes delivered for these ORACLE_HOMEs through Critical Patch Updates are also applied using OPatch.  It updates the central and per-product inventories with the details of each patch applied.  Apart from the Oracle Universal Installer (which internally also uses OPatch), this is the only tool authorized to patch ORACLE_HOMEs. 

    Although it once had a reputation for being somewhat arcane, OPatch has evolved over the years into a more user-friendly and better-documented tool.  I'll cover the essentials of using OPatch in this article.


    Prerequisites for Running OPatch

    OPatch is a set of perl scripts that allow the application and rollback of interim patches to the ORACLE_HOMEs. It requires the Perl language interpreter and requires, at minimum, Perl version 5.005_03 or higher.  Version 5.6 or higher is recommended.

    OPatch expects jar, java, ar, cp, and make commands (depending on the platform) to be available in the current PATH. EBS users have these available as part of the current PATH once the respective tier environment file is sourced.

    What Does OPatch Do?

    In Oracle E-Business Suite releases where a Rapid Install option is available, the installation process installs and maintains the OUI inventory for each of the ORACLE_HOMEs using OPatch. A query of each of the ORACLE_HOMEs created by a Rapid Install lists the patches installed.

    OPatch can be used to:
    • Apply an interim patch

    • Roll back the application of an interim patch

    • Detect a conflict when applying an interim patch after previous interim patches have been applied. It also suggests the best options to resolve a conflict.

    • Report on installed products and interim patches.
    Key OPatch Concepts
    Oracle Universal Installer
    When an installation is performed using the Oracle Universal Installer, the OUI inventory records the ORACLE_HOME, SID, location, products and technology versions installed.  The E-Business Suite Rapid Install maintains a global inventory of all its Oracle products. The location on Linux is specified in the /etc/oraInst.loc file.

    [Editor:  Also see: Oracle Universal Installer Inventory Essentials for Apps Sysadmins]


    The file on Unix where the inventory location and the OS group of the install user.

    patch_storage directory

    This directory stores information about the patches applied.
    Important OPatch Runtime Options and Arguments
    OPatch is located in the <Path_to_Oracle_Home>/OPatch directory.  You can run it with various commands and options. The following string shows the syntax for the OPatch utility:
    <Path_to_OPatch>/opatch [-help] [-r[eport]] [command] [-option]


    The most commonly-used commands running OPatch are:
    1. opatch apply ...

    This command applies a patch from the patch directory.  The OUI inventory is updated with the patch's information.

    2. opatch rollback ....

    This is the command to rollback or undo a patch installation. The respective patch information is removed from the inventory.

    3. opatch lsinventory

    lsinventory lists all the patches installed on the Oracle Home.

    4. opatch lsinventory -detail

    lsinventory -detail gives list of patches and products installed in the ORACLE_HOME.

    5. opatch version

    version option displays the version of OPatch installed.

    6. opatch napply

    napply applies the patches in a directory. This is used in EBS environments while applying a patch that is a bundle of individual patches. napply eliminates the overhead of running opatch multiple times by the administrator. The napply option skips subsets or duplicates if they are already installed.

    7. opatch nrollback

    nrollback rolls back the patches using the IDs specified.

    8. opatch  apply -minimize_downtime

    This is specific to Real Application Clusters (RAC) enabled instances (DB tier patches).  The -minimize_downtime option allows you to apply a patch by bringing down one database server instance at a time.  OPatch applies the patch to the quiesced server instance, the instance is brought back up, and then OPatch moves on to the next database server  in a Real Application Clusters pool.

    9. opatch apply -force

    -force overrides conflicts with an existing patch by removing the conflicting patch from the system.

    Caution: This option should be only used when explicitly it is said safe to be used in the README of the patch.

    10. opatch apply -invPtrLoc <...>

    The option -invPtrLoc can be used to specify the oraInst.loc file in case it's not in the default location e.g., /etc/oraInst.loc in Linux.  The argument to this option is the location of this file.

    11. opatch query

    The query command can be used to find out useful information about the patch

    Syntax to be used:

    opatch query  [-all] [-jre <LOC> ] [-oh <LOC> ] \ 
    [-get_component] [-get_os] [-get_date] [-get_base_bug] \
    [-is_rolling_patch] [-is_online_patch] \
    [-has_sql] [ <Patch Location> ]


    Retrieves all information about a patch. This is equivalent to setting all available options.


    Retrieves bugs fixed by the patch.


    Retrieves components the patch affects.


    Retrieves the patch creation date and time.


    Indicates true if the patch is an online patch. Otherwise, the option is false.


    Indicates true if the patch is a rolling patch. Otherwise, the option is false.


    Specifies the Oracle home directory to use instead of the default directory. This takes precedence over the ORACLE_HOME environment variable.

    Patch Location

    Indicates the path to the patch location. If you do not specify the location, OPatch assumes the current directory is the patch location.

    Where's the Official OPatch Documentation?

    A well written User Guide and FAQ are shipped with every OPatch version and are available under the OPatch/doc directory of the ORACLE_HOME. These documents list all the arguments and options available with OPatch.

    I strongly recommend the administrators who are in charge of applying the patches to carefully read the above documents as well as the ORACLE_HOME version-specific OPatch documentation on Metalink. Latest OPatch versions for 10.1, 10.2 and 11.1 are available for download via Patch 6880880

    A New Option For Critical Patch Updates (CPU)

    Oracle introduced the napply option in July 2007 with Critical Patch Updates for its DB tier patches on Unix platforms for 10gR2 version and higher. This provides conflict resolution and the ability to merge patches for CPU fixes.  This eliminates the CPU merge patch.  It also reduces downtime by eliminating the need to rollback and reinstall patches that are already installed. Customers can continue to partial apply and get other security fixes in place while waiting for a merge conflict resolution from Oracle's Database Support team.

    Common OPatch Issues
    Conflicts Between Patches
    Conflicts occur when you try to apply a patch whose fix already been applied through another patch.  DBAs are advised NOT to use the -force option with apply as this removes the conflicting fix from the system. All conflicts need to be resolved by contacting Customer Support.

    Errors due to Java locations

    Make sure that the Java JDK and JRE prerequisites are available in the PATH or provided in command line option. The -jre and -jdk options allow you to specify these explicitly instead of using the ones from ORACLE_HOME.  EBS customers generally do not need to specify -jre or -jdk options because sourcing the respective ORACLE_HOME .env file will include the correct jre/jdk locations in the PATH.
    Related Articles

    Friday Aug 21, 2009

    Configuring SSL with a Configuration Wizard in EBS R12

    E-Business Suite R12.1.1 provides Advanced Configuration wizards that make it easier to deploy features such as SSL and load-balancing.  Apps administrators can use these wizards to make configuration changes online through Oracle Applications Manager (OAM) and then run AutoConfig on the applications tier to make the changes effective.

    SSL (Secure Sockets Layer) is one of the most commonly used configurations in EBS. I'll walk through the SSL Advanced Configuration Wizard in this article.

    Accessing the Advanced Configuration Wizards

    Launch the Oracle Applications Manager Site Map using the System Administrator responsibility, then select the AutoConfig link from the Administration tab.


    Click on Launch Wizards. It brings up the launch pad for five wizards:

    1. Forms Socket Mode
    2. SSL
    3. SSL Accelerator
    4. HTTP Load Balancing
    5. OC4J Load Balancing


    Start the SSL Configuration Wizard

    The OAM General Collection Service must be activated before running any configuration wizards.  From the Administration tab of the Site Map, click on the 'Generic Services' link under the Application Services. Select 'OAM Generic Collect Services' and start it for the target instance. OAM submits a concurrent request for the same. Click on Verify to see if the service starts up fine. Once the service starts, you are ready to use the wizard.

    From the Configuration Wizards launch pad, click on the 'Enable' button for SSL.

    Select Nodes to be SSL-Enabled

    Select the nodes on which you would like to enable SSL and click 'Next.'


    2. Set Context variables for SSL

    Notice the tip at the bottom of the Parameters screen:  you should make sure that your digital certificates are properly imported into the Wallet of your EBS instance. For details about importing SSL certificates, see:


    The wizard sets the following context variables to 'https':

    • URL protocol
    • Local URL protocol

    It also sets values for the 'Web SSL directory' and the 'Active HTTP SSL port.' The subsequent screen gives the current and new values for these variables.

    3. Validation

    The wizard validates all settings when you click 'Next' after the user comparison of context values screen.  It checks that the Wallet and the required directory structures exist.


    Make sure that the Status is 'Success.' Check the log file in the 'View' link for any errors.

    4. Confirmation Page

    Clicking 'Next' will take you to the Confirmation Page in the train cart. Click on the link below to check the confirmation page.

    View image

    5. Submit the changes and run AutoConfig

    Clicking the 'Submit' button on the Confirmation page displays the next action to be taken. You can review the context file on the applications tier for the changes that have been made.

    The next step is to run AutoConfig to propagate the changes. You need to restart all application services to make the changes effective.

    Once the service have been restarted, the EBS instance is ready to be used in SSL mode.


    Related Articles


    « July 2016