ConfigSnapshot Guide - Upgrades

2e2 UK Ltd: The Mansion House, Benham Valence, Speen, Newbury, Berks, RG20 8LU. Registered in England Number 4090390.

ConfigSnapshot Guide Upgrades

Author: 2e2 Business Applications Version: Draft Date: Aug-2010

ConfigSnapshot Guide - Upgrades 0.2.doc -i-

Contents

1 INTRODUCTION ...................................................................................................... 1

2 UPGRADE PROCESS OVERVIEW ......................................................................... 1

2.1 Upgrade Definition ........................................................................................... 1

2.2 Rollup Patches ................................................................................................. 1

2.3 Upgrade Phases .............................................................................................. 1

3 UPGRADE PREPARATION..................................................................................... 3

3.1 Creating the Environment ................................................................................. 3

3.2 Upgrade Assessment ....................................................................................... 3

3.2.1 Overview .............................................................................................................. 3

3.2.2 Analysing Existing Setup ..................................................................................... 4

3.2.3 Determining Setup at Risk ................................................................................... 5

3.2.4 Identifying Customisations ................................................................................... 7

4 TEST UPGRADE ITERATIONS ............................................................................... 9

4.1 Test Upgrade ................................................................................................... 9

4.2 Upgrade Effects ............................................................................................. 10

4.2.1 Overview ............................................................................................................ 10

4.2.2 Effect on Application Setups .............................................................................. 11

4.2.3 Effect on Application Functionality ..................................................................... 12

4.3 Maintaining Customisations............................................................................ 15

4.3.1 Existing Customisations ..................................................................................... 15

4.3.2 New Customisations .......................................................................................... 17

4.4 Configuration Changes ................................................................................... 17

4.5 Implementing New Features ........................................................................... 17

4.6 Systems Test ................................................................................................. 17

4.6.1 Standard Functionality ....................................................................................... 17

4.6.2 Customisations................................................................................................... 18

4.6.3 Post-System Test Baseline ................................................................................ 18

4.7 Confirmation of Upgrade Iteration .................................................................. 18

5 USER ACCEPTANCE TESTING ........................................................................... 18

6 DRESS REHEARSAL UPGRADE ......................................................................... 19

7 PRODUCTION UPGRADE..................................................................................... 19

8 APPENDIX 1: DETERMINING SETUP AT RISK ................................................... 20

9 APPENDIX 2: CUSTOMISATION AREAS ............................................................. 21

9.1 Overview ........................................................................................................ 21

9.2 System Administration .................................................................................... 21

9.2.1 Concurrent Programs ......................................................................................... 21

9.2.2 Concurrent Program Parameters ....................................................................... 21

9.2.3 Table Validated Value Sets ................................................................................ 22

9.2.4 Printer Styles ...................................................................................................... 23

9.2.5 Printer Drivers .................................................................................................... 23

9.3 Application Developer .................................................................................... 23

9.3.1 Forms ................................................................................................................. 23

ConfigSnapshot Guide - Upgrades 0.2.doc -ii-

9.3.2 Form Functions .................................................................................................. 24

9.3.3 Tables ................................................................................................................ 24

9.3.4 Views .................................................................................................................. 24

9.3.5 Attachment Functions ........................................................................................ 25

9.3.6 Profile Options.................................................................................................... 25

9.4 Descriptive Flexfields ..................................................................................... 26

9.4.1 Descriptive Flexfield Segments.......................................................................... 26

9.5 Alerts 26

9.5.1 Alerts .................................................................................................................. 26

9.6 Workflow ........................................................................................................ 27

9.6.1 Workflows ........................................................................................................... 27

9.7 Database Objects ........................................................................................... 27

9.7.1 Tables ................................................................................................................ 27

9.7.2 Views .................................................................................................................. 27

9.7.3 Functions ............................................................................................................ 28

9.7.4 Packages ........................................................................................................... 28

9.7.5 Procedures ......................................................................................................... 29

9.7.6 Triggers .............................................................................................................. 29

9.8 Core Contracts ............................................................................................... 29

9.8.1 XML Query ......................................................................................................... 29

9.9 CRM Foundation ............................................................................................ 30

9.9.1 Dynamic Groups ................................................................................................ 30

9.10 CRM HTML Administration ............................................................................. 30

9.10.1 Declarative Components .................................................................................... 30

9.11 Customer Care ............................................................................................... 31

9.11.1 Profile Variable ................................................................................................... 31

9.12 Inventory ........................................................................................................ 31

9.12.1 Delete Constraints ............................................................................................. 31

9.12.2 Delete Statements ............................................................................................. 31

9.13 iStore 32

9.13.1 Relationships ...................................................................................................... 32

9.14 Lease Management ....................................................................................... 32

9.14.1 Criteria Category ................................................................................................ 32

9.15 Marketing ....................................................................................................... 33

9.15.1 Web Offer Query ................................................................................................ 33

9.16 Quality ............................................................................................................ 33

9.16.1 Collection Elements ........................................................................................... 33

9.17 Service ........................................................................................................... 34

9.17.1 User Defined Query ........................................................................................... 34

9.18 Warehouse Management ............................................................................... 34

9.18.1 Custom Labels ................................................................................................... 34

ConfigSnapshot Guide - Upgrades 0.2.doc -1- Company Confidential 2e2 / Client Use Only

1 Introduction

This guide is one of several covering different areas of functionality provided by ConfigSnapshot. The purpose of these guides is to supplement the in-built help and cover key areas in more depth, focussing on how the functionality can be applied to different business requirements and providing recommendations for getting the most out of the ConfigSnapshot.

The guides are not designed to be exhaustive in explaining how you can use ConfigSnapshot as different organizations can tailor the information and recommendations to best suit the way in which they use the E-Business Suite and their own specific requirements. Not all examples given will be relevant to all organizations, but it is hoped that where an exact requirement is not covered the information provided it will enable organizations to see the potential of how ConfigSnapshot can assist and be able to develop their own methods to meet these requirements.

Should you require help in understanding in how ConfigSnapshot might best help you meet a particular requirement please contact [email protected] and we will be able to provide individual assistance.

This document focuses on how ConfigSnapshot can be applied to upgrading the E-Business Suite; the scope of the document is not intended to necessarily cover all aspects of an upgrade. The included recommendations are not an exhaustive list of the ways in which ConfigSnapshot can assist with this type of project but are recommendations for usage for common requirements. If you find additional ways in which ConfigSnapshot has assisted you with upgrades please contact us at [email protected] and we will share these benefits with the wider ConfigSnapshot user base.

2 Upgrade Process Overview

2.1 Upgrade Definition

For the purposes of this document an upgrade refers to a:

Major release upgrade (e.g. 11i to R12)

Point release upgrade that includes a change to the family pack level for one or more applications (e.g. R12.AP.A.x to R12.AP.B.x).

2.2 Rollup Patches

Rollup patches modify the minor point release version of applications, for example R.12.A.0 to R.12.A.6. Typically these consist of consolidated patches for bug fixes etc with little or no new functionality for the affected modules. However, minor changes affecting functionality and the underlying database schema may be included for some modules. The Readme documents for the patch should be consulted to determine whether functionality changes have been included.

