Friday Jul 26, 2013

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

Oracle E-Business Suite Release 12.1.1 Consolidated Upgrade Patch 2 (CUP2) is now available in My Oracle Support. This patch includes fixes and performance improvements for the scripts used to upgrade an EBS 11i environment to 12.1.1.

This patch is 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)

This patch includes all of the upgrade-related fixes released previously in the Consolidated Upgrade Patch 1 (CUP1, Patch 7303029) and many additional upgrade related fixes released since March 2010. 

You can download it here:



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

The Consolidated Upgrade Patch 2 (CUP2) 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 CUP2.

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 CUP2?

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 CUP2 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, 12.0.6), you should not apply Release 12.1.1 CUP2.

Can I apply Release 12.1.1 CUP2 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 CUP2 only while upgrading a Release 11i Oracle E-Business Suite instance to Release 12.1.1

Is Release 12.1.1 CUP2 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 CUP2 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 CUP2 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.
References
Related Articles

Wednesday Aug 15, 2012

Five Errors Customers Make When Upgrading E-Business Suite 12 (Part 5)

This is the fifth in a series of articles about common technical myths or misunderstandings about the E-Business Suite. Other articles have covered installations, cloning, patching, migrations, and maintenance. This article discusses upgrading. 

Each article is absolutely not definitive and I’d be interested in comments from readers who think there are other misconceptions about the day to day maintenance and upgrade of a typical E-Business Suite environment.


COMMON ERROR #1: Believing that DBUA does not work for Apps databases.

ORACLE’S RECOMMENDATION: Many DBAs still like to perform database upgrades manually using Oracle-provided scripts as they feel it gives them more control of the upgrade process. For the rest of us, DBUA is an excellent tool that greatly simplifies the upgrade process and which should reduce your upgrade time. E-Business Suite database upgrade documentation now assumes (but does not mandate) that you will use DBUA and documentation will be written accordingly. Raise a Service Request if you believe you have an issue where DBUA fails and the manual process is required instead.


COMMON ERROR #2: Assuming that only one test upgrade is needed before the production upgrade.

ORACLE’S RECOMMENDATION: Oracle advise a minimum of three completely successful tests of any upgrade or maintenance downtime before your production upgrade.


COMMON ERROR #3: Using generic documentation instead of the E-Business Suite versions.

ORACLE’S RECOMMENDATION: As an example, if you need to upgrade your database do not just refer to the standard database upgrade manuals. The E-Business Suite Development Team have created documentation specifically for upgrading the E-Business Suite technology stack to supplement generic documentation. Follow these supplemental documents. They are well written, thoroughly tested and will make your upgrade a success.


COMMON ERROR #4: Skipping new products included in Release Update Packs (RUPs) because there are no plans to use that product.

ORACLE’S RECOMMENDATION: When instructed to add new products to your database as part of a RUP you must always add those products. These products will later be patched and updated by this or later RUPs and if the products are not present then the patches will fail.


COMMON ERROR #5: Manually copying files between different E-Business Suite environments.

ORACLE’S RECOMMENDATION: New or replacement files should only be introduced to your system by patching, scheduled upgrades or other documented methods. Manually copying files between systems can cause mismatches between files in the APPL_TOP and their corresponding entries in database AD tables. This could cause patching issues later.

Related Articles


Tuesday May 01, 2012

EBS File Comparison Report Now Available

If your Oracle E-Business Suite customizations are still making you hesitate about upgrading from Release 11i to Release 12, we have another useful tool to help you along: the brand new EBS File Comparison Report. This new report joins the related EBS Seed Data Comparison Report and the EBS Data Model Comparison Report in our collection of handy upgrade comparison reports.

You can download the new file comparison report here:

You can download its companion reports here:

File Comparison Report Contents

The new report provides detailed information about what files were added, removed, or stubbed (made inactive) during changes between Releases 11.5.10.2 and 12.1.3 of Oracle E-Business Suite. For text-based files such as .xml files, you can drill down into the files to see the actual changes between the file versions. The File Comparison Report includes the following file types:

  • Forms (.fmb files)
  • Libraries (.pll files)
  • Reports (.rdf files)
  • Java (.class files)
  • Java Server Pages (.jsp files)
  • Oracle Application Framework (OAF) Pages (.xml files)
  • Oracle Application Framework (OAF) Personalizations (.xml files)
  • Workflow Definition (.wft files)
  • Workflow Business Event System Object Definitions (.wfx files)
  • BI Publisher (XML Publisher) Reports - Layout template formats
  • BI Publisher (XML Publisher) Reports - Data Definition formats

Using the File Comparison Report

One example of how you might use the File Comparison Report is for assessing upgrade impacts on your personalizations. Start by getting a list of your personalizations as described in “Upgrading Form Personalizations and OA Framework Personalizations from Oracle E-Business Suite Release 11i to 12.1” (Note 1292611.1).

Three categories of personalizations might be affected by upgrades. Here is how the File Comparison Report can help you with those:

  1. Personalizations shipped by product teams that you might have modified further: look at “Oracle Application Framework (OAF) Personalizations (.xml files)” to see which shipped personalizations have changed. You can drill in to see exactly what has changed for each affected personalization.
  2. OA Framework Personalizations where the shipped base page may have changed: look at “Oracle Application Framework (OAF) Pages (.xml files)” to see which shipped pages have changed. You can drill in to see exactly what has changed for each affected personalization. If a page you have personalized hasn’t changed between releases, you probably do not need to change your personalizations for the page in the new release.
  3. Oracle Forms Personalizations where the shipped form may have been removed: look at “Forms (.fmb files)”. Because these are binary files, you cannot see exactly what has changed for each form, but knowing what forms have been removed will still save you time in assessing what form personalizations can be retired.

Personalization assessment is just one example of how you can use the File Comparison Report. We expect you will find many ways to use it!

Your feedback is welcome

This new tool was produced by our hard-working EBS Release Management team, and they are actively seeking your feedback. Please feel free to share your experiences with it by posting a comment here. You can also request enhancements to this tool via the My Oracle Support Community mentioned in Note 1446430.1.

Related Articles

Tuesday Apr 10, 2012

Webcast Replay Available: E-Business Suite Release 12.1 Upgrade Best Practices - Technical Insight

I am pleased to release the replay and presentation for the latest ATG Live Webcast:Image to show the cycle of E-Business Suite 12.1 upgrades
E-Business Suite Release 12.1 Upgrade Best Practices - Technical Insight (Presentation)
Udayan Parvate, Director, E-Business Suite Release Engineering and Uday Moogala, Senior Principal Engineer, Applications Performance discussed the best practices that you can apply when upgrading your E-Business Suite instance to Release 12.1 and beyond. They discussed upgrade paths, resources, and practices to minimize downtime during the upgrade. (April 2012)

Finding other recorded ATG webcasts

The catalog of ATG Live Webcast replays, presentations, and all ATG training materials is available in this blog's Webcasts and Training section.

Friday Mar 16, 2012

New Whitepaper: Upgrading your Customizations to Oracle E-Business Suite Release 12

