Development Guidelines for 11i Upgrade

DEVELOPMENT GUIDELINES

Oracle 11i Upgrade Project

Author: Amin JiwaniCreation Date: February 13, 2004Last Updated: May 19, 2011Control Number: Development_Guidelines_for_11i_Upgrade.doc Version: 1.0

Approvals:

hoople.dawn, 01/03/-1,

This is the name of the user(s) driving this requirement

Document Control

Change Record

Date Author Version Change ReferencePa

02/13/04 Jiwani.Amin 1.0 Initial Creation

Reviewers

Name Position

Greg KierAnalissa HiltBarry HawkinsPam Schoeb

Distribution

Copy No. Name Location

1 Level 3/SSI 11i Upgrade Project team Broomfield, Dallas, Europe2 WIPRO Project Team Broomfield and off-shore34

Development GuidelinesOpen and Closed Issues ii

Company Confidential - For internal use only

Contents

Document Control...............................................................................................ii

Source Code Version Control – Use of ClearCase.........................................1Identify Custom Objects to be Upgraded................................................1Identify ClearCase file for Custom Objects.............................................2ClearCase Check In/Check Out Procedures.............................................3Benefits of separating 11i folder in ClearCase.......................................8

Coding Standards for Upgrading Custom Objects......................................10

Migrating Upgraded Custom Objects..........................................................11

Open and Closed Issues......................................................................................12

Development GuidelinesOpen and Closed Issues iii


Source Code Version Control – Use of ClearCase

This section describes how and when ClearCase should be used by all developers (Level 3/SSI and WIPRO) during upgrade of Level 3 custom objects for Oracle Applications Release 11i (11.5.9). The term “Level 3 Custom Object” as used in this document refers to (but not limited to) one of the following. These are the type of objects that Level 3 developers and/or consultants have created or modified in order to support the business requirements in an Oracle Applications Release 11.0.3 environment:

Oracle Reports 2.5

Oracle Forms 4.5 (including CUSTOM.pll)

Oracle Workflows (including Account Generators)

PL/SQL procedures and functions

PL/SQL packages (including the ones written using PL/SQL Web Toolkit)

Database tables and views

Database indices

Database triggers

SQL*Loader scripts

SQL*Plus scripts

Host Scripts

Please note that development guideline (or upgrade approach) discussed in this document does not apply to Discoverer reports and custom Oracle Alerts, which will be upgraded using a different methodology.

Identify Custom Objects to be Upgraded

The following guideline will be used to determine whether a custom object needs to be upgraded (or not) in order to function as desired in Oracle Applications Release 11i environment. If the custom object meets one or more of the following criteria, then the object will need to be upgraded for 11i.

All Custom Oracle Reports (2.5)

All Custom Oracle Forms (4.5)

CUSTOM.pll

Custom Oracle Workflows (including Account Generators)

Development GuidelinesOpen and Closed Issues 1


Any custom database object (views, triggers, procedures, functions, packages) that is found to be INVALID after the database instance has been upgraded to 11i and after objects have been re-compiled during post-upgrade.

Any custom object (including DB objects, SQL*Loader Scripts, SQL*Plus scripts, Host Scripts) that gets migrated successfully during the upgrade, but does not meet the business requirement in the 11i environment (due to data model or application logic changes in 11i)

Please note that custom objects that fall in the last category (mentioned above) will be identified during unit and/or user testing.

Identify ClearCase file for Custom Objects

Once its determined that a custom object needs to be upgraded, the relevant code (that created the custom object) can be found in ClearCase using one or more of the following steps. These instructions work fine for most of the custom objects, but there could be exceptions (e.g. object exists only in production database but not in ClearCase), which will need to be dealt on a case-by-case basis:

1. Identify the module (or custom application) short name – This is usually the 3rd and 4th character in the custom object name. For example, the custom object l3ar_ssi_trx pertains to the Oracle Receivables (AR) module. Please note that there are some Oracle Packages that include APIs, which are supposed to be customized by the client and thus, the custom object in such cases will not have a name starting with “L3”. In this case the first two characters of the custom object make up the module short name (e.g. PA_CLIENT_EXTN_PTE object pertains to Oracle Projects or PA module). Please note that there could be a couple of exceptions to these object naming standards. For example, the custom object utx_ap_invoices_v is a Use Tax Link object and pertains to the AP module.