As rollup patches typically have a much narrower effect on application functionality than an upgrade, several tasks recommended for an upgrade can usually be scaled back for these types of patch. For example, rollup patches will have no effect on the majority of customisations that might have been written for the implementation. It is still important to understand the full effects of a rollup patch but it is not usually necessary to undertake such in depth analysis as it required for other upgrades.

Generally it is recommended that you follow the details covered in ConfigSnapshot Guide Patching for rollup patches. If the scope of a particular rollup patch is deemed to make it more of a risk to areas such as customisations then this guide can be used as a framework.

2.3 Upgrade Phases

Figure 2.1 shows the typical phases of an upgrade project. In general the process consists of:


An initial assessment phase that focuses on understanding which areas are likely to be affected by the upgrade and creating a detailed plan to manage each of these areas through the upgrade process.

A series of iterations of the upgrade process to ensure it has been applied correctly and that the process can be accurately repeated when the Production upgrade is carried out.

User Acceptance Testing to ensure that all existing processes work correctly in the upgraded version, any new functionality has been correctly configured to meet the business requirements and that any retained customisations continue to work correctly.

Dress rehearsal of the upgrade mirroring the Production upgrade as much as possible to finalise the process and minimise the risk of issues occurring during the Production upgrade

Production upgrade

In addition, where major new functionality is being implemented as part of the upgrade, there may be a more clearly defined Development Phase to cover the configuration and system testing of the new functionality areas. This is not shown in the diagram below.

Where the upgrade is primarily a technical upgrade or where new functionality will be implemented as a separate phase following the successful upgrade any configuration changes required for the upgrade will be managed as part of the upgrade iterations. This can include configuration changes for mandatory new features or other minor new features requiring relatively little design to implement.

Where a separate Development Phase is required for more complex configuration changes, it is likely that iterations of the main upgrade process will continue to be carried out in parallel with any development work. In these cases it is recommended that you refer to ConfigSnapshot Guide Implementation / Extension to determine how best to use ConfigSnapshot for the Development phase of the project.


3 Upgrade Preparation

3.1 Creating the Environment

It is highly recommended that upgrade activities take place on an environment that is a recent clone of the Production environment. This ensures that, for each upgrade iteration, data being upgraded mirrors Production as closely as possible, minimising the risk that any data in the Production environment could cause an issue during the final upgrade process.

Depending on the overall time taken for the upgrade process it is possible that configuration changes may need to be made or emergency patches be applied to Production after the initial cloned environment has been created. Although this should be avoided wherever possible, there are circumstances where it may not be avoided. Where these kind of changes do occur it is essential that each change is captured, documented and the potential affect on the upgrade process be quantified. Therefore it is important to implement tight control for any changes made to the Production setup after the first clone has been created.

It is recommended that you create a ConfigSnapshot baseline configuration of the Production environment at the time the clone from Production is taken for the first patch iteration. At any stage comparison between the current Production setup and this baseline can identify any configuration

changes that might need to be considered. The scope of the baseline should cover all modules being used that are being upgraded. For more information on baselines refer to ConfigSnapshot Guide XML Baselines.

3.2 Upgrade Assessment

3.2.1 Overview

The upgrade process can affect many dimensions of the implementation. The main purpose of an Upgrade Assessment is to ensure each of the affected areas is identified and a comprehensive plan developed to determine the scope of the effect of the upgrade process and the actions required to ensure each dimension is working correctly in the upgraded environment.

A well planned Upgrade Assessment prior to running the first test upgrade can help clearly determine the likely impact of the upgrade at a very early stage of the project. This can significantly improve the subsequent project planning and make for a much smoother overall process.

Some type of assessment is recommended for all upgrades but it is essential for a major release upgrade. For point release upgrades it may be possible to scale down some aspects of the full assessment; however, this should be done after consulting the patch Readme documents to understand which areas are less likely to be impacted.

The upgrade assessment will cover several different aspects of the existing system and a full description of this phase and how it should be executed is outside the scope of this document. However, some of the key areas that should be considered are:

Effect on business processes. Major upgrades and new family packs will introduce new application functionality. In most cases this will be additional functionality but in some it may force a modification to existing functionality. Most changes will be optional but some may make mandatory changes to the way in which the application works (e.g. the introduction of the new tax model in R12). It is also possible that new features may remove the need for certain existing customisations. All new features should be reviewed to determine those that will be implemented as part of the upgrade process. Further features may be identified to implement after the main upgrade process has been completed. These are likely to be features where a business benefit can be realised but they may require more detailed analysis; it may be felt that including them as part of the upgrade process introduces more risk to the project or extends the overall time for the upgrade project.

Effect on customisations. As part of the implementation it is highly likely that one or more customisations will have been made to extend the standard functionality to better meet the business requirements. These might be reports, extensions, forms, interface, workflows, packages etc. As part of the assessment all customisations should be identified so the potential impact of the upgrade on


them can be assessed. Some customisations may continue to work without modification after the upgrade; some may be replaced by new application functionality while others may require modification to enable them to work correctly. Regardless of whether customisations are identified as requiring modification, all retained customisations should be tested in the upgraded environment.

Effect on existing data. During the upgrade process it is possible for existing setup data to be modified in some way. This is a particular risk where previously seeded data has been modified or added to, for example inclusion of a custom concurrent program in a seeded request group or additions to a seeded menu.

Effect on Technical Infrastructure. This includes determining whether the underlying database or other technical components require upgrade as part of the process, potential effect on data volumes, possible effects on other 3rd party products installed that interact with the E-Business Suite etc.

Another key activity during the Upgrade Assessment is to review either the Upgrade documentation for major release upgrades or patch readme documentation for family packs. These provide detailed information regarding which steps should be followed as part of the upgrade process. In addition, for major upgrades, Oracle provides tools to assist in identifying which specific steps should be carried out based on the existing implementation settings.

3.2.2 Analysing Existing Setup

Wherever new functionality is being implemented as part of an upgrade it is essential to review the current setup in those areas to best determine how to integrate new configurations.

ConfigSnapshot can quickly provide details of the existing setups so that they can be reviewed. This is particularly useful for areas where significant changes are expected in the upgraded version (for example the introduction of E-Business Suite tax in R12). The reports will

assist the project team in assessing these areas to determine the configuration changes to make once the main upgrade process has been completed.

Use ConfigSnapshots standard Single Environment reports to generate the current setup in the areas to be reviewed. When generating these reports pay careful attention to both the scope of the areas reported and the format for the output. The aim of this process is to target areas that may be affected by the new functionality NOT to report the full setup for any module. In addition, consideration of how best to format each report can greatly simplify this analysis.

Consider which setup steps should be included do not include steps that are not necessary

Determine whether all data levels are required for each reported step; consider excluding data levels not necessary for the analysis

Control whether each step should be reported in the default format or whether alternatives, such as widescreen reporting, might be more effective

For some setup steps you may wish to consider whether more than report, each focussed on certain aspects, could be beneficial to better understand the setup. For example, you may wish to report on the step in detail but also create a summary matrix report showing just the top level of information to get an overview of what is configured. Combining the output of both reports provide a better analysis than simply reporting the detailed data in isolation.

Refer to ConfigSnapshot Guide Basic Reporting, ConfigSnapshot Guide Advanced Formatting and ConfigSnapshot Guide Using Filters for more information about the different ways in which reports can be submitted.