Cover page for upgrading customizations whitepaperThe prospect of upgrading from Oracle E-Business Suite Release 11i to Release 12 might seem intimidating if you have customized your EBS 11i environment. When considering this upgrade, one of the first things you need to do is review your customizations systematically.

I am pleased to announce the availability of a new white paper that will help you do that:

This white paper provides an overview of how you can manage and upgrade existing Release 11i customizations to Release 12.1. It covers identifying the various types of customizations you might have--such as personalizations, Oracle Forms, Web ADI, and mod_plsql--and how to handle them during your upgrade.

The document discusses upgrading Oracle E-Business Suite customizations in the context of the following cycle:

  1. Creating an inventory of your existing customizations
  2. Comparing customizations to standard Release 12 functionality
  3. Upgrading customizations
  4. Reimplementing customizations
  5. Creating future customizations

The paper also provides recommendations on customization technologies such as Oracle Application Framework (OAF), Oracle Application Express (APEX), and Oracle Application Development Framework (ADF).

This white paper is written for Oracle E-Business Suite system administrators, DBAs, developers, and implementers.

Related Webcast

Related Articles

Wednesday Mar 07, 2012

ATG Live Webcast: E-Business Suite Release 12.1 Upgrade Best Practices - Technical Insight

Are you deep into the planning for your upgrade from 11i or 12 to the latest 12.1.3 version of E-Business Suite? Are you planning in anticipation of the upgrade to 12.2? If you are at any stage in your upgrade planning, you need to attend this event. Even if you are not currently planning an upgrade, this presentation will prepare you properly for the next upgrade you undertake. The next installment of our ATG Live Webcast series is on Mar. 8, 2012:

E-Business Suite Release 12.1 Upgrade Best Practices - Technical Insight

Image to show the cycle of E-Business Suite 12.1 upgradesJoin Udayan Parvate, Director, Release Engineering and Uday Moogala, Senior Principal Engineer, Applications Performance as they discusses E-Business Suite 12.1 topics. They will start with an overview of the process, and they will include some of the essential best practices that will help you minimize downtime during your upgrade. They will even share customer upgrade snapshots; so, you can understand how real customers accomplished real upgrades to 12.1.

The agenda for the E-Business Suite Release 12.1 Upgrade Best Practices - Technical Insight webcast includes the following topics:

  • 12.1 Upgrade Overview
  • 12.1 Supported Upgrade Paths
  • 12.1 Upgrade Resources
  • 12.1 Upgrade Best Practices to Minimize Downtime

Date:              Thursday, March 8, 2012
Time:              8:00 AM - 9:00 AM Pacific Standard Time
Presenter:    Udayan Parvate, Director, Release Engineering
                        Uday Moogala, Senior Principal Engineer, Applications Performance

Webcast Registration Link (Preregistration is optional but encouraged)

To hear the audio feed:
    Domestic Participant Dial-In Number:           877-697-8128
    International Participant Dial-In Number:      706-634-9568
    Additional International Dial-In Numbers Link:
    Dial-In Passcode:                                              99339

To see the presentation:
    The Direct Access Web Conference details are:
    Website URL: https://ouweb.webex.com
    Meeting Number:  599153712

If you miss the webcast, or you have missed any webcast, don't worry -- we'll post links to the recording as soon as it's available from Oracle University.  You can monitor this blog for pointers to the replay. And, you can find our archive of our past webcasts and training here.

If you have any questions or comments, feel free to email Bill Sawyer (Senior Manager, Applications Technology Curriculum) at BilldotSawyer-AT-Oracle-DOT-com. 

Tuesday Feb 07, 2012

Best Practices for Combining EBS Upgrades with Platform Migrations

Odds are that you're planning an EBS upgrade soon.  EBS 11i Extended Support runs out in 2013, and EBS 12.0 Premier Support ended in January 2012. You might need to combine your EBS upgrade with a operating system upgrade or hardware migration for your servers, too.

Projects that combine EBS upgrades with migrations pose some interesting questions.  What tools do you use if you're...:

  • ... upgrading to a newer version of your current operating system?
  • ... migrating to a different platform with the same endian format?
  • ... migrating to a different platform with a different endian format?

Diagram showing small endian and big endian platforms

Evaluating the different options

I have published a new whitepaper that provides a comprehensive evaluation of the different mechanisms available in upgrading the Oracle E-Business Suite while considering platform migration. This document is meant as an overview to supplement existing detailed documentation that outlines specific processes to perform the migration:

This whitepaper discusses the use of Transportable Database, Recovery Manager (rman), Export/Import using Datapump, Transportable Tablespaces (TTS), Rapid Install, and Release Update Packs.

Application server vs. database server upgrades

Platform migrations may considered separately for the application and database tiers, or for both tiers together. In either case, it is critical to understand that the migrations are separate processes that can be thought of logically as such. This is especially crucial in light of potentially reducing downtimes by breaking them out into separate discrete events which may have different considerations for users and administrators.

Upgrade your database server before upgrading EBS

We recommend that you migrate your database to a new version and new server platform first.  This allows you to perform this in a separate earlier downtime.

For example, you might wish to migrate your EBS 11.5.10.2 database tier running 11gR2 to Oracle Linux 5 on newer and faster hardware prior to an R12 upgrade. Performing this migration first would leave the your environment in a certified configuration that you can continue using until you wish to perform your EBS R12 upgrade.

Regardless of whether this migration is done in a separate earlier downtime or as part of a single downtime, the newer hardware would allow the EBS upgrade to go faster.

Best practices for combined upgrades

Here are our recommendations when performing EBS upgrades and platform migrations in a single project:

  1. Consider the database and application tier migrations separately and plan to perform the database migration first.

  2. Choose the right migration process for the database while considering the target platform, database size and process complexity.

  3. Migrate and upgrade your EBS application tier from 11i to R12 by laying down the new application tier on the target platform as part of the upgrade.

For more details, see:

Related Articles

Tuesday Jun 21, 2011

EBS Seed Data Comparison Reports Now Available

Earlier this year we released a reporting tool that reports on the differences in E-Business Suite database objects between one release and another.  That's a very useful reference, but EBS defaults are delivered as seed data within the database objects themselves. What about the differences in this seed data between one release and another?

I'm pleased to announce the availability of a new tool that provides comparison reports of E-Business Suite seed data between EBS 11.5.10.2, 12.0.4, 12.0.6, 12.1.1, and 12.1.3.  This new tool complements the information in the data model comparison tool.  You can download the new seed data comparison tool here:

Screenshot of summary of seed data comparison report top level

The EBS ATG Seed Data Comparison Report provides report on the changes between different EBS releases based upon the seed data changes delivered by the product data loader files (.ldt extension) based on EBS ATG loader control (.lct extension) files.  You can use this new tool to report on the differences in the following types of seed data:
  • Concurrent Program definitions
  • Descriptive Flexfield entity definitions
  • Application Object Library profile option definitions
  • Application Object Library (AOL) key flexfield, function, lookups, value set definitions
  • Application Object Library (AOL) menu and responsibility definitions
  • Application Object Library messages
  • Application Object Library request set definitions
  • Application Object Library printer styles definitions
  • Report Manager / WebADI component and integrator entity definitions
  • Business Intelligence Publisher (BI Publisher) entity definitions
  • BIS Request Set Generator entity definitions
  • ... and more