2. Typically the ClearCase file name itself contains the object name string in which case, you can easily search the relevant ClearCase folders through Windows Explorer to find the source code file name. Based on the module name identified in step 1, you can search the corresponding “l3” module folder in Clearcase for filenames that include the custom object name. For example, the custom object L3GL_JOURNAL_VAL_PKG, can be found in ClearCase by searching for file names like “* L3GL_JOURNAL_VAL*” under corp_sys_apps/oracle_apps/l3gl ClearCase folder. If the ClearCase file name cannot still be determined by this method, then perform steps 3 and/or 4 as necessary to identify the source code file name in ClearCase.

3. Once you identify the module name as instructed in step 1, you can execute the following UNIX command on the server, which provides access to ClearCase VOB for Oracle Applications, e.g. steamboat. This UNIX command will look for the occurrence of custom object name in files under the current directory and all sub directories. All files that contain the string will have their path printed to standard output. You will need to set your default directory to /view/READY_FOR_RELEASE/vob/corp_sys_apps/oracle_apps/<mod>



where <mod> is the Level 3 module short name of the custom object e.g. l3ar . $ find . -exec grep –i "<custom object name>" '{}' \; -print The output of this command will help determine the ClearCase file name that defines or creates the custom object.

4. If the custom object source code file name cannot be derived from step 2 mentioned above, then you might need to execute the UNIX find command from the oracle_apps directory, which is one level above the module directory. This will help find the ClearCase file in case the custom object module name is inconsistent with the ClearCase folder name for that module. For example, if an L3AP object is stored in L3PO Clearcase folder.

ClearCase Check In/Check Out Procedures

Once you have identified the custom object that needs to be upgraded and also the ClearCase location of source code (11.0.3 version) file name, the following ClearCase procedures will need to be followed. The custom object L3AR_SSI_TRX package body is being used for illustration purposes:

1. Check if the 11i ClearCase folder already contains the custom object source code

This can be done by performing a ClearCase Update on the appropriate 11i ClearCase folder (corp_sys_apps\oracle11I). In this example, a ClearCase Update is being done on corp_sys_apps\oracle11I\l3ar\1.0.0\admin\sql folder.

If the custom object source code file already exists in 11i ClearCase, then skip the following steps and instead make sure that no one else has checked out or reserved this file from 11i ClearCase folder. If this file is not reserved or checked out, then check out the file from 11i ClearCase folder, make the necessary code changes, compile and/or unit test the code changes in a development environment (e.g. UPGDEV), and then finally check in the modified source code file into the 11i ClearCase folder. If the custom



object source code file does not exist in 11i ClearCase, then continue with the following steps.

2. Perform Update on the 11.0.3 ClearCase folder that contains the source code file

3. Make sure that the source code file is not reserved or checked out by someone else

If the “Check Out…” option does not show up on the ClearCase drop down menu (as illustrated in the picture below), then coordinate with the developer who has the file checked out or reserved before proceeding with any changes to the source code file. If the file is not checked out or reserved, then continue with step 4.



4. Use the 11.0.3 version of source code file to create the initial version in 11i ClearCase and check out the file for code changes

Copy the file from 11.0.3 ClearCase folder (in this example copy the file oracle_apps\l3ar\1.0.0\admin\sql\l3ar_ssi_trx.pkb) and paste it in the corresponding 11i ClearCase folder (in this example oracle11I\l3ar\1.0.0\admin\sql folder). Then right mouse click on the file in the 11i ClearCase folder to invoke the ClearCase drop down menu and add the file to ClearCase source control as shown in the following picture.

When adding the file to 11i ClearCase, you can also choose to check out (or reserve) the file for code changes. Please also make sure that you enter relevant comments when you add the file to source control (or when you check out and check in the files) as shown in the following picture:



5. Make the required code changes to the checked out file

Once you have checked out the source code file from 11i ClearCase, copy the file to any other non-ClearCase folder (e.g. working directory on your C: drive). Make the necessary code changes, compile and/or unit test the code changes in a development environment (e.g. UPGDEV), and then copy the modified source code file back to 11i ClearCase folder where it was checked out from.