If you wish to report on single setup steps in multiple ways or wish to include steps from multiple modules in your report(s) consider creating a Configuration Set to define the reporting requirements. For more information refer to ConfigSnapshot Guide Configuration Sets.

The purpose of reporting at this stage is to provide the foundation for the design of how new functionality will be integrated. As you begin to manage the configuration changes required for new functionality it is possible to quickly generate up to date configuration reports at any time.


3.2.3 Determining Setup at Risk

Overview

When you perform an upgrade there is a risk that existing setup may be modified in some way. It is critical to identify these changes to ensure that any modifications are as required otherwise the application may no longer perform as expected. Any modifications made by the upgrade process that are not correct must be noted and an action plan created to adjust these settings to the desired value.

These modifications will need to be checked and addressed for each iteration of the upgrade. Generally there are two approaches to dealing with these modifications:

Document the step(s) required to change the setup to the required value and repeat these steps for each upgrade iteration.

Make a modification to the data at source prior to the next upgrade iteration so that the data is no longer modified.

Which of these two methods is most appropriate will depend on each specific modification.

Once the first upgrade has been applied you can use ConfigSnapshot to quickly identify any modified data or newly introduced seeded Oracle data using Comparison Reports; this process is described later in this document. Therefore, it is not critical at the assessment stage

to determine data that may be affected as the actual effect can be accurately determined once the first upgrade process has been completed. However, it can be beneficial to highlight potential risk areas as early as possible so that plans to mitigate any risk can be initiated as soon as possible.

It is important to stress that most setup data will not be modified by the upgrade process but the following situations pose the greatest risk:

Seeded data has been updated to a different value the upgrade may replace the modified value with the current seeded value

Seeded data has been extended with implementation specific data. In some cases this poses little or no risk, for example adding a lookup value to a seeded lookup type. In other cases, such as adding menu items to a seeded menu, there is a much greater risk that the extensions will be lost as part of the upgrade even though no change has been made directly against any seeded record.

Implementation setup data has been carried out in a way that does not meet standards defined by Oracle. In this case there is a risk that the upgrade might overwrite implementation data with new seeded data. For example, if a custom application has been registered but has been given a short name that is subsequently used by a seeded application the upgrade may either overwrite the custom application or the upgrade process may fail until the conflict has been resolved.

Amended Seeded Data / Implementation Data Appended to Seeded Data

The colour coding used in ConfigSnapshot reports quickly highlights records that were seeded but have been potentially changed from their default settings (Amended Seeded Data from the ConfigSnapshot report legend). To further assist with this analysis it is recommended that the Show History Fields checkbox is set ON for these reports so that who created and last amended each record is clearly shown. This enables further analysis for those records identified to determine whether they are likely to be at risk.

The amount of data reported can be minimised by only reporting data that was created by one of the seeded users.

To highlight the amended seeded data run a Single Environment report for each of your modules with the following settings:

Created/Updated By Specific User(s) checked ON. When you continue choose the following from the list of available users:

o AUTOINSTALL, INITIAL SETUP, APPSMGR, SEED, SYSTEM, ORACLE12.0.0, ORACLE12.1.0, ORACLE12.2.0, ORACLE12.3.0, ORACLE12.4.0, ORACLE12.5.0, ORACLE12.6.0, ORACLE 12.7.0, ORACLE12.8.0, ORACLE12.9.0.


o N.B. Depending on the version of the E-Business Suite you are currently using not all these users will be available for selection. If the user is not in the list of values it can be ignored.

Show Deactivated Data checked ON. This ensures you identify any seeded record that has been deactivated for the implementation.

Show History Fields checked ON. This will provide feedback about who created records and who they were last amended by.

Review each record included in the report where it was created by one of the seeded users but subsequently amended by another, non-seeded, user. Determine whether the record may be at risk during the upgrade and ensure it is checked once the upgrade has been completed.

N.B. Once the upgrade has been completed comparison reports will enable you to determine whether the settings have actually been affected.

It is recommended that Standard Run Options are created for these settings to simplify repeating this analysis for future upgrades. For further information regarding how to create these refer to ConfigSnapshot Guide Standard Run Options.

Since 11i Oracle has delivered some seeded data as SYSADMIN rather than AUTOINSTALL or INITIAL SETUP etc. Depending on the way in which the implementation has been configured some implementation specific setup may also have been created as the SYSADMIN user. It is not recommended that further implementation data is setup while logged on as SYSADMIN for the following reasons:

Using a general user prevents proper tracking of how the system has been configured; this can be an issue for auditing requirements such as Sarbanes Oxley.

Oracle now treats any updates made by SYSADMIN as seeded increasing the risk of configuration done as the SYSADMIN user being adversely affected by future upgrades or patching. See Oracle Applications System Administrators Guide Configuration for more details.

It is therefore recommended that you also review records created by SYSADMIN that have subsequently been modified by another user to determine if these also represent records at risk, i.e. where the record was seeded but changed by an implementation user.

As there is no automatic way to differentiate records created as SYSADMIN that were seeded from those created by an implementation user logged in as SYSADMIN, all modified SYSADMIN records will need to be reviewed to determine whether the record was specifically added for the implementation or whether it was seeded and been subsequently amended. Although this requires a more manual process, by targeting the data effectively it can be accomplished relatively quickly.

To target the SYSADMIN data most effectively it is recommended that you run Single Environment reports for your modules with the following settings on the Run Options form:

Created/Updated By Specific User(s) checked ON. When you continue choose SYSADMIN from the list of available users.

Show Deactivated Data checked ON. This ensures you identify any seeded record that has been deactivated for the implementation.

Show History Fields checked ON.

In a similar process for the amended seeded data above, review each recorded included in the report. In this case you should also review records created by SYSADMIN even if they have not been subsequently amended. The purpose of the exercise is to identify any records included in these reports that have been created as part of the implementation rather than being seeded by Oracle. Determine whether each identified record may be at risk during the upgrade (primarily by checking any standards specific by Oracle) and ensure it is checked once the upgrade has been completed.

N.B. Once the upgrade has been completed comparison reports will enable you to determine whether the settings have actually been affected.

It is recommended that Standard Run Options are created for these settings to simplify repeating this analysis for future upgrades.


Extended Seeded Data / Records Not Matching Oracle Standards

Data where seeded records have not been modified but where implementation data has been added to extend the seeded data will not be identified by the two sets of reports defined above unless the seeded data was installed as the SYSADMIN user.

It is recommended that Single Environment reports are submitted for specific key module steps to determine:

Extensions to seeded data that could be lost during the upgrade

Records defined that do not meet standards defined by Oracle

Both of these requirements can be addressed by a single set of reports. The following are the recommended settings on the Run Options form:

Show Seeded Data checked OFF. This will ensure basic seeded data is not included in the reports. The only seeded data shown will be where it has been modified or extended.

Review the Module Step Definition reports for each of your modules to determine which steps should be included in the scope of these reports. Refer also to any Oracle module documentation to review which steps have specific standards and what these standards are. Depending on the definition of each Oracle standard you may be able to further target records using one or more ConfigSnapshot filters.

Some steps in this category are applicable to all implementations such as:

Menus (System Administration)

Request Groups (System Administration)

Other steps will relate to specific modules and only need be included if the module is in use.