Your feedback is welcome

This new tool was produced by our hard-working EBS Release Management team, and they're actively seeking your feedback.  Please feel free to share your experiences with it by posting a comment here.  You can also request enhancements to this tool via the distribution list address included in Note 1327399.1.

Related Articles

Thursday Feb 17, 2011

Identifying Data Model Changes Between EBS 12.1.3 and Prior EBS Releases

[Update June 21, 2011: A complementary tool that compares seed data between different EBS releases is now available.]

The EBS 12.1.3 Release Content Document (RCD, Note 561580.1) summarizes the latest functional and technology stack-related updates in a specific release.  The E-Business Suite Electronic Technical Reference Manual (eTRM) summarizes the database objects in a specific EBS release. 

Those are useful references, but sometimes you need to find out which database objects have changed between one EBS release and another.  This kind of information about the differences or deltas between two releases is useful if you have customized or extended your EBS instance and plan to upgrade to EBS 12.1.3. Where can you find that information?

Answering that question has just gotten a lot easier.  You can now use a new EBS Data Model Comparison Report tool:

This new tool lists the database object definition changes between the following source and target EBS releases:
  1. EBS 11.5.10.2 and EBS 12.1.3
  2. EBS 12.0.4 and EBS 12.1.3
  3. EBS 12.1.1 and EBS 12.1.3
  4. EBS 12.1.2 and EBS 12.1.3
For example, here's part of the report comparing Bill of Materials changes between 11.5.10.2 and 12.1.3:
Screenshot of EBS data model comparison report for Bill of Materials 12 1 3 and EBS 11 5 10 2 bom_1213_diffs.png

What types of database objects does this tool cover?

This tool includes reports of the differences in:
  • Regular tables
  • Partitioned tables
  • Index organized tables
  • Global temporary tables
  • Queued tables
  • Views
  • Indexes
  • Sequences
  • Materialized views
  • Materialized view logs
  • Advanced queues
  • Packages
  • Triggers
  • Types
Your feedback is welcome

This new tool was produced by our hard-working EBS Release Management team, and they're actively seeking your feedback.  Please feel free to share your experiences with it by posting a comment here.  You can also request enhancements to this tool via the distribution list address included in Note 1290886.1.

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!

References

Related Articles


Monday Jan 24, 2011

In-Depth: Thoughts on Testing from a Battle-Scarred Support Engineer

[Editor's Note: Weighing in at over 3,100 words, Nick Quarmby's treatise below is more of a whitepaper-in-disguise than our traditionally-short blog articles.  This article is worth your time, though.  In my experience, shortchanging testing simply translates to longer upgrade times downstream.  With EBS 11i now in Extended Support, everyone still on that release should already have their R12 planning underway.  Nick's insights and tips are worth careful consideration by everyone, but particularly so for if you're planning your R12 upgrade.]



"The more I practice, the luckier I seem to get."

"If you think safety is expensive, just try having an accident."

The two quotes above I think pretty accurately sum up the importance of preparation and planning. The first has been attributed to various professional golfers over the years and suggests luck is never accidental. If things work, they work for a reason and that reason is usually because of good preparation, not good luck.

The second quote has been attributed to various airline industry executives. Here the message is that however much time, and inevitably money, that you spend making sure your planes do not crash, it will cost you considerably more if one of them does.

The real message is of course that planning and preparation pay off in the long term and, in the context of your Oracle Applications upgrade, you can conclude that successful upgrades are the result of good testing, not good fortune.

This article is just a few thoughts from a battle-scarred Support Engineer on why good testing is crucial to the success of your system and why it is important for you to thoroughly test any patches, upgrades or migrations before carrying out the work on your production environment. The great majority of the work that you do in any project will be testing. Underestimate it at your peril. Testing is not simply a necessary evil which has to be endured before the inevitable, white-knuckle ride of the production upgrade. Testing is not where you should be cutting corners. Testing is where you should be going into every conceivable corner you can find and looking for something that might, without warning, jump out of the shadows and derail your production upgrade.

There are links at the end of the document to various tools you have access to which may help your testing but this article is not intended to go into the specifics of testing but simply to discuss how testing should be approached and hopefully raise awareness of the consequences of not doing enough testing.

Preparation

A significant Oracle Applications upgrade is a project that will be measured in months, not weeks. The most important part of that long process will be the work that is done before the production upgrade.

A requirement to upgrade a system or perform maintenance is usually triggered via a business or technical requirement. Once a need to upgrade is identified, the work always seems to be considered urgent - these days everything is urgent. Early on in the project you need to clearly identify what is needed to achieve a successful upgrade and present this to the people driving the project. You may sometimes feel you are presented with unreasonable timescales to complete a project and commercial pressures beyond your control have placed you in this position. This is sometimes an inevitability but it is for these reasons that, as early as possible in a project, you emphasise to the people driving your business that systems do not change over the course of one frenetic weekend. Well, actually, they do, but what happens during that weekend is simply the tip of the iceberg.

Behind the scenes you must do a lot of work to prepare for that tiny weekend window at the end of your long project plan. It's sometimes inevitable that tasks tend to concertina towards the end of a project and, whilst some people work better under pressure with a visible and looming deadline, many others do not. Use your time wisely unless you look forward to sleepless nights.

Testing should be performed on a complete cloned copy of your production environment, and, where possible, on an identical hardware environment. If migrating to new hardware, your upgrade testing should include the new hardware so you are confident you can configure the software on the new hardware and that it performs correctly in the new environment.

You should never consider applying untested patches on your production environment.  However urgent a patch may be, it is never so urgent you should risk the stability of the whole production environment by applying it untested. Oracle Applications patches (patches applied using adpatch) are not reversible without using database rollback/flashback features and it would also require a detailed analysis of the patch and its log files in conjunction with your specific system. You should never assume you can manually reverse even the simplest of Oracle Applications patches. Oracle Support cannot provide this service for you remotely via a Service Request (SR).

Do not rely on the assurances of your suppliers and assume everything will work on the day. You need to prove to yourself that your suppliers will deliver what you need and when you need it. Contact them early in the project - they will be grateful for the opportunity to be part of your plans. If things go wrong, having a supplier to blame for things not working may absolve you of some responsibility but you will still have to present this failure within your organisation and that will reflect on you, no matter how much you consider that you were not responsible for that failure.

Always follow the documentation.   Context sensitive documents exist for upgrading all components of Oracle Applications and should be followed. If you cannot find an appropriate document for a process in your upgrade, contact Oracle Support who should be able to advise you of the right Note or manual to follow. Do not assume generic documentation will be applicable to your Oracle Applications environment.

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.

Consider phasing your upgrade.  If a major upgrade involves both a database and Applications upgrade you may be able to perform this in separate, shorter downtimes. 10gR2 and 11gR2 are certified on both 11i and R12 so you could perform a database upgrade during your first downtime, return the system to your users and perform the Applications upgrade in the second downtime at a later date. This will increase the testing you have to do and will also require additional user acceptance testing but you may find this method works for you.