6. Check in the modified source code file to 11i ClearCase with check in comments

5. Mark the modified source code file as “READY_FOR_RELEASE”

This step is a pre-requisite if you intend to migrate the modified code from one instance to another using Kintana Workbench. You can use ClearCase Home Base icon on your desktop or select “ClearCase Home Base” from ClearCase Program Group to start the “Apply Label” process. The following screenshots illustrate this process.



Select the appropriate file from 11i ClearCase folders displayed in the left column and then click on the “Add >>” button to include that file in the “Elements to apply label to:” column. Click “Next” to continue.



Select READY_FOR_RELEASE label by clicking on the “Browse” button and select the radio buttons in the Options section as shown in the following picture. Then click the “Finish” button.



Benefits of separating 11i folder in ClearCase

Creating a separate ClearCase folder for 11i and adding the 11.0.3 version of source code as the first element in 11i ClearCase (as described in the above mentioned sections) offers the following benefits.

1. We can easily identify all the custom objects that had to be modified for 11i Upgrade, since these will exist in a separate ClearCase folder. Please note that this will be a much smaller set compared to the custom objects that exist in Oracle Apps (11.0.3) ClearCase, since we will only be upgrading (reworking) those custom objects that meet the criteria mentioned in the “Identify Custom Objects to be Upgraded” section in this document. Custom objects that do not meet such criteria should not be modified for 11i Upgrade and thus will not exist in 11i ClearCase folders.

2. This approach also makes it easier to concurrently modify custom objects for 11.0.3 (if required) to address any 11.0.3 production issues or mission critical requirement until we go live on 11i. Such occurrences however should be genuine exceptions.

3. Using 11.0.3 version of source code to create the first element in 11i ClearCase also gives us the ability to use ClearCase’s graphical file differencing utility to compare the 11i version with 11.0.3 version of the custom code changes and easily identify the code changes made for 11i Upgrade. This is a highly recommended ClearCase feature that developers working on 11i Upgrade should make use of, because this will not only help the onsite team with debugging issues (if encountered during testing the custom code), but also will serve as a QA tool for off-shore developers who may make code changes to compile the code but may not be involved in unit testing.





Coding Standards for Upgrading Custom Objects

Most (if not all) of the development work required on the 11i Upgrade Project involves modifying existing custom code. Thus, the coding standards are not required to be as elaborate as they would be on a traditional development projects. However, at a minimum, the following standards should be adhered to on the 11i Upgrade Project:

1. Do not delete the original lines of 11.0.3. code that needs to be modified for 11i. Instead, comment out the 11.0.3 code that is being replaced by the new code for 11i.

2. Include your Name, Company Name and the Date when you modified the program unit.

3. Include a brief description that explains the reason for modifying the code. The keyword “11i” should also be included in the text, so that custom database objects that were modified for 11i could be easily searched by querying the Oracle data dictionary tables.

The above-mentioned coding standards are appropriate (and required) when upgrading any of the following custom objects:

Oracle Reports 2.5 (Include Comments in Report Triggers and Program Units)

Oracle Forms 4.5 (including CUSTOM.pll)

Oracle Workflows (Include comments in Item Type Description)

PL/SQL procedures and functions

PL/SQL packages (including the ones written using PL/SQL Web Toolkit)

Database table and view DDL scripts

Database indices DDL scripts

Database triggers

SQL*Loader scripts

SQL*Plus scripts

Host Scripts

While upgrading Oracle Forms and Oracle Reports, if major changes have to be made to the form or report layout, please include comments in Module Property section of the form or report.



Migrating Upgraded Custom Objects

Once the custom objects have been upgraded, checked into 11i ClearCase and marked as READY_FOR_RELEASE, these objects will be eligible for migration into test and production instances through Kintana. All custom objects (with the exception of Oracle Alerts, Oracle Workflow/Account Generators and Discoverer) should always be migrated through Kintana workbench into test and production instances. (Please contact Lucy Feng for Kintana migration procedures)

For development instances (like UPGDEV), the upgraded custom objects will need to be migrated manually (compiled or copied into appropriate application top directories on appropriate servers) .



Open and Closed Issues

Issue # Description Resolution Date Added Date Closed Owner



Documents

Development Guidelines for 11i Upgrade