As only specific setup steps need be reported for this part of the analysis rather than submitting a Single Environment report for each module it is recommended that one or more Configuration Sets are defined and the Single Environment reports are initiated from these sets. This simplifies the overall reporting process and makes it easier to repeat the analysis consistently for future upgrades. See ConfigSnapshot Guide Configuration Sets for further details.

It is beyond the scope of this document to provide a full list of steps for all modules that should be included in these reports as Oracle may change its standards etc. However, a list of recommended steps has been included in Appendix 1.

3.2.4 Identifying Customisations

Overview

One of the key areas of investigation during the Upgrade Assessment is the identification of customisations and the analysis of how these might be affected. Most E-Business Suite implementations include at least one customisation, whether this is a report, form, interface or some other customisation.

When identifying customisations the first thing to consider is exactly what constitutes a customisation. For the purposes of this document, a customisation will be defined as any of the following:

Non-standard database object, including tables, views, packages etc, not created as part of E-Business Suite installation, upgrade or standard process.

Non-standard programs, including reports, forms, interfaces etc, used as part of the E-Business Suite implementation. Generally these will be registered in some way as part of the implementation set up.

Configuration items that have fields that include SQL-based information. Any of these items could be affected if the underlying schema objects are changed as part of the upgrade

Other setup items outside of this definition may be affected by the upgrade but these should be covered by the recommended reporting described in Determining Setup at Risk.

For each potential area of customisation the following analysis should be carried out:

Identify all instances of the customisation type


Determine whether each individual customisation should be retained after the upgrade

Determine which of the retained customisations require modification to continue to work successfully in the upgraded environment

As a minimum the first two stages of this analysis should be carried out as part of the Upgrade Assessment. The ability to perform the third stage, determining which of the retained customisations will require modification as part of the upgrade, will depend on what resources are available to the Upgrade Team.

Oracle previously published Product Update Notes for major upgrades which gave details of all schema changes between versions. Unfortunately this information is no longer published so identification of schema changes, and hence the effect on customisations, is significantly harder for development teams.

ConfigSnapshot can greatly assist in the analysis by allowing comparison of schemas between the upgraded environment and the current environment. This will highlight all changes between the two versions. There are two common ways in which to perform this analysis:

Perform the first upgrade iteration and when this is complete compare the upgraded environment against the pre-upgraded environment.

Install a vanilla instance of the applications that are at the same patch level as the upgraded environment will be. Compare this vanilla environment against the pre-upgraded environment.

Installing a separate vanilla instance is an additional step that is not necessary for the main upgrade process. However, if this can be carried out there are some benefits that are not possible simply using the main upgrade environment itself:

The vanilla environment can be prepared prior to the first upgrade iteration allowing the investigation of the schema changes to be done earlier and hence the assessment of the total effort required for customisation modification to be quantified earlier; leading to more detailed planning at an earlier stage.

When environments are upgraded some objects may no longer be used as part of the applications. However, these objects are often not removed from the environment during the upgrade process. Therefore, straight comparison between the upgraded and pre-upgrade versions of an environment will not identify objects that would not have been installed if it this had been a new installation. Comparing a vanilla instance at the target patch level to the pre-upgraded environment should highlight objects in the current version that will no longer be valid in the upgraded version. This provides the Development Team will more detailed information with which to analyse the customisations to determine any that reference objects that will no longer be valid.

These benefits must be balanced with the overhead of having to perform the additional task of installing the vanilla environment. In general, this method is more appropriate for major upgrades where the impact on schemas is much greater. For point release upgrades the reduced scope of change and, hence lower impact on customisations, comparing the pre- and post-upgrade schemas is usually sufficient.

Identifying Customisations

Customisations and extensions can be made in many areas of the E-Business Suite and how to identify these will depend on each type of customisation. In some cases the best method will depend on the resources available to the Upgrade Team.

ConfigSnapshot reports can be used to identify many areas of customisation; both at a summary level to quantify the extent of customisation, providing a mechanism by which they can be reviewed to determine whether they should be retained, and at a detailed level, providing a mechanism to

reference against the list of changed objects to quantify which retained customisations are likely to require modification.

In some cases it may not be possible to extract details of just customisations as there is no guaranteed rule to target this data. However, in most of these cases ConfigSnapshot reports can be used to target data so that the volume of information that the Development Team must review to

identify the customisations is much reduced compared to the total volume of data.


It is beyond the scope of this document to exhaustively list all possible areas of customisation and it is recommended that the Upgrade Team reviews the available Oracle documentation to compile a full list of areas that should be considered. However, Appendix 2 provides details of most common customisation areas and also details of specific settings for ConfigSnapshot reporting to best capture the customisation details.

As the configuration steps covering customisations are spread across multiple modules it is recommended that Configuration Sets are created so that the reporting can be carried out more quickly and the process can be done consistently over subsequent upgrades.

Determining Which Customisations to Retain

Some customisations identified in the current version may not be required in the upgraded version for several reasons, the most common being:

The customisation is no longer used but is still active

The customisation can be replaced by standard functionality in the upgraded version

To simplify the upgrade process, both the current upgrade and any future upgrades, it is recommended that existing customisations that are not required in the upgraded version be disabled or removed where possible. This housekeeping simplifies ongoing application administration and can prevent unnecessary work being carried out on modifications.

Review the list of customisations identified with ConfigSnapshot to determine any that are no longer required. For summary matrix reports it can be beneficial to review the output in Excel and use standard Data Filters to focus on different groups of data. For example, in the Concurrent Program

summary this can be used to focus on specific program types (Oracle Report, SQL, Host etc).

4 Test Upgrade Iterations

4.1 Test Upgrade

Process Overview

Once the Upgrade Assessment and planning has been completed the first test upgrade can begin. Key to the success of an upgrade is the ability to capture all activities that are performed during the upgrade process, issues encountered, resolutions, workarounds and the timings for each of the steps. This recipe is then used to repeat and refine the process through further test iterations. By repeating the process successfully multiple times minimises the risks associated with the Production upgrade.

As each stage of a test upgrade is performed all actions taken and any supporting information should be recorded in an Upgrade Log. This should be the master document used to control repeating the actions during each subsequent iteration. As each iteration is carried out, the log should be refined as required. The more complete is the Upgrade Log, the lower the risk of issues being encountered during the Production upgrade.

The way in which major upgrades and family pack upgrades work is fundamentally different but both can be characterised by the following basic process:

Pre-upgrade steps or patch prerequisites

Main upgrade or patching process

Post-upgrade steps or post-update steps

Pre-upgrade Baseline

It is recommended that a ConfigSnapshot baseline of key areas is created prior to undertaking each upgrade iteration. This enables the configuration setups as they are prior to the upgrade process to be captured so that they can be referenced as the project continues. The scope of this baseline

should include:


All application modules being used

Supporting areas including:

o Application Developer

o System Administration

o Organisation Structures

o Descriptive Flexfields

o Personalisation

Workflows

o This can be restricted to the Workflows being used as part of the implementation

Database objects where a separate vanilla environment has not been installed

o Tables

o Views

Other database objects (e.g. database triggers, packages etc) can also be included in the baseline. However, there are other methods to determine which of these have been changed during the upgrade. Changes to these objects do not generally affect customisations but will affect application functionality and should be considered when planning test scenarios. This is considered further in Effect on Application Functionality.

For details of how to create ConfigSnapshot baselines refer to ConfigSnapshot Guide XML Baselines.