Testing is not just to establish that the technical upgrade is a success. Testing should also include ensuring that the system you build performs acceptably under load and remains stable. The links at the end of this article refer to products you can use to measure performance and load on your environment. 

The truth is the hardest work you will do in your whole upgrade project will be the testing and preparation. It is during testing that you will find where you have to reduce what takes two weeks into something that you'll be lucky to get 48 hours to perform. It is during testing that you will have to find imaginative ways to solve the issues you encounter.


Issues Encountered During Testing

Some people see testing as something that is only for the overly cautious - those people who are too scared to confront real-time events when they arise. We may live in an increasingly risk-averse society but the truth is that smart people are always testing. Only fools rush in. A macho or cavalier attitude to testing rarely produces a reliable or stable environment.

Your testing will reveal issues that have to be solved.  These truly are opportunities and not problems. This is why you are testing in the first place - so that you do not see these errors when you come to the production upgrade. If you encounter issues during testing then you must find a solution to these issues or find a workaround that does not compromise the rest of the upgrade. Skipping a documented step because you don't think it's significant can easily cause problems further down the line. 

Perform at least one test upgrade before you make a commitment to how soon you can perform your production upgrade. A well run project should allow the key people involved time to scope out their work before committing to any deadlines. If you do not know the scale of the job, you cannot accurately plan for the production upgrade. As part of the whole project, you should plan to perform a minimum of three successful test upgrades.

During testing you will see software acting inconsistently under apparent laboratory conditions. Some people seem to accept software is a somewhat capricious product that can behave unpredictably and that it's acceptable to see it acting differently from one day to the next so long as it doesn't actually do the wrong thing. This is not how commercial business software is designed or expected to behave. You should be able to find a reason for that inconsistent behaviour. If you cannot, then you have to make a call on how significant you believe that inconsistency is, but be assured, there is a reason for this apparently erratic behaviour. Software - even fiendishly complicated software - does not have a mind of its own.

Use Service Requests (SR) with Oracle Support to validate your upgrade plans and to help you if you encounter any technical issues during your testing. An upgrade where the first we hear from you is when you raise a Severity one SR during the production upgrade is already a failing upgrade. We want to know about any issues you encounter during testing when these can be handled as Severity two and three type SRs where you can work closely with a single engineer, usually in your own time zone, for the duration of the SR.

Be flexible in your testing. Oracle may release a new maintenance pack or updates to patches or the technology stack in the middle of your testing. Consider whether you should now integrate these later releases into your planned upgrade. This will require additional testing but you may not get another downtime window for some time so it's important you upgrade to the latest software whenever possible.


The Production Upgrade

Some DBAs approach a production upgrade with about as much relish as they approach invasive dental work. They know it will be painful, there may be some sleepless nights, and it will cost much more than expected. This is a worrying but increasingly common scenario and it's a real concern to think that some customers feel that the production phase of an upgrade is not only the most stressful part of their project but also the stage most likely to produce an unpredictable outcome.

It would be wrong to dismiss the above concerns as groundless but it's important to realise that with good planning and testing, the production upgrade should not exactly be a formality, but it should certainly be something for which you are fully prepared for every scenario you can think of, and probably a few you have not thought of.

If you approach your production upgrade with dread, unsure of what might go wrong, and wondering if it will succeed then this is almost certainly due to a lack of effective preparation and testing. You may feel under pressure to deliver a system but this is nothing compared to the pressure you will feel if you deliver nothing at all. If you really go into your production upgrade being unsure of its success then you should not be contemplating performing it. Production downtime is not something you will be offered regularly and it should not be lost on speculative or poorly tested work.

The Apollo astronauts on their way to the Moon, had a "go/no go" decision at each critical point in their mission. Your production upgrade should run on similar lines. At each significant stage in the production upgrade you should decide whether you are on course to reach your objective. You should not be afraid to abandon a production upgrade which has gone wrong and instead focus on returning the old system to your users as quickly as possible. This should be the worst scenario you can contemplate but your project plan should include a contingency for it. Your users may not thank you for this but having the old system available on Monday morning is always more acceptable than having no system at all to offer them. You can always come back to fight another day. At no time should you be in a position that you have nothing to offer your users but a broken, part-upgraded environment.

Your production upgrade is not the place where you should be trying any of the following:-

  • Fixing errors that you have not seen during testing
  • Trying out a different upgrade path that you did not think of during testing
  • Applying patches that you did not require during testing

The common message in the above is that you should not be trying anything in your production upgrade that you have not done during testing. This should be pretty much a golden rule of your production upgrade. One day you may have to break that rule but that day will be an exceptional one.

Using standby database functionality from Data Guard is very useful when upgrading. You can configure up to nine standby databases off your production database. If, for example, you have a standby database, you can decouple this at the start of the upgrade. This is then immediately available as a pre-upgrade backup should your production upgrade fail. If the production upgrade succeeds then you just bring this standby database back online after the upgrade and it will automatically resynchronise with the new production database through Data Guard. This may be a little more complicated if your upgrade includes a database upgrade but standby databases can still have an important part to play in any maintenance exercise.

It's important to approach a production upgrade with a positive mental attitude. A belief that what you are going to do will succeed means you will approach any problems with a belief that you can solve them. If you expect your upgrade to fail then problems come like body blows and you struggle to pick yourself up and fight back. You will only have that positive mental attitude if the weeks and months you have spent prior to the production upgrade have been used constructively giving you the confidence you need to make your production upgrade a success.


When Things Go Wrong

Fans of The Hitchhiker's Guide to the Galaxy will know that printed on the cover of this book is the phrase "DON'T PANIC" (always in upper case). This is always good advice in difficult circumstances. A calm head is always best when things don't seem to be going to plan.

Always have a contingency plan.  Expect things to go wrong and congratulate yourself when they don't, but do not assume that the most fastidious of testing will guarantee a success. Having a contingency or backup plan will support you. You'll be reassured that you were smart enough to plan for every eventuality.

Do not expect to rely on others in a crisis.  This is your upgrade and your responsibility. Your colleague at the next desk may be sympathetic to your predicament but that does not mean they do not have their own issues to deal with. Nobody knows your upgrade as intimately as you do. If your production upgrade fails and you need help, consider how much time you may have to spend familiairising a third party with your upgrade and your environment before they can offer constructive help as to how you might overcome your current problem. They may be able to help you but if they cannot, then the onus is back on you to find a solution to your problem. Good preparation before you started your upgrade will be invaluable here.

Do not assume that if a component of the upgrade fails then you can resort to the supplier and they will be responsible for the failure. That may give you a solution in the long term but it may not fix your immediate short term problem. Having a new solution after the event may deflect some of the recriminations as to why the upgrade failed but that will not make the failure go away.


Conclusion

We want your upgrade to succeed.  Oracle Support is available to help during testing and also during your production upgrade. Make sure you use us to ensure everything we offer is available to you throughout your project. Engage your Service Delivery Manager (SDM) and ensure they know about your upgrade. They can make Oracle Support aware of your plans.

The media is full of stories about IT upgrades that have failed. Outside of promotional literature, you rarely read a headline that says "IT Project Goes Exactly to Plan." That does not mean that successes do not exist -- it just means that they do not make the news.

