Site hosted by Angelfire.com: Build your free website today!

R11i Upgrades – A Toolkit Approach

 

Mike Bromfield

Myriad Business Consulting

mbromfield@myriad-business.com

Darren Ryan & Dominic Hicks, UPGRADExtra

 

Upgrading to Oracle Applications Release 11i can be a costly and time-consuming process, especially if you’ve customised your current release. A way to minimize costs and time spent upgrading is to implement a toolkit approach that is devised to identify, access, and control key information for the R11i upgrade process.

 

The toolkit, which was used during one of the United Kingdom’s first Oracle Applications R11i major upgrade projects, provides a mechanism to scope and support the Oracle Applications upgrade process by centralising specific essential upgrade information and allowing it to be accessed via web-enabled software. Additional links to documentation and desktop applications provide an integrated, innovative, technical, and functional solution to the upgrade process. The toolkit helps to ‘”‘de-mystify’”’ the upgrade process and complements Oracle’s structured upgrade process and utilities.

 

Before beginning the upgrade process, ask the following questions:

 

A fundamental requirement of the upgrade process is to complete preliminary and cut-over activities within a specified time frame that is acceptable to the business. Because it is important to document all requirements relevant to your site, a structured and centralised documentation subsystem, which acts as the hub for all upgrade processes, is required. 

 

Oracle’s Structured Upgrade Process

Oracle provides a structured upgrade process, broken down into two phases: pre-upgrade and post-upgrade. Within these phases, upgrade tasks are grouped into categories that contain a combination of technical and functional activities. The technical activities are predominately conducted by DBAs while application specific requirements are split between those who have an understanding of the technical requirements and those who have an understanding of the business processes and application functional requirements.

 

Before You Receive the Software

This category concentrates on preparing your Oracle Applications well before the upgrade. It requires nothing from the new software, and it allows you to continue to use your current Oracle Applications environment. It is during this phase that you should document your customisations. Irrespective of the amount of customisations at your site, identify and record every single custom object.

 

After You Receive the Software

This category also concentrates on preparing your Oracle Applications before the upgrade. It differs from Category 1 steps in that it requires the running of scripts that come as part of the upgrade bundle. These scripts validate the existing environment and identify application data and setup.

 

In many cases, the application data and setup can be corrected in the existing system without affecting the day-to-day running of the current applications. This must be thoroughly tested, but once fixed, should no longer impact the upgrade process.

 

Performing the Upgrade

This category concentrates on preparing your Oracle Applications for the upgrade to Release 11i immediately prior to the actual upgrade itself. In preparation for the upgrade, you should process as many outstanding transactions as possible. It is also advisable to complete any process cycles and interfaces – and if possible, close accounting periods. The system is required to be down for this stage in the upgrade process. The Autoupgrade itself upgrades your applications from 10.7 to 11.5.0 and consists of approximately 16,000 scripts. You can then Patch the 11.5.0 instance to the accepted version level.

 

Before Using Oracle Applications

This category concentrates on activities that occur immediately after the completion of Autoupgrade and before you use any of the application products. This category affects the entire applications system and must be performed when all users are logged off the system as with Category 3.

 

You are also required to re-enable all of the triggers, constraints, and indexes that have been removed as part of the upgrade. In addition, you must copy the customisations into the new environment. Your pre-upgrade analysis will identify all the objects that should be reinstated.

 

Before Using the Products

This category relates to the finishing steps that should be completed prior to using the applications. Generally, an application specialist is required to assist with the completion of these activities. A number of these tasks rely on the successful completion of the Category 3 steps. These activities complete the upgrade of each of the products.

 

Before Using Product Features

Complete these activities prior to using the new features associated with the application products. An understanding of the new application features is essential in order to assess the impact of any changes to the existing processes. A number of new features will become a standard part of the upgraded application, while other features can be optionally implemented depending on each sites specific requirements.

 

Finishing the Upgrade

These tasks are performed to finish the upgrade and are conducted by the DBAs. These technical tasks incorporate database and server maintenance routines, loading of the online help, and configuring the client software.

 

Minimising Customisation Re-development

If you have customised your Oracle Applications in order to meet your business requirements, then you are faced with the onerous task of re-developing those that have not been replaced with new functionality. You need to be able to assess what the customisations are, how they have been affected, and how long it takes to redevelop them.

 

In order to fully scope the risk, you must know about every custom object introduced at your site. This includes database objects, AOL objects and reports, forms, and programs. The new release can affect any or all of these objects.

 

There have been significant changes to the underlying Application Schemas, with many of the 10.7/11.0 tables and views being changed in order to meet the new 11i requirements. Gauge the impact of these changes against all your custom objects. Changes in the 11i functionality may mean that existing customisations work correctly using historical data, but may not process correctly with new transactions. The database engine now uses the Cost Based Optimiser, which can have significant performance impact upon your customisations.

 