Post-upgrade Baseline

It is likely that having performed the upgrade and carried out any prescribed post-upgrade or post-patch steps further modifications may need to be made:

To adjust setups modified by the upgrade process where the change was not correct for the implementation

Modifications required to ensure specific functionality is working correctly

Implementation of new features being introduced as part of the upgrade

To implement clear change control it is recommended that another ConfigSnapshot baseline is created once the upgrade and prescribed post-upgrade steps have been completed and before any other configuration changes are made. This will enable comparison reports to be run at later stages

to clearly identify any additional configuration changes made.

If there are manual configuration changes to be made as part of the post-upgrade steps it is preferable to create the baseline prior to carrying them out. This enables all manual configuration changes that have been made to be identified by comparing the current environment settings with the post-upgrade baseline.

The main purpose of this baseline is to minimise the risk that any configuration changes are not repeated during subsequent iterations.

4.2 Upgrade Effects

4.2.1 Overview

One of the key requirements for any upgrade is to understand what has been the effect on the configuration setup and application functionality.

The two main potential risks to application configurations are:

Existing setups are modified in some way by the upgrade process. If these modifications are not expected they may cause issues when using the upgraded application.


The upgrade introduces a new seeded setup item that affects the business process

An upgrade will introduce new functionality and modifications to existing functionality. It is essential that the testing phase of project considers these and determines those that are relevant to the implementation. It is possible that the test phase attempts to be fully comprehensive and test all potential scenarios for every business process. However, in reality this is seldom possible and, if undertaken, might be an inefficient use of resources if significant testing were carried out on areas that were actually unaffected by the upgrade.

Usually the approach to testing will be different for a major release upgrade compared to a family pack upgrade. For a major release there should be an assumption that all areas of functionality have been affected by the upgrade and testing should be as comprehensive as time and resources allow. For family pack upgrades it is much more efficient to prioritise testing on those areas affected by the upgrade as many other areas will not be changed. However, the issue for the Upgrade Teams is to accurately identify which areas have been affected to enable this prioritisation. Traditionally the first point of call would be the patch readme documents. However, although these give an overview of the new and changed functionality introduced by the patch, they are typically not comprehensive; for example they normally list a number of patches included but do not clearly list all components (forms, reports etc) that will be affected, and therefore should be tested, as a consequence.

This section explains how ConfigSnapshot can be used to identify these affects and describes the benefits this provides.

4.2.2 Effect on Application Setups

Traditionally it is extremely difficult to determine the effect of an upgrade on existing setups and comprehensively identify any new setup introduced. It is not practical to manually review all setup to try to identify if a modification has been made. Not only would this take an enormous manual effort when the number of modifications might be quite small it would not be possible to be sure that all areas had been checked thoroughly and whether all modifications had actually been identified. Therefore, it is usual to place the burden of trying to determine any effect on the testing cycle. However, this introduces risk into the project as without knowing what has been affected it is not possible to ensure that the test plan would actually pick up all potential issues.

ConfigSnapshot comparison reports can be used to determine these effects.

Existing setups modified by the upgrade process

New seeded setups introduced as part of the process

Setup fields that have been introduced and may need to be configured

All three of these analysis requirements can be completed with a single ConfigSnapshot comparison report. The comparison report can be done either between the current application setup and the pre-upgrade baseline or between the post-upgrade baseline and pre-upgrade baseline.

One major benefit of comparing post- and pre-upgrade baselines is that work can continue on the upgrade in parallel to the analysis of the upgrade effect as both the pre- and post-upgrade baselines will be unaffected by any new configurations. If comparisons were being done using the current environment setup rather than a post-upgrade baseline these reports must be run before any further configuration changes are made to ensure any differences identified were made during the main upgrade process (including prescribed post-upgrade steps). It would also be preferable for the analysis of the reports to be completed prior to any further configuration, in case investigations require further reporting to be carried out. By comparing pre- and post-upgrade baselines this is not an issue as subsequent reports would not be affected by any changes made to the environment.

If a pre-upgrade baseline was not taken it is still possible to assess the upgrade impact by comparing the upgraded environment (or post-upgrade baseline) against the environment from which the upgrade environment was cloned. However, when doing this care must be taken to consider whether any configuration changes have been made to the source environment after the clone for the upgrade was taken.

To carry out the comparison analysis, run the reports against each module using the following Run Options:

Show Seeded Data checked ON


Show History Fields checked ON

Only Show Differences OR Show Records With Differences. Either option is suitable.

When reviewing the comparison documents the following should be identified and investigated:

Any value found to differ between pre- and post-upgrade setup should be reviewed to determine whether the post-upgrade setting is correct or whether the pre-upgrade setting should be reinstated. The history information should confirm the change being made as part of the upgrade process. Any settings found to be incorrect should be modified and the steps taken added to the Upgrade Log.

Any records that have been created as part of the upgrade should be reviewed to determine whether they might have any affect on the business process. Where a new record is found to be relevant, the test plan should be reviewed to ensure the scope of testing will cover the effect of the new setup. Particular attention should be paid to new setup that affects application security (for example where a new form or function has been added to support new functionality it may automatically be added to one or more existing standard menus; users may therefore automatically have access to these new areas. As part of audit and control analysis these should be checked to ensure no user has access to new areas they should not be granted as part of the upgrade).

Where new fields have been added to support functionality changes these will be highlighted by being blacked out in the pre-upgrade setup and available in the post-upgrade setup. In some cases a default value may have been set by the upgrade and in others the value for the new field may have been left blank. The former would be identified by the first stage of the analysis highlighted above as it would show up as a difference between the two setups. However, the latter circumstance where the field has been added but no value set during the upgrade should also being investigated to determine whether a value should be set.

4.2.3 Effect on Application Functionality

Overview

For major upgrades there should be an assumption that all areas of the applications will be affected and testing should be as comprehensive as possible across all business processes. For family pack upgrades the changes will be limited to specific areas of the applications. Although it is recommended that testing be as broad as is practical, effort should be focussed, where possible, on those areas that are known to have been directly affected by the upgrade process. This maximises the effectiveness of the testing phase and will reduce time wasted on running tests against areas of the applications that have not been changed.

The main challenge in trying to limit the scope of testing is to accurately identify which areas of the applications have been affected by the upgrade. Certainly the patch readme files should be reviewed to determine an overall summary of the changes that have been included. However, they will focus on areas of functionality change; in reality these patches will also include a consolidation of many individual bug fixes that will affect many other components. These components are not clearly listed in the readme files. In addition, the actual components affected on any specific environment will also vary based on other patches that may have been previously installed.

Reporting the Effects

ConfigSnapshot includes a Patch Impact Analysis process to help identify components (forms, functions, workflows etc.) affected by the process. This can be used to determine where key testing areas should be focussed.

The Patch Impact Analysis is carried out by running the Applied Patches (Detail) option within the E-Business Suite DBA area. This provides details of all components that were included in a patch, or group of patches. However, rather than listing details of every component included in the patch it is recommended that the report is focussed only on those components that were actually executed when the patch was run.