There is rarely much glory in doing your work quietly, efficiently and delivering what is promised, on time and within budget. But if you look around your organisation you will notice that some of the most successful people in the business are the ones who do exactly that. They're not lucky. They planned it that way.


Related Articles

Wednesday Sep 15, 2010

Upgrading From EBS R11i to R12 Using a Staged System

ugstagedsys.jpg
Upgrades are always time-consuming and complex, so anything that makes the task easier and reduces the downtime needed is worth investigating.

A newly-supported technique for upgrading from Oracle E-Business Suite Release 11i to Release 12.1.1 involves use of a staged Applications system, in an extension to the already proven usefulness of this approach to patching within an EBS version.

We've recently expanded the following note to provide full details of the steps needed:
How does this work?

Traditionally, a staged Applications system represents an exact physical copy of a production system,including all APPL_TOPs and the production database. You can apply patches to a staged system while the production system remains in operation. After that, you connect the staged system to the production system, update the database, and synchronise the APPL_TOPs. This means that the downtime for the production system only needs to begin after all patches have been successfully applied to the staged system.

After the patches have been applied to the staged system, and the production system updated, you must export applied patches information from the staged system and import it into the production system. This ensures that the production patch history database is up-to-date.

Now certified for production upgrades from EBS 11i to 12


Having been used unofficially by some upgrade customers for a while, this strategy is now fully supported for use in performing an upgrade from Release 11i to Release 12.1.1. Although your mileage will vary, you should find that using the staged approach is significantly faster than the traditional upgrade route. 

The principles of using the staged approach for upgrading are simple: after meeting the applicable AutoConfig and Rapid Clone patch rerequisites, you create the R11i staged system. You then upgrade the staged system to R12.1.1 by updating the production APPL_TOP and database. Finally, you synchronise the patch histories of the production and staged systems.

Your feedback is welcome

One early adopter found that this shaved 12 hours off their total upgrade time.   We're extremely interested in hearing about your use cases and your experiences with this newly-supported upgrade technique. Please post a comment here or drop us a line with your thoughts.

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:

anne_carlson_email.png


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:
Patch-7303029-screenshot.png

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.
References
Related Articles

Wednesday Sep 23, 2009

Field-Tested Advice for Smooth EBS 11.5.10.2 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:  11.5.10.2. 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 11.5.10.2 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 11.5.10.2, 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 11.5.10.2.

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 8.1.7.4 Database, you will have your work cut out for you.  If you are on 11.5.9 and 9.2.0.8, 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 11.5.10.2 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 11.5.10.2 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 11.5.10.2 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 10.2.0.4 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 11.5.10.2 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 11.5.10.2:
Myth #1:  Shortcuts are safe

There are no safe shortcuts.  This upgrade can't be done by performing a fresh install of 11.5.10.2, linking this installation to your 11.5.x database and then applying the database portion of the 11.5.10.2 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

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 11.1.0.7) 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.