Use the Toolkit approach to address customizations and  identify and load all necessary site-specific information into the central repository. Use this information to perform a full impact analysis. This is a critical factor in successfully speeding up re-development time, as you can use this source of information to drive the development effort. This approach significantly reduces the cost of re-development by focusing expensive development resources only to areas where it is required.

 

In summary, you need to identify:

 

Using this approach enables you to easily identify which custom objects are highly impacted. It also enables you to more accurately estimate total re-development time scales and resource requirements.

 

A standard documentation template is attached to every entry in the Toolkit. Developers use these templates to record analysis, tips, tricks, and solutions identified during the re-development phase.

 

A number of affected tables and views require substantial analysis and complex coding to re-develop the customisation. The Toolkit enables you to identify all other custom objects with the same problematic table or view. The developer who initially identified the solution can repeat the process on all affected custom objects.

 

By centralising all information, you are able to maximize the efforts of all of the re-developers; and by sharing solutions and focusing efforts, you can halve the total re-development time – resulting in substantial time and cost savings.

 

Functional Assessment

A fundamental part of the upgrade process is to gain an understanding of the impact on existing business processes. A functional assessment generally incorporates the following elements:

 

Existing Business Processes

It is important to establish a baseline to start the impact analysis. An understanding of the existing business processes provides this basis from which you can link associated new features and customisations. Using this helps define the training, testing, setup, and documentation requirements.

 

New Product Features

An understanding of the new product features is essential to reviewing the business impact. New product features generally fall into three broad headings:

·        Features which are an essential part of the upgraded application functionality and must be incorporated into the existing business processes.

·         Features which provide an immediate benefit and have a minimal impact on the users as far as training and existing process.

·        New features which require significant analysis and implementation solution to address the setup, testing, and training requirements. You can plan a number of these features after the initial upgrade is complete and stabilised.

 

Links to Customisations

Using customisation information extracted from technical activities, customisations can be linked to each process. This assists in confirming whether the customisation is still relevant or redundant as a result of changes in the upgraded functionality. This information assists in defining the testing, training, and application setup requirements.

 

Testing Requirements

The testing phase is a crucial element of any upgrade process. It is essential that testing requirements are identified and understood. A testing plan needs to incorporate the requirements for each business process. Using standard documentation templates linked to the business process provides a mechanism to outline requirements, identify assumptions, confirm decisions, and record results.

 

Documentation Recording

During the functional analysis and testing phase, additional analysis involves referencing various application manuals and Oracle Metalink. Make sure to include cross-references to these sources within the centralised documentation, as the application environment constantly changes.

 

Structured Upgrade Process

The structured upgrade process provides an initial checklist for the required upgrade activities. During the upgrade process, you should expand this list to incorporate your site-specific requirements. Additional steps may be incorporated as a result of introducing application patches, developing additional data correction scripts, or adding application setup changes including parameters, menus, responsibilities, and profile options.

 

The upgrade process is supported by a vast array of functional and technical documentation. Document links to key information, and wherever possible, incorporate timings to indicate the actual duration of conducting the upgrade tasks and estimates for time required to further investigate impacts.

 

The critical success factor for the upgrade is to create a repetitive process. In order to achieve a repetitive upgrade process in an ever-changing environment, centralise the documentation for all upgrade activities. The central database repository acts as a hub, which allows you to record specific activities, identify anomalies, and highlight issues. This assists in reducing risks associated with the upgrade process. A structured and centralised approach is the major factor in reducing the down-time during that all-important upgrade window. The Toolkit provides the mechanism to capture and retrieve this information in standard documentation templates. It is important to be able to track the status of all upgrade activities, highlighting any that are an issue.

 

The upgrade process requires significant input by the technical resources. It requires a number of DBAs who are experienced in upgrading Oracle Applications. The DBAs must be able to understand and organise the multitude of tasks that make up the upgrade process.

 

Your Application Developers should have a thorough working knowledge of the schemas that are being upgraded. They must know reports and Forms 6 and be capable of making the necessary changes to your customised code in order to accommodate the new schema. The new database is cost based optimised (Rule Based in 10.7), so performance tuning of customised code is required.

 

A structured approach supported by an easily maintainable documentation system helps assist the functional impact analysis. Involve key users in the upgrade process well before the testing phase in order to assist with the impact analysis. The Toolkit provides an online repository to record these functional processes. The central repository provides essential documentation and references that you will use repeatedly to reduce analysis activity. They also act as an important source of information as the upgrade moves into the production phase.

 

The finalised version of the R11i Toolkit allows the identification, access, and control of key information during the R11i Upgrade process. It provides the following:

 

 

Recommendations

We recommend the following for your R11i Upgrade Process:-