In addition, understanding the actions that are carried out when a patch is applied can allow for further targeting of the data reported. Several actions during a patch will be the generation (or compilation) of components such as forms and libraries. These compilation actions will be carried out on components included in the patch regardless of whether the component was actually changed by the patch. Generally the most important consideration for components such as forms is whether it was replaced with a later version; the fact the existing component was recompiled should have no effect (unless for some reason it fails to compile). Therefore, it is recommended that generate actions are excluded from the report to focus on the real, material effects.

The following options are recommended for the Applied Patches (Detail) report:

Show Seeded Data checked ON (patch information is logged as being done by AUTOINSTALL)

Output Type = Excel. This allows further analysis to be carried out on the reported data.

Filters to be applied against the Applied Patches (Detail) step:

o Patch Number =

o Component Executed = Yes

o Component Action != genform, genfpll, gengpll, genmenu, genogd, genrep, genrpll

It is also possible to exclude specific component extensions from the report and these can be specified as further filters. Some components, such as forms, have a clear direct effect on the application functionality and must be checked. Other components may have no direct effect or their effect may be picked up by other stages of the analysis. For example:

odf files Object Description Files include a description of tables, views, indexes and sequences etc for the building blocks of the E-Business Suite. When an upgrade is applied these are compared against the existing objects in the environment and any differences applied during the upgrade. Understanding the effect of the upgrade on tables/views etc is key to being able to carry out the impact analysis of identified customisation. However, ConfigSnapshot can identify these differences by running a comparison report. Several options for the comparison report are possible, as described elsewhere in this document. All provide a much simpler mechanism to identify the effect on database objects rather than trying to interpret the various odf files:

o The pre- and post-upgrade configurations.

o The upgraded environment and original source environment from which the upgrade environment was originally cloned.

o The pre-upgrade environment and a vanilla install at the target patch level

lct / ldt files both these file types are used as part of FND Loader by Oracle to introduce or modify seeded data. Lct files provide the definition for the loader and ldt files include the data to be loaded. As explained in Effect on Application Setups the effect on seeded data by the upgrade process can be discovered by running ConfigSnapshot comparison reports

pdt files also used as part of the loading of seeded data.

gif files image files that are unlikely to affect the application functionality

It is recommended that the Upgrade Team review other extensions that can be excluded from the impact analysis. These extensions can be included in the filters when submitting the report, e.g.

File Extension != odf, lct, pdt, gif

As described in Analysing the Effects by using data filters in Excel you can focus in turn on different file extensions so even if the extensions are included they can quickly be differentiated.

To ensure consistent analysis of each upgrade you perform, it is recommended that Standard Run Options are created with all filters set except for the Patch Number. When the analysis is ready to be performed the Standard Run Options can be applied and the specific patch numbers set as

additional filters.


Analysing the Effects

Family pack upgrades can affect many thousands of components so a structured approach to the analysis of the components is necessary. There are several ways to undertake the analysis so a definitive series of actions will not be specified in this document. The Upgrade Team should

determine the depth and order of analysis, focussing on the most likely components to affect functionality first.

The following guidelines should help Upgrade Teams to define their approach to analysing patch effects. The most important aspects of the analysis are to:

Focus on application areas that are used within the implementation; consolidated patches may include effects across the entire E-Business Suite, many areas of which will not be relevant to the business process.

Work logically through the different types of component (form, report, workflow etc) and determine whether each component identified is used within the implementation. Where a component is identified as being used ensure the test plans cover the component functionality.

When analysing the patch effect add a standard Data Filter in Excel to enable different groups of rows/columns to be focussed on.

The Component Application column can be used to focus on a specific application at a time. This can be used by different team members to review the effect on the areas of the implementation they are responsible for. Care must be taken to ensure to include common areas such as Application Object Library in the analysis.

For many components either the File Extension column can be used to differentiate different types of components, e.g.:

fmb files application forms. ConfigSnapshot shows the file name and will highlight the version of the form in the patch and the version of the form that was previously on the environment. To assist the Upgrade Team, ConfigSnapshot includes the user name for the form where the form is registered in the applications. This allows the team to more quickly identify which of the modified forms are used. Where no user form name is shown, the form is not directly registered in the applications. In these cases the Development Team should review the fmb file to identify the purpose of the form to determine whether it is used and where it may be called from, e.g. another form.

xml files the E-Business Suite now contains many browser-based forms. Complete analysis of the effect of changes on these is more complex as they can be made up of many different components. The patch impact analysis allows these components to be seen and, where possible, tries to link the component to a specific form function in the applications. The user name of the form function is shown to assist the Upgrade Team determine whether it is used as part of the implementation. As there is no direct link without examining the contents of the xml files themselves, ConfigSnapshot has to identify the most likely form function. In the vast majority of cases the correct form function will be identified as the name is unique; in a few cases where the xml name has been used for more than one form function the first matching value will be shown. These are generally quite easy to spot in the report as they tend to have more generic filenames. Although the analysis cannot be completed 100% in all cases the additional information in ConfigSnapshot significantly simplifies the process.

rdf file application reports that are called as Concurrent Programs. ConfigSnapshot again provides the registered name for the report to allow the Upgrade Team to determine which of the reports are currently used.

For other components there are alternative methods to determine the effects rather than focussing on a specific file extension, including:

SQL reports if the File Extension SQL is selected this would include any Concurrent Program SQL reports. However, it would also include any number of additional components such as sql scripts to generate new versions of packages etc. To focus more specifically on SQL reports it is better to filter on the Directory column, selecting a value of sql. This will only return SQL scripts that are called as a registered Concurrent Program. The user concurrent program name will be included, enabling the Upgrade Team to determine which are currently used and must be tested.


Workflows workflows are stored as data rather than as separate files, so it is not possible to look for different file components to determine whether any workflows have been changed. However, all new versions of workflows will be loaded by the patch. To identify these, filter on the File WFLOAD.exe. This will return all workflows loaded. As part of the Arguments column you will see the workflow item type. This enables the Upgrade Team to determine which workflows have been amended and highlight any that are used.

Packages / Functions / Procedures / Triggers if the Upgrade Team wishes to determine which of these has changed during the upgrade it is simpler to carry out a comparison report rather than to try to decipher the information based on the component information. The scripts to generate these objects will be shown in the Patch Impact Analysis report (generally with two actions for each; copy to install the new version followed by execute to compile the new version of the object). However, the filename of the component is not too meaningful to the Upgrade Team. A ConfigSnapshot Comparison report between the upgraded environment and either the pre-upgrade baseline or the environment from which the upgrade environment was cloned can more easily and clearly show which objects have changed during the upgrade. It is recommended that the comparison reports focus on picking up where the reported version has been changed where possible. For triggers a detailed comparison must be completed to identify changes. It is more difficult for the Upgrade Team to pinpoint where particular packages are used as part of the application functionality so this analysis should be used more as assisting information in most cases to determine areas that appear to have been affected. To submit the comparison report, include the following steps from Database Objects:

o Packages

o Parent Records Only checked ON

o Show Package Version Information checked ON

o Procedures


o Show Procedure Version Information checked ON

o Functions


o Show Function Version Information checked ON

o Triggers

ConfigSnapshot can significantly assist the Upgrade Team in understanding which areas of the applications have been affected by the application of one or more patches. Although a structured approach must be employed to leverage the maximum information from the Patch Impact Analysis report, the process is relatively straightforward for teams with a good knowledge of how the E-Business Suite is architected. A short time in designing a process for analysing the patch effects will provide significant benefits.