rapidwiz-txk.png

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 10.1.3.4 (Applications tier)
  2. Application Server10g Forms and Reports to 10.1.2.3 (Applications tier)
  3. Database Release 10gR2 to 11gR1 version 11.1.0.7 (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.

rapidwiz-txk.png


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.

rapidwiztxk-DB.png


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

DB11upg.png


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.

rapidwiztxk-AT.png


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

OracleHomes.png


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.

ATUpg.png


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.

ValidationAT.png


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

References
Related Articles

Tuesday Jul 28, 2009

Latest Apps 11i Techstack (ATG RUP 7) Now Available

I'm very pleased to announce that the latest ATG Family Pack H Rollup 7 for the E-Business Suite Release 11i technology stack is now available for download from Metalink.

Screenshot of download page for patch 6241631

The official name for this patch is:

In other words, this is the seventh consolidated rollup of patches released on top of 11i.ATG_PF.H. For the Oracryptoanalysts out there who like to track nomenclature variants of these things, this patch is also referred to as the Applications Technology Group (ATG) Family Pack H Rollup 7.

This Rollup patch is a collection of technology-stack patches that can safely be applied on top of the ATG Family Pack H. This Rollup patch is cumulative: all previous patches released for Family Pack H since the initial 11.5.10 release are included in this latest patch, including:

Why Is This Rollup Important?

As with the previous ATG Rollup 6, we've spent a huge amount of effort both within the Applications Technology Group and across the entire Applications Suite to test and certify this Rollup patch.

Our focus for this latest Rollup has been to consolidate all known safe defect fixes, performance improvements and security enhancements into one well integrated and fully certified update. We also focused on eliminating as many "co-requisite" patches as possible (application product patches required to interoperate with new ATG Rollups), by working to restore backward compatibility with earlier application levels wherever possible.

Our standing recommendation is that all customers should make plans to move to Rollup 7 as quickly as possible, especially any customers who are not already at ATG Rollup 6.

Changes and Fixes in Rollup 7

Oracle Applications Technology 11i.ATG_PF.H.delta.7 (RUP7) contains Oracle Applications Technology (ATG) security fixes for core ATG products from the January 2005 Critical Patch Update (CPUJan2005) through the July 2009  Critical Patch Update (CPUJul2009).

The following core ATG products are included in 11i.ATG_PF.H.delta.7: FND, OAM, OWF, FWK, JTT, JTA, TXK, XDO, ECX, EC, AK, ALR, UMX, BNE, and FRM.

ATG Family Pack H Rollup 7 (11i.ATG_PF.H RUP 7, Patch 6241631) includes a range of new features and bug fixes for:

Full details about what's new in RUP7 are listed here:

Prerequisites

Oracle Applications Technology ATG_PF.H RUP7 can be applied only to an existing Oracle Applications Release 11.5.10.2 system.  If you don't already have a running Release 11.5.10.2 (11.5.10 CU2) system, then you must first install the Oracle E-Business Suite 11.5.10.2.

Special Advisory for Single Sign-On 10g Users

The SSO 10g Integration patch for Rollup 7 (Patch 6936696) has been released concurrently with this patch. It is available immediately for download. Details about upgrading your SSO-integrated environment to use this patch can be found in the latest version of Note 233436.1.

Supporting the Current and Previous ATG RUPs

Way back in 2006, in this blog's salad days, I posted this article:

Remember that our support baseline for the E-Business Suite is comprised of the current (N) and immediately preceding (N-1) ATG RUPs.  New EBS patches are tested and released on top of these two technology stack baseline configurations. 

What Does This Have to do with ATG RUP 7?

Apps 11i ATG RUP 7 is supported along with ATG RUP 6.  In other words, if you encounter any issues with ATG RUP 6 or 7, we'll be able to release new E-Business Suite patches for those configurations as necessary.

If your Apps 11i environment is still running ATG RUP 5 or older, you will no longer be able to request new patches for those technology stack levels.  You can still get access to existing patches, of course.

A Short Aside About Related Support Policies

This is similar but not identical to the support policy for our Server Technologies and Fusion Middleware products, which I've discussed in more detail in these important articles:

Remember that our Server Technologies and Fusion Middleware support policies are subtly different and from EBS policies:  they support the current (N), as well as the immediately preceding (N-1) release for 12 months after the N release.

Related Articles

Tuesday Jun 09, 2009

Updating the Default JDK Installed in OracleAS 10g

[June 12, 2009 Update: Added link to JDK 1.6 Note 444462.1]

Java logo

If you run Java-based applications in your organization, you're aware that you may wish to optionally update the Java Development Kit (JDK) libraries periodically to get the latest fixes for security, stability, and performance.  This applies to the E-Business Suite, naturally, so we regularly release new certifications for the latest Java releases for EBS.

Perhaps lesser-known is that this also applies to external servers running Oracle Fusion Middleware -- also known as Oracle Application Server 10g.  You may have deployed Oracle Application Server 10g on one or more application tier servers to use Discoverer, Single Sign-On, Oracle Internet Directory, Portal, or other Fusion Middleware services with the E-Business Suite.

How Do You Update Java for other Oracle Products?

Oracle Security has published the following advisory:

That note is important reading for all Oracle administrators.  It contains links to three additional documents:

If you're looking for the latest JDK 1.4 release to update an Oracle Application Server 10g instance, you can find it here:

Special thanks to those readers (you know who you are) whose persistence helped us make this JDK patch available for all of our customers.

Related Articles

Monday Nov 10, 2008

Apps Technology 12.0.6 Update Now Available

In conjunction with last week's release of the Applications 12.0.6 Release Update Pack, the sixth major update for the Apps Release 12 technology stack is now available for download from Metalink:

Screenshot of download page for ATG R12 RUP 6 Patch%207237006.png

[Read More]

Tuesday Jul 15, 2008

Case Study: Oracle's Own Oracle E-Business Suite Release 12 Upgrade

[Oct. 27, 2008 Update:  The latest version of this popular presentation from OpenWorld 2008 is now available for download.  For links to the latest version, see this article.]

I've heard anecdotal reports suggesting that some customers hold off on upgrading to a given E-Business Suite release until we've done so ourselves here at Oracle. Oracle went live on R12.0.3 in January 2008, and a reader reminded me that I haven't highlighted this adequately. Here's a critical presentation from Eugene Weinstein and Sharon Leong at OAUG Collaborate 2008 (Denver) that I've been remiss in profiling:

Eugene and Sharon cover a lot of ground in this technically-oriented presentation, including:

  • A primer on the R12 file system
  • Supported upgrade paths from earlier Apps releases (11.5.x, 11.0)
  • A detailed step-by-step flowchart of the upgrade process
  • Applications DBA (AD) improvements relating to the upgrade process
  • Performance improvements relating to the upgrade
  • Best practices for:
  • Reducing downtime
  • Performing pre-upgrade, upgrade, and post-upgrade steps
[Read More]

Thursday Jun 12, 2008

New Whitepaper: Best Practices for Adopting E-Business Suite Release 12 (First Edition)

A colleague has just pulled off an impressive feat that I wouldn't have attempted myself:  she's collected practical tips and advice on how to do Oracle E-Business Suite Release 12 implementations and upgrades.  She's consolidated input from Oracle's Support, Consulting, IT, and Development groups into a new whitepaper:

This whitepaper is mandatory reading if you're planning -- or in the middle of -- an Oracle E-Business Suite Release 12 deployment.  The whitepaper has a mix of concrete and strategic advice that covers topics such as:

[Read More]

Friday Jun 06, 2008

OLAP + Data Mining Prerequisites for Apps + 10.2.0.3 DB Upgrades

There are a variety of reasons to upgrade your E-Business Suite Release 11i environment to the 10.2.0.3 database.  You might be upgrading because Premier Support for the 9iR2 database ended in July 2007.  You might be upgrading in preparation for your move to E-Business Suite Release 12.

Regardless of your motivation for doing so, you will have noticed that this upgrade requires two database options:  Oracle Data Mining and OLAP.  These prerequisites are required even if you do not use any Applications products that depend on these options.  Some questions have been raised about whether these prerequisites trigger additional licencing fees for customers in that situation.

Don't Worry, Be Happy

We've just clarified our documentation to reassure you that restricted use licences for these products are included with the Oracle Database Enterprise Edition for the purposes of upgrading an E-Business Suite database.  In other words, if you don't already have OLAP or Oracle Data Mining installed, you don't have to purchase additional licences for these database options just to perform an upgrade.

We've just published clarifications about these restricted use licences in the following documents:

Related Articles

Saturday May 17, 2008

Release Update Packs 12.0.5 for Financials and HRMS Now Available

[July 2, 2008 Update: Removed references to specific numbers of issues fixed.]

This announcement isn't really directly-related to the E-Business Suite technology stack, but it can't hurt to highlight this news here since it affects so many of our readers.   Oracle Financials and Oracle Human Resources Management System (HRMS) have released two new product family Release Update Packs for E-Business Release 12.0.5.  These cumulative product family RUPs include error corrections, statutory/regulatory updates, and functionality enhancements that were made available after the initial release of Oracle E-Business Suites 12.0.

The naming convention for E-Business Suite Release 12 until now has been that a "Release Update Pack" comprises bug fixes for all product families.  These were called Consolidated Updates in Release 11i. 

This is the first time I've seen the term "Release Update Pack" used to refer to fixes for a specific product family for Release 12.  You should be aware that these latest 12.0.5 RUPs don't include fixes for any other E-Business Suite application modules except Financials or HRMS.  Regardless of what they're called, R12 sysadmins can now download two new patchsets:


Oracle Financials Release Update Pack 12.0.5

This patch can be downloaded as Patch 6836355, and its contents are documented in Oracle Financials Software Updates, Release Update Pack 6 (Metalink Note 565898.1).

Oracle HRMS Release Update Pack 12.0.5

This patch can be downloaded as Patch 6610000, and its contents are documented in Oracle HRMS Software Updates, Release Update Pack 5 (Metalink Note 565977.1).


References

New functionality for both RUPs is described in:
Related Articles

Monday Apr 28, 2008

Five Key Resources for Upgrading to E-Business Suite Release 12

[July 16, 2008: Added two more vital resources to this list, instantly rendering the title of this article inaccurate.]

[May 14, 2008 Update:  It turns out that the original diagram from Eugene's presentation could use some refining.  Diagram replaced with an excerpt from the Official R12 upgrade guide itself.]

[Apr 29, 2008 Update:  The diagram below is excerpted from Eugene Weinstein's excellent OpenWorld 2007 presentation describing Oracle's own R12 upgrade.  That presentation was released prior to our recent certification of the 11g Database with Release 11i, which is why there's no reference to that database version below.  


As of today,  the 11g Database is certified with Release 11i but not with Release 12.  The R12 certification with the 11g Database is still underway now, and -- as usual, I don't have any dates for this certification yet.  If you upgrade your Apps 11i environment to the 11g DB today, your upgrade to Release 12 will have to wait until the latter is certified with the 11g DB, too.]

A remarkable aspect of this year's OAUG Collaborate 2008 conference was the abundance of customer-presented sessions devoted to E-Business Suite Release 12 upgrades.  I stopped counting after the first dozen sessions.  I wish I could have cloned myself to attend all of them.

Upgrade Paths Table: Table of Release 12 upgrade paths from E-business Suite 11.0, 11.5.1 to 11.5.7, and 11.5.8 to 11.5.10

Despite the plethora of customer case studies and other materials, I got the impression that some of you may be wondering where to start.  Here's a round-up of the key Oracle resources to help you plan and execute your Release 12 upgrade:
  1. Whitepapers about R12 functional benefits
    As a reader of this blog, your focus is likely on E-Business Suite technology more than on the applications modules' functionality itself.  Remember, however, that upgrading to Release 12 should be primarily driven by the improvements to business processes that R12's new capabilities offer.  The site above has whitepapers that your end-users can review to build their own business cases for the upgrade (e.g. "The Business Value of Upgrading to Oracle E-Business Suite Financials Release 12").
  2. Oracle Applications Upgrade Guide: Release 11i to Release 12 (PDF, 1.6 MB)
    This is the official, authoritative technical upgrade manual from Oracle Applications Development. This is part of the official Release 12 Documentation Library (Oracle Technology Network).
  3. Oracle Maintenance Wizard
    Oracle Support has worked jointly with Oracle Applications Development to produce this essential tool which produces a personalized 11i to R12 upgrade plan -- complete with detailed patching recommendations -- based upon your existing 11i environment.  Highly recommended.

  4. Oracle E-Business Suite Upgrade Resources Roadmap (Note 461705.1)
    Oracle provides a massive (and sometimes intimidating) amount of documentation to support your R12 upgrade.  This roadmap helps organize that documentation into four phases:  Evaluation, Planning, Execution, and Optimization.  This is the one-stop Metalink Note for links to Release Notes, READMEs, Release Content Documents, Upgrade Notes for specific platforms, and much, much more.

  5. R12 Install/Upgrade Forum (Oracle Technology Network)
    Amazingly, this OTN peer-supported discussion forum can sometimes yield answers to R12 upgrade questions faster than a formally-logged Service Request. This forum is monitored by Oracle Applications ACEs such as Hussein Sawwan, Michael Taylor, and Fadi Hasweh as well as Oracle Development (I'm one of the Oracle co-moderators of this forum).  This should be your first stop if you're having any technical issues with your upgrade.  If your question isn't answered here, then logging an SR with Metalink is the next step.

  6. Best Practices for Adopting Oracle E-Business Suite Release 12 (Metalink Note 580299.1)
    This whitepaper from Oracle Development pulls together a diverse range of tips and practical suggestions for implementation, preparation and cleanup, and product-specific considerations for the R12 versions of Oracle Financials and other products. Highly recommended.

  7. Case Study: Oracle's Own Oracle E-Business Suite Release 12 Upgrade
    In addition to being a useful primer about R12, this excellent presentation summarizes practical tips and technical insights from the Oracle internal team that upgraded Oracle's own E-Business Suite Global Single Instance from Release 11i to 12. As you'd expect, and their notes represent an insider's glimpse into how an organization with access to the most-skilled EBS talent on the planet performed this upgrade. Highly recommended.
Related Articles

Wednesday Apr 23, 2008

Preparing for Apps 11i AutoConfig Updates

E-Business Suite Release 11i uses the Oracle9i Application Server 1.0.2.2.2-based components in its Applications tier. This includes an 8.0.6 ORACLE_HOME for the Developer 6i Forms and Reports run-time and an 8.1.7 ORACLE_HOME for the Apache and JServ-based run-time components. AutoConfig and its associated templates provide the configuration data for these ORACLE_HOMEs.

The latest version of AutoConfig is always included with the latest ATG Technology Stack rollup patches.  It's also possible to update the AutoConfig Engine and its associated templates separately if certain prerequisites are met.  You can download the latest version of AutoConfig via the TXK Rollup for Oracle E-Business Suite Release 11i:

In preparation for your AutoConfig upgrade, you can run the Technology Stack Rollup Validation Utility to get a report of the current component versions on your Release 11i Applications tier. The report also advises on the components on each tier that need to be upgraded before upgrading AutoConfig itself.

TXKRUPR:

Running the Technology Stack Rollup Validation Utility

The Technology Stack Rollup Validation Utility is a perl script that is run using the perl infrastructure delivered in the APPL_TOP by the TXK team.

Where to run

  • In a single-node install, run the utility on the Applications Tier Node.
  • In a multi-node install, run the utility on every Web/Forms, Admin/CP Node
  • The latest version of the Validation Utility is shipped with the TXK Rollup. Hence the script needs to be run from the location where the patch is unzipped.

Steps to run

  1. Source the Applications environment file as the owner of the application tier file system
  2. From the location where TXK Rollup patch was unzipped, change directory to fnd/patch/115/bin
  3. Run the Validation script as described in the table below
Unix
./txkprepatchcheck.pl -script=ValidateRollup -outfile=$APPLTMP/txkValidateRollup.html 
-appspass=<apps database password>
Windows
%ADPERLPRG% txkprepatchcheck.pl -script=ValidateRollup

-outfile=%APPLTMP%txkValidateRollup.html

-appspass=<apps database password>

Note: The arguments for the perl script txkprepatchcheck.pl can be entered manually at the prompt also.

Interpreting the Report

The report generated in the location specified by the outfile argument contains:
  1. Overall PASS/FAIL status of the Utility.
  2. Report header table with information about the host, node type and configuration file, versions.
  3. Validation table for each of the HTTP Server, Forms Server, Concurrent Processing Server, and Administration Server Node types.
  4. For each of the node types, the dependent and relevant Technology Component is displayed with its version number and PASS/FAIL status.
Sample Reports

Report Header

TXKHeader1:

TXKHeader2:

Validation for HTTP Server Node

TXKHTTPServer:

Validation for Other Nodes

TXKOtherNodes:

Before Applying the TXP RUP

The AutoConfig upgrade, as delivered by TXK Rollup patches, can be be applied only when the report displays PASS for all entries in each table and an ALLPASS at the top. All WARNING/FAIL rows should be corrected with respective actions recommended in the report row before applying the patch.

References
  1. Using AutoConfig to Manage System Configurations withOracle Applications 11i (OracleMetalink Note 165195.1).
  2. Frequently Asked Questions About Using AutoConfig With Oracle Applications Release 11i (OracleMetalink Note 218089.1)
Related Articles

Monday Apr 21, 2008

What Happened to E-Business Suite Release 12.0.5?

[May 29, 2008 update:  They don't meet the definition of a Release Update Pack that's been used for R12 so far, but two 12.0.5 product family updates for the Financials and HRMS product families are now available.  See this article for details.]


Up until now, a new E-Business Suite Release 12.0.x Release Update Pack (RUP) has been released in the same general time-frame as each new Oracle Critical Patch Update (CPU).  For example, the January 2008 Critical Patch Update was released concurrently with the E-Business Suite 12.0.4 Release Update Pack.

E-Business Suite 12.0.4 Patch 6435000: Screenshot of download site for E-Business Suite Release 12.0.4 Release Update Pack Patch 6435000

This pattern changed with the recent Oracle Critical Patch Update for April 2008.  The April 2008 CPU was not released concurrently with a corresponding E-Business Suite Release 12.0.5 Release Update Pack.  Sharp-eyed readers have asked whether an upcoming Release 12.0.5 is still in the pipeline.

Here's an update on our plans, based on what was being shared in various sessions at last week's Collaborate conference (notably, Cliff Godwin's sessions):  As of today, it appears that there are no plans for Release 12.0.5.  Instead, it appears that new Family Packs for Financials and Human Resources (HRMS) are planned for customers currently on the 12.0.x codeline.

It's important to note that this is breaking news and is still subject to change.  As usual, I'm afraid that I don't have any information about dates for these updates.  I'll provide more details about our plans for these forthcoming updates as soon as they're available.

Related Articles
The above is intended to outline our general product direction.  It is intended for information purposes only, and may not be incorporated into any contract.   It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions.  The development, release, and timing of any features or functionality described for Oracle's products remains at the sole discretion of Oracle. 

Thursday Apr 10, 2008

Apps Management Pack 2.0 Available for HP-UX

The latest Applications Management Pack version 2.0 was initially released for a selected set of operating system platforms.  This eagerly awaited upgrade to our popular Oracle Enterprise Manager Grid Control 10gR3 plug-in is now also available for two new platforms:  HP-UX PA RISC and HP-UX Itanium.  This update is available for download via Patch 5489352 from Oracle Metalink.

Enterprise Manager Screenshot:

As of today, this version of the Application Management Pack is now available for the following platforms:
  • Linux x86
  • Linux x86-64
  • Sun Solaris
  • IBM AIX
  • HP-UX PA-RISC
  • HP-UX Itanium
For more details about what's new in this release, see:

Wednesday Apr 02, 2008

Apps Release 12.0.4 Rapid Install Now Available

Climbing back into the blogging saddle after a five weeks abroad feels distinctly odd.  Here's something noteworthy from my beleaguered inbox:

12.0.4 eDelivery screenshot: Screenshot of Oracle Electronic Delivery download page for Apps 12.0.4 Rapid Install

Ever since the initial release of E-Business Suite Release 12.0, we've been putting out quarterly Release Update Packs (RUP) that you can apply on top of your base installation.  So far, we've released Release Update Packs 12.0.1, 12.0.2, 12.0.3, and 12.0.4.  The latest Release Update Pack 4 included more than 10,000 fixes and 100 functionality enhancements after the initial release of 12.0.

Although convenient, applying all of these individual Release Update Packs can be time-consuming.  Recognising that, we've now released a new version of E-Business Suite 12.0.4.  This brand-new release includes a repackaged Rapid Install that makes it possible to upgrade existing 11.5.8, 11.5.9 (Base, CU1, CU2), and 11.5.10 (base, CU1, CU2) systems directly to the Release Update Pack 4 level. 

Release 12.0.4 is now available for download for both new and upgrading customers on all supported languages through Oracle Electronic Product Delivery (EPD) and the Oracle Store.  You can check EPD for specific platform downloads, which are updated regularly.

What's New in Release Update Pack 4?

As noted in my previous article about Release 12 Update 4, this RUP contains fixes for the following product families, with details in the
corresponding Metalink Notes:
Includes January 2008 Critical Patch Updates

Just like the previous Apps 12.0.1 Release Update Pack, Apps 12.0.2 Release Update Pack, and Apps 12.0.3 Release Update Pack, there's a gem buried in all of this:  the Apps 12.0.4 Release Update Patch includes all of the security fixes released in the January 2008 Critical Update Patch (CPUJan2008).

Related

Thursday Feb 21, 2008

Latest Apps Management Pack 2.0.1 Now Available

Our hardworking E-Business Suite Applications Technology Group recently released  Application Management Pack version 2.0.1 for Oracle E-Business Suite.  This upgrade includes some important new features and a large number of bug fixes.  This update  is available for download via Patch 5969524 from Oracle Metalink.

Enterprise Manager Screenshot:

Supported E-Business Suite Releases

Application Management Pack (AMP) 2.0.1 is available for Grid Control 10gR3 on Linux (x86) and can be used to manage the following E-Business Suite releases:
  • Release 11.5.10 CU2 + ATG FP RUP4.H
  • Release 12.0
What Else Is New?


AMP 2.0.1 is an OPatch rollup update on top of the Pack's earlier release V2.0.  Some of the key benefits of this upgrade are:

  • Improved discovery and cloning capabilities
  • Management of E-Business Suite advanced topologies
  • Option to discover and register E-Business Suite instances either through the Command line or EM Grid Control User Interface
This pack also contains major bug fixes in the following areas:

Cloning
  • 6141071: Ability for user to choose custom directories for installing APPL_TOP and DB TOP while cloning EBS R12.
  • 5976900: Ability for users to perform scale up or scale down clone of DB TOP.
  • 6155177: Ability for clone to support the capability to skip optional steps specified in the Clone Procedure.
  • 5876590: Support cloning of Individual EBS components (Database Techstack, Data Top, Application Techstack, and Application Top).
  • 5892625: Ability to apply an EBS image on an existing E-Business Suite Target.
Discovery
  • Command Line Interface (CLI) for discovering and registering E-Business Suite system. In addition to the EM Grid Control User Interface based EBS discovery process, customers can now choose to discover using CLI. However the discovery mechanism still remains the same in both the steps.
Certified Oracle E-Business Suite Topology
  • EBS deployed on shared file system (NFS): Customers can now use AMP 2.0.1 to monitor and manage Oracle E-Business Suite systems deployed on a shared file system. However the cloning capability is still pending certification.
  • SSL enabled EBS System: Using AMP 2.0.1 customers can monitor and manage Oracle E-Business Suite systems that are SSL enabled.
References
Related Articles

[Completely unrelated aside: This is likely going to be the last major piece of news on this blog for a while.  I'm off to visit my teams in India and the UK for an extended trip.  It's unlikely that I'll have a lot of free time to post techstack news during my travels, but we'll see how things go.]

Monday Feb 04, 2008

RapidClone Updates Available for Apps 11i and 12

Our ever-handy RapidClone utility allows you to create a standalone copy of an existing Oracle Applications system. There are many scenarios where it's useful to clone an Applications environment, including:

  • Standard cloning - Making a copy of an existing Oracle Applications system, for example a copy of a production system to test updates.
  • System scale-up - Adding new machines to a system to provide the capacity for processing an increased workload.
  • System transformations - Altering system data or file systems, including actions such as platform migration, data scrambling, and provisioning of high availability architectures.
  • Patching and upgrading - Delivering new versions of Applications components, and providing a mechanism for creating rolling environments to minimize downtime.
Latest RapidClone Consolidated Fixes Available for Download

The latest updates to both the Release 11i and 12 versions of RapidClone are now available in the following downloads:
The January 2008 updates fix 36 cloning-related issues for Release 11i and 57 cloning-related issues for Release 12; see the respective READMEs for the list of bugs fixed.

Documentation
Related Articles
About

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
4
5
6
7
8
9
10
11
12
13
14
19
20
21
23
24
25
26
27
28
29
30
   
       
Today