4.3 Maintaining Customisations

4.3.1 Existing Customisations

Any necessary modifications to customisations can be carried in parallel to the test upgrade iterations out before passing them to System Test to ensure they still operate correctly in the upgraded environment.

As described in Identifying Customisations, the main cause of customisation modification is change to the underlying schemas. However, other causes may also need to be considered. For example, if an underlying technology changes; such as the version of forms or reports used by Oracle; other maintenance may be required, even if this is as simple as recompiling the code in the current version of the technology.

For major release upgrades there may be significant changes required to some retained customisations due to differences in the underlying schemas.

For point release upgrades the modification to underlying schemas is generally relatively minor. In most cases the schema changes will be related to the introduction of new functionality and existing customisation will usually remain unaffected. However, this is not always the case so the analysis cannot be completely


ignored. The most likely cause of issues for family pack upgrades is where Oracle changes the underlying tables for particular functionality in one version to completely new underlying tables in another version. Although rare, this does happen and can easily catch developers out as customisations appear to work correctly until new data is created that populates the replacement tables rather than the original tables; the customisation being unaware of this new data. As Oracle usually does not remove older tables this sort of change can be difficult for developers to identify.

Expanding on the information provided in Identifying Customisations, the process for determining which tables / views have been affected is to run a ConfigSnapshot comparison report that looks across the two versions of the applications. Depending on the process being followed this

comparison will usually be done using one of the following combinations of environments:

Post-upgrade baseline and pre-upgrade baseline (recommended for point release upgrades)

Current upgraded environment and pre-upgrade baseline

Current upgraded environment and environment used to create original clone for the upgrade

Vanilla install of environment at target patch level and pre-upgrade baseline (recommended for major upgrades)

The considerations for which source and target environments to use for the comparison are covered in Identifying Customisations. If the last option (vanilla install vs. pre-upgrade baseline) is used the comparison can be carried out prior to the upgrade process. For all other options the comparison can only be carried out after the first iteration of the upgrade has been completed.

There may be several temporary tables within an E-Business Suite environment and these can cause differences to be shown between a source and target that can be ignored when carrying out the impact analysis. If the comparison is done between the pre- and post-upgrade baselines for the upgraded environment the temporary tables should be consistent as they are snapshots of exactly the same environment at different times so there should be few, if any, examples of temporary tables reported in the comparison reports. When comparing between the pre-upgraded environment and a vanilla install of the upgraded environment some temporary tables may be included in the report; these can be ignored for the impact analysis. Although there is some manual effort in identifying these temporary tables, they are generally quite clear and the other benefits in comparing to the vanilla install in identifying objects no longer used by the applications outweighs any effort in excluding the temporary tables.

Detailed comparison of the tables and views can be carried out by running the following comparison report from Database Objects:

Only Show Differences checked ON

Steps chosen; Tables, Views

Filters are not necessary unless comparing across different environments. In this case it is recommended that the Tablespace field is hidden for Tables. This ensures no differences due to variations in tablespace design being returned where there is no real difference in the table structure. For more information on applying filters see ConfigSnapshot Guide Applying Filters.

It can also be useful, particularly for family pack upgrades, to also report a summary of the tables that differ between the pre-upgrade and post-upgrade environments. Primarily this is to highlight new tables introduced by the upgrade. As stated, in most cases these will be to support new functionality. However, in cases where Oracle has changed the tables underlying some particular functionality it is easier to identify these from the summary report. To get a summary of changes run the following comparison report from Database Objects:

Only Show Differences checked ON

Steps chosen; Tables, Views

Set a filter against both steps Parent Records Only checked ON this will ensure only the header information is checked rather than the column details (which will be shown in the detailed report above).

As with the detailed report hide the Tablespace field for Tables, if necessary.


The comparison reports should be used by the Technical Developers to identify objects that are used retained customisations. Although customisations must be checked for these objects, the process is significantly simplified as the list of objects to check is dramatically reduced.

4.3.2 New Customisations

As part of new functionality being implemented there may be additional technical development requirements to support new customisations. These can be controlled and managed as described in ConfigSnapshot Guide Implementation / Extension.

4.4 Configuration Changes

As part of the upgrade manual configuration changes may need to be made after the main upgrade has been completed. These might be to correct changes made to modifications made as a consequence of the upgrade or to support mandatory new features. It is essential that all these changes are documented to ensure they are accurately repeated for each iteration of the upgrade.

As stated above, it is highly recommended that a ConfigSnapshot baseline is taken after the main upgrade has been completed. This will allow for comparison between the current environment and the environment as it was prior to any manual changes being made; making it easy to determine

any changes that have been applied.

Details of the configuration steps where changes are made can be controlled using Configuration Sets. Separate Configuration Sets may be controlled by individuals or sets may be shared depending on the requirements. As changes are made each configuration step should be added to

the Configuration Set. Where appropriate it is recommended that comments are included with steps:

Explanation comments to provide details about why the configuration change is being made.

Instructional comments to provide any pertinent details to whoever is repeating the setup on later iterations.

Where steps taken are not specific configuration setup in the applications (for example running a SQL script or submitting a concurrent program) these can still be included in the Configuration Set as manual steps. Full details of the actions required can be provided within the manual step.

Where the sequence of events is important this can also be captured in the Configuration Set to ensure the generated documentation includes the necessary dependencies.

For more information on Configuration Sets refer to ConfigSnapshot Guide Configuration Sets.

4.5 Implementing New Features

As part of an upgrade, non-mandatory new features may be implemented these should have been identified as part of the Upgrade Assessment. Once the main upgrade process has been completed, including any post-upgrade steps, and the effect of the process quantified any new feature implementation can begin.

The process for the implementation of new features will be determined by their complexity. Smaller changes can most likely be controlled as part of other configuration changes as described in Configuration Changes above using Configuration Sets. However, for more complex

enhancements it is recommended that the process defined in ConfigSnapshot Guide Implementation / Extension is used as the framework.

4.6 Systems Test

4.6.1 Standard Functionality

Once the upgrade process has been completed, new features configured and any other configuration changes made the environment must be tested to ensure that the system works as expected.

For family pack upgrades use the findings from the Patch Impact Analysis to help prioritise where


testing should be carried out.

In some cases modification to setup may occur during system testing if issues are found. These must be recorded and added to the Upgrade Log and, where appropriate, Configuration Sets to ensure the changes are made correctly during the following iterations.

4.6.2 Customisations

As part of the System Test ALL retained customisations should be tested regardless of whether they have been amended or not. In addition customisations should be tested with both existing data and after new data has been added after the upgrade process. This is to ensure that where data is now stored in different tables than before the upgrade any effects will be felt by the customisations. This will greatly assist in highlighting any customisations that have been affected by situations where the underlying tables have changed.

The information highlighted during Identifying Customisations can be used as the basis to ensure each customisation is tested.

4.6.3 Post-System Test Baseline

To enforce strict control on the environment it is recommended that a further ConfigSnapshot baseline is taken once Systems Testing has been completed. This enables any changes that might have been made after the completion of Systems Test to be identified so that they can be captured

and added to the Upgrade Log, any potential effect investigated and any further testing required as a consequence of the change(s) completed.

Once System Testing has been completed either the next iteration of the upgrade will be carried out or the environment will be used as the basis for User Acceptance Testing. By taking a baseline at the end of System Testing any changes made AFTER the next stage has begun can be highlighted and the potential impact on the subsequent phase considered and acted on.

4.7 Confirmation of Upgrade Iteration

It is not practical to fully repeat System Testing for each iteration of the test upgrades. However, it is important to check that all the steps recorded in the Upgrade Log and, where appropriate, Configuration Sets for configuration changes and new features have been successfully repeated. If steps are not correctly carried out on each iteration there may be consequences that cause functionality to work incorrectly.

To determine whether each iteration has been completed correctly use ConfigSnapshot comparison reports at the end of each test iteration once all planned steps have been completed. Compare the setup on the current iteration with the setup of previous iterations. The comparison should be done

for all modules in use. If any differences are identified between them they must be reconciled and explained (some settings may be environment specific and therefore an expected difference). The purpose of this exercise is to minimise the risk that steps carried out previously have not be repeated.

5 User Acceptance Testing

Once a full end-to-end upgrade process has been successfully carried out without error or interruption and all post-upgrade steps and additional configuration has been completed and successfully system tested the environment can be handed over for User Acceptance Testing (UAT). This allows the business community to ensure the upgraded system fully supports the business requirements.

Prior to the start of the formal acceptance testing it is recommended that a ConfigSnapshot baseline is created to ensure any changes made during the testing can be controlled effectively.

Any changes made to configuration during the User Acceptance process these must be captured. Changes should be made and first tested in the main control environment being used by the Upgrade Team. Where necessary details of the change should be added to the Upgrade Log and

amendments/additions made to Configuration Sets. This ensures that changes will be repeated during the Dress Rehearsal and Production upgrades. Once changes have been tested in the main control environment they can then be replicated in the User Acceptance environment for sign off.


At the end of User Acceptance comparisons between the current environment setup and the pre-test baseline will ensure that if any configuration changes have been made they are highlighted and can be cross-referenced to the Upgrade Log and Configuration Sets to ensure they have been

correctly included.

A common cause of issues during User Acceptance is where an unexpected change occurs to the setup, perhaps by one of the users carrying out testing, that subsequently causes issues. By having a pre-test baseline, unplanned changes can be identified very quickly whereas without a baseline

they can cause significant delay while they are being investigated.

6 Dress Rehearsal Upgrade

By the end of successful User Acceptance Testing the full end-to-end process should be fully documented. At this stage it is recommended that a full dress rehearsal of the upgrade be carried out. This should mirror the Production upgrade as much as is possible. It is essential that the Dress Rehearsal is carried out on a fresh clone of Production to ensure that there is as little difference between this data and the data at the time of the Production upgrade. This minimises the risk of issues caused by data created in the time between the Dress Rehearsal and the Production upgrades.

The purpose of this iteration is to confirm that the full end-to-end process runs efficiently, without error and to confirm the timings mean the Production upgrade can be carried out within the acceptable business downtime window for the organisation.

Prior to starting the Dress Rehearsal Upgrade, generate the latest version of the configuration change documentation. The recommended method for preparing these documents is by running comparison reports for each Configuration Set between the current data in the control environment

and the post-upgrade baseline. This should identify all the changes (additions, changes and deletions) for each step in the Configuration Set made after the main upgrade process completes.

As a control step, general module comparisons can be carried out for all setup steps for each module between the current environment setup and the post-upgrade baseline. This should highlight any situations where a difference exists but the step has not been included in one of the

Configuration Sets. Although this should not be the case as long as the Upgrade Team has been diligent in maintaining the sets and the Upgrade Log, this additional checking further minimises the risk that any changes have been left out.

Once the Dress Rehearsal Upgrade has been completed use ConfigSnapshot comparison reports for each module to confirm the setup is consistent with the signed off User Acceptance Testing environment. Any differences highlighted should be for clearly understood reasons.

7 Production Upgrade

After a successful Dress Rehearsal Upgrade the Production Upgrade can be performed. This should be done as soon after the Dress Rehearsal Upgrade as possible to ensure that as few variables as possible change between the two iterations. The Production Upgrade must be carefully planned (including back out plans in the event of failure) and should closely follow the process used during the Dress Rehearsal Upgrade.

ConfigSnapshot can be used to compare the end point of the Production Upgrade with the User Acceptance Testing environment as a final check that all steps have been completed as planned. This can significantly reduce the likelihood of issues once users are allowed on the upgraded

system. Where possible this should be completed prior to allowing users on to the upgraded system.


8 Appendix 1: Determining Setup at Risk

Part of the Upgrade Assessment is to consider any existing setup that may be at risk of modification during the upgrade process. For a full description of the types of data at risk see Upgrade Assessment. Two of the categories of data that may be affected by the upgrade are where implementation setup has been added to seeded data or where Oracle defines one or more standards for the setup and these have not been followed during the implementation.

The areas that fall into these categories can vary, so this document does not exhaustively list all areas that might be affected; the Upgrade Team should review their modules to determine which steps require checking.

System Administration

o Menus

o Request Groups

o Responsibilities

o Request Sets

Application Developer

o Applications

Alerts

o Alerts


9 Appendix 2: Customisation Areas

9.1 Overview

Part of the Upgrade Assessment is to determine areas of customisation within the existing applications to assess the impact of the upgrade.

ConfigSnapshot can assist in identifying a wide variety of customisations to significantly simply this process. In many cases a full list of customisations can be reported. In a few cases it is not possible to directly distinguish customisations from standard data; however, in these cases it is often possible to use ConfigSnapshot reporting to filter the data to produce a much more targeted list of potential customisations that can be quickly reviewed to identify which are actual customisations.

Customisations should be completed based on the standards defined by Oracle. However, there is no guarantee that all standards have been followed on any specific implementation. Therefore, it is not possible to exhaustively list all customisation types; however, this section give details of the majority of common areas and provides details of how ConfigSnapshot reports can target each of these areas. The Upgrade Team should review this list and consider whether any further areas should be investigated.

Some of the areas highlighted here will be relevant to all implementations. Others are specific to the modules implemented and only need to be run if applicable.

Reports do not need to be run individually or by module. Review the steps that are relevant to the implementation (and any additional steps not specified in this section that the Upgrade Team would like to include in the analysis) and create one or more Configuration Sets to simplify the reporting process.

9.2 System Administration

9.2.1 Concurrent Programs

The following settings provide a summary matrix of all custom concurrent programs.

Run Options

o Show Seeded Data checked OFF

o Show SYSADMIN Data checked OFF

o Show ANONYMOUS Data checked OFF

o Show History Info checked ON

Filters


The following settings provide a summary matrix of all concurrent programs created by SYSADMIN. Many of these may be seeded programs but some may be custom programs where the user was logged on as SYSADMIN. These should be reviewed to determine whether any of the returned records are custom.

Run Options

o Created / Updated by Specific User(s) checked ON


o Choose SYSADMIN from list of available users

Filters


9.2.2 Concurrent Program Parameters

The following settings provide details of all custom concurrent programs that include at least one parameter with a default value derived from a SQL statement:


Run Options

o Show Seeded Data checked OFF

o Show SYSADMIN Data checked OFF

o Show ANONYMOUS Data checked OFF


Filters

o Has Parameter With SQL Default = Yes

Documents

ConfigSnapshot Guide - Upgrades