F Upgrading the Oracle BI Repository for Industry-Specific Analytics Applications

This appendix contains instructions for upgrading the Oracle BI repository for Pharma Analytics, Consumer Sector, and Vehicle Sales.

In Oracle BI Applications release 7.9.4, the Pharma Analytics business model and Core business model were merged. In Oracle BI Applications release 7.9.5, the Consumer Sector and Vehicle Sales Analytics business models and Core business model were merged. Because of this merge, the process of upgrading the Oracle BI repository has some steps that differ from the standard Oracle BI repository upgrade process.

This section includes the following topics:

Section F.1, "Common Dimensions"
Section F.2, "Merging Siebel Analytics and Oracle BI Repositories"
Section F.3, "Replacing Common Dimensions After the Repository Merge"

F.1 Common Dimensions

Table F-1, Table F-2, and Table F-3 list the common dimensions of Pharma, Consumer Sector, and Vehicle Sales Analytics and their statuses. Some of the dimensions are not shared with other Core modules because of specific requirements.

Table F-1 Common Pharma Analytics Dimensions

Dimensions in Pre-7.9.4 Releases	Dimensions in Release 7.9.4	Status	Comments
Dim - Accounts	Dim - Customer	Shared	None
Dim - Contacts	Dim - Contact	Shared	New name is singular
Dim - Security Dimension	Dim - Position Security	Shared	None
Dim - Time Period	Dim - Date	Shared	None
Dim - Geography	Dim - Pharma Geography	Not shared	Use Pharma-specific dimension in Core
Dim - Geography_Account	Dim - Pharma Geography_Account	Not shared	Use Pharma-specific dimension in Core
Dim - Geography_Contact	Dim - Pharma Geography_Contact	Not shared	Use Pharma-specific dimension in Core
Dim - Products	Dim - Pharma Products	Not shared	Use Pharma-specific dimension in Core

Table F-2 Common Consumer Sector Analytics Dimensions

Dimensions in Pre-7.9.5 Releases	Dimensions in Release 7.9.5	Status	Comments
Dim - Account Geography	Dim - Account Geography	Shared	None
Dim - Accounts	Dim - Customer	Shared	None
Dim - Accounts Hierarchy	Dim - Accounts Hierarchy	Shared	None
Dim - Employees	Dim - Employees	Shared	None
Dim - End Date	Dim - End Date	Shared	None
Dim - Position Hierarchies	Dim - Position	Shared	Dim - Position in 7.9.5 combines both Position and Position Hierarchy
Dim - Positions	Dim - Position	Shared	Dim - Position in 7.9.5 combines both Position and Position Hierarchy
Dim - Product Categories Hierarchy	Dim - CS Product Category Hierarchy	Not shared	Use CS-specific dimension in Core
Dim - Products	Dim - CS Product	Not shared	Use CS-specific dimension in Core
Dim - Start Date/Date	Dim - Start Date	Shared	None

Table F-3 Common Vehicle Sales Analytics Dimensions

Dimensions in Pre-7.9.5 Releases	Dimensions in Release 7.9.5	Status	Comments
Dim - Accounts	Dim - Customer	Shared	None
Dim - Accounts Geography	Dim - Account Geography	Shared	None
Dim - Contacts Geography	Dim - Person Geography	Shared	None
Dim - Date	Dim - Date	Shared	None
Dim - Households	Dim - Households	Shared	None
Dim - Individuals	Dim - Contact	Shared	None
Dim - Lease/Loan Expiry	Dim - End Date	Shared	None
Dim - Product Hierarchy	Dim - Product Hierarchy	Shared	None
Dim - Products	Dim - Product	Shared	None
Dim - Vehicle	Dim - Asset	Shared	None

F.2 Merging Siebel Analytics and Oracle BI Repositories

The Pharma, Consumer Sector, and Vehicle Sales Analytics upgrade process involves merging customizations of prior releases of the Siebel Analytics or Oracle BI repositories into the current version of the Oracle BI repository. This process follows the same principle as the Core upgrade process but includes some additional steps.

In this section, the upgrade process for Pharma Analytics from pre-7.9.4 releases to release 7.9.4 and higher will be used as an example. The upgrade process for Consumer Sector and Vehicle Sales Analytics from pre-7.9.5 releases to release 7.9.5 and higher are the same as that for the upgrade to Pharma Analytics release 7.9.4 and higher.

As shown in Figure F-1, there are two phases to the Pharma Analytics upgrade process.

Figure F-1 Phases of Repository Merge for Pharma Analytics

This illustration is described in the surrounding text.

Phase 1

As shown in Figure F-1, there are two phases in the Pharma Analytics upgrade process. Phase 1 involves merging the 7.x original Core base repository (the repository that shipped with the release of Siebel Analytics or Oracle BI you are currently running), the 7.x custom Core repository, and the new base repository into one output repository.

Phase 2

Phase 2 involves merging the output repository of Phase 1 with the 7.x original Pharma Analytics base repository and the 7.x custom Pharma Analytics repository. The output repository of Phase 2 is a merged Pharma and Core repository that includes your customizations from prior releases and the new data model.

Note:

You need to perform both phases of the upgrade process if your current, customized repository has both Core and Pharma models and the Core model is customized.

If your current, customized repository does not include the Core model or includes the Core model but the Core model is not customized, you only need to perform Phase 2.

If you only perform Phase 2, then you will not have a new Core merged RPD (as shown in Figure F-1). Instead, you will use the new base RPD in place of the new Core merged RPD.

See Table F-4 and Table F-5 for a description of the different RPD file names.

The tasks in this section refer to multiple versions of the Siebel Analytics or Oracle BI repository. Table F-4 provides the names and descriptions of the repositories used in Phase 1. Table F-5 provides the names and descriptions of the repositories used in Phase 2.

Table F-4 Phase 1 Repository Files

Repository File	Description
7x_original_Core_base.rpd	The trimmed, original (standard) repository for the version you are upgrading from.
7x_custom_Core.rpd	The trimmed, custom 7.x repository that includes the Core model customizations.
New_base.rpd	The trimmed, new repository that includes related Core and Pharma modules in one Core model (logical folder).

Table F-5 Phase 2 Repository Files

Repository File	Description
New_Core_merged.rpd	The output repository from Phase 1. If you do not perform Phase 1, then use the new base RPD in place of the new Core merged RPD.
7x_original_Pharma_base.rpd	The trimmed, original 7.x repository that includes the Pharma model, which was not customized.
7x_custom_Pharma.rpd	The trimmed, customized repository that includes a customized Pharma model.
New_Core_Pharma_merged.rpd	The final, merged new repository that includes a single Core model (logical folder), including all the customized content.

F.2.1 Creating Working Folders

You will use the working folders to hold the repository files after the different stages of the merge process.

Create a folder for the merge process, such as \OracleBIPharmaUpgrade, and then create the following subfolders:

Original
AfterTrimDown
AfterEqualize
AfterMerge
AfterManualWork
AfterRegressions

F.2.2 Trimming Repository Files

Trimming the repositories so that you upgrade only the content that is in use can narrow the upgrade scope and eliminate unnecessary complexities during the merge process.

You can trim down repository files by extracting projects or manually trimming down repository objects.

Note:

The Security Group property controls the presentation catalogs that will be extracted. If a presentation catalog is added to a project for extract but none of the groups in the project has visibility to see the catalog, it will not show up in the extracted repository file.

F.2.2.1 Trimming the Original Base Repository Files

You should trim the original base repository file to meet your business requirements.

To trim the original base repository files

If you are performing Phase 1 of the upgrade process, trim the original Core base repository file.
Save the file as 7x_original_Core_base.rpd (where 7x represents the release of Siebel Analytics or Oracle BI) in the AfterTrimDown subfolder.
Trim the original Pharma base repository file.
Save the file as 7x_original_Pharma _base.rpd in the AfterTrimDown subfolder.

F.2.2.2 Trimming the New Base Repository File

The new base repository file that you received with the current Oracle BI Applications release, contains one Core model (logical folder), which holds Pharma and Core repository objects.

To trim the new base repository file

Trim the new base repository file.
Save the file as New_base.rpd in the AfterTrimDown subfolder.

F.2.2.3 Trimming the Custom Repository Files

If you are performing Phase 1 of the upgrade process, you will have a 7x custom Core repository file (7x_custom_core.rpd) that contains the 7x original Core base contents and your customizations.

You will also have a 7x custom Pharma repository file (7x_custom_Pharma.rpd) that contains the 7x original Pharma base contents and your customizations.

Save these files in the AfterTrimDown subfolder.

F.2.3 Renaming Objects in the Original Pharma Base Repository File

In the 7x original Pharma base repository file and the 7x custom Pharma repository file, you need to rename some repository objects to be compatible with the new data model.

To rename objects in the Pharma repository files

In the Server Administration Tool, open the 7x _original_Pharma_base.rpd file.
In the Business Model and Mapping layer, rename Business Model Pharma to Core.
In the Physical layer, do the following:
1. Rename Database Pharma Data Warehouse to Oracle Data Warehouse.
2. Make sure the Connection Pool is named as Oracle Data Warehouse Connection Pool.
3. Make sure the Catalog entry (below the Connection Pool entry) is named as Catalog.
4. Make sure the Schema entry (below the Catalog entry) is named as dbo.
Repeat Steps 1 through 3 using the 7x_custom_Pharma.rpd file.

F.2.4 Equalizing the Oracle BI Repositories

The equalization process in the standard Oracle BI repository upgrade uses the original base repository from a previous release as a starting point. This type of equalization is referred to as "backward" equalization. The Pharma upgrade uses what is called "forward" equalization, in which you use the repository file from the current release as a starting point and equalize the 7x base repository file and the 7x custom repository file to it.

You will first need to prepare the MAP file for "forward" equalization before you execute the equalization.

Table F-6 provides a list of the available MAP files and the Siebel Analytics or Oracle BI Applications release version associated with the file.

Table F-6 Rename MAP Files to Be Used for Various Releases

Siebel Analytics / Oracle Business Intelligence Applications Release Version (Upgrading from DW Version)	Rename MAP File to Be Used
Siebel Business Analytics Applications 7.0.x	Not available
Siebel Business Analytics Applications 7.5.x	Not available
Siebel Business Analytics Applications 7.7.x (with Siebel CRM OLTP Pre-7.7.0)	Rename77-7963.map
Siebel Business Analytics Applications 7.7.x (with Siebel CRM OLTP 7.7.0)	Rename771-7963.map
Siebel Business Analytics Applications 7.8.2 and all 7.8.x versions before this release	Rename782-7963.map
Siebel Business Analytics Applications 7.8.3 and all 7.8.x versions after this release	Rename783-7963.map
Oracle BI Applications 7.9.0	Rename79x-7963.map
Oracle BI Applications 7.9.1	Rename79x-7963.map
Oracle BI Applications 7.9.2	Rename79x-7963.map
Oracle BI Applications 7.9.3	Rename793to7963.map
Oracle BI Applications 7.9.4	Rename794to7963.map
Oracle BI Applications 7.9.5	Rename79x-7963.map
Oracle BI Applications 7.9.5.1	Rename7951to7963.map
Oracle BI Applications 7.9.5.2	Rename7951to7963.map
Oracle BI Applications 7.9.6	Rename79x-7963.map
Oracle BI Applications 7.9.6.2	Not available

To prepare the MAP file for "forward" equalization

Copy the appropriate MAP file from the \OracleBI\Upgrade folder into the folder where you will execute equalizerpds.exe.

Note:
The naming convention of the MAP files is rename<release from which you are upgrading>-<release to which you are upgrading>.map.
For example if you are upgrading from release 7.8.4 to release 7.9.5, you should use the file rename784_795.map.
Open the MAP file in Excel.
In the Text Import Wizard, accept the default in the Step 1 dialog by clicking Next.
In the Step 2 dialog of the Text Import Wizard, do the following:
1. Make sure the Tab check box is selected in the Delimiters region.
2. In the Text qualifier list, select None.
3. Click Next.
In the Step 3 dialog, click Finish.

The file opens in an Excel spreadsheet window and contains three columns.
Switch the order of the second and third columns by cutting the third column and inserting it as the second column.
Save the file.
Check to make sure the string format is correct.

To equalize the repository files

Run equalizerpds.exe.

An example of the equalizerpds command is as follows:

equalizerpds -A Administrator -B SADMIN
-C \OracleBIPharmaUpgrade\AfterTrimDown\New_base.rpd
-D Administrator -E SADMIN
-F \OracleBIPharmaUpgrade\AfterTrimDown\7x_custom_Pharma.rpd
-O \OracleBIPharmaUpgrade\AfterEqualize\7x_custom_Pharma.rpd
-X -J rename784-795.map

If the equalizerpds.exe executable file runs correctly, no errors are returned.

Repeat Step 1 to equalize each of the files in AfterTrimDown to New_base.rpd.
To verify the process completed successfully, compare the size of the repositories. The output repository (-O) should be close to the same size as the repository you equalized (-F).

F.2.5 Merging the Core Repository Files

Note:

You need to perform this procedure if your customized repository has both Core and Pharma models and the Core model is customized. If the customized repository does not include the Core model or includes the Core model but the Core model is not customized, you do not need to perform this step.

This step involves a three-way merge on the Core repository. For a description of the files that will be merged in this procedure, see Section F.2, "Merging Siebel Analytics and Oracle BI Repositories."

To merge the core repository files

Copy 7x_original_Core_base.rpd, 7x_custom_Core.rpd, and New_base.rpd to the AfterMerge folder.
In the Server Administration Tool, open the New_base.rpd file.
From the Administration Tool menu bar, select File, then select Merge.
In the Select Original Repository dialog, select 7x_original_Core_base.
Enter the password, and click OK.
Click Select for the Modified Repository field.
In the Select Modified Repository dialog, select 7x_custom_Core.rpd.
Click Open, type the password, and then click OK.
In the Decision list, select the action you want to take regarding the repository change, or accept the default action.

For information about making decisions, see Section F.2.7, "Making Merge Decisions in the Administration Tool."
To locate subsequent rows with empty Decision fields, click the Decision header cell.

When all rows have a value in the Decision field, the Merge button is enabled.
Click Merge.

This process can take up to 40 minutes, depending on the size of the repositories you are working with. A message will alert you when the merge is complete.
Click Yes when asked if you want to run a consistency check.

The number of errors returned by the consistency check is an indication of how successful the merge process was. If you receive many errors, for example, over 300 you should analyze the reason for the errors. If the merge process failed to recognize that two objects are the same, you may need to edit the rename file or add your own rename file if you have renamed many of the objects and the upgrade engine failed to relate them to the original objects.

You also may need to change the actions you selected in the Decision drop-down list before rerunning the merge. This could save you time by reducing the number of errors that you will need to fix manually.

Once you are satisfied with the results of the merge, you should fix the remaining errors manually. It is important that you fix all errors before moving on to the next step. This repository serves as the input for the next stage.

You should also check that all of your customized objects are present and that no duplicate physical tables were introduced. To check for duplicate tables, search for physical tables using a query such as:
```
where name like '*#1'
```
Save the merged repository as New_Core_merged.rpd.

F.2.6 Merging the Pharma Repository Files

This step involves a three-way merge on the Pharma repository. For a description of the files that will be merged in this procedure, see Section F.2, "Merging Siebel Analytics and Oracle BI Repositories."

Note:

If you did not perform Phase 1 of the upgrade process you will not have a New_Core_merged.rpd file. In place of the New_Core_merged.rpd file, you should use the New_new_base.rpd file.

To merge the Pharma repository files

Copy New_Core_merged.rpd, 7x_original_Pharma_base.rpd, and 7x_custom_Pharma.rpd to the AfterMerge folder.
In the Server Administration Tool, open the New_Core_merged.rpd file.
From the Administration Tool menu bar, select File, then select Merge.
In the Select Original Repository dialog, select 7x_original_Pharma_base.
Enter the password, and click OK.
Click Select for the Modified Repository field.
In the Select Modified Repository dialog, select 7x_custom_Pharma.rpd.
Click Open, type the password, and then click OK.
In the Decision list, select the action you want to take regarding the repository change, or accept the default action.

For information about making decisions, see Section F.2.7, "Making Merge Decisions in the Administration Tool."
To locate subsequent rows with empty Decision fields, click the Decision header cell.

When all rows have a value in the Decision field, the Merge button is enabled.
Click Merge.

This process can take up to 40 minutes, depending on the size of the repositories you are working with. A message will alert you when the merge is complete.
Click Yes when asked if you want to run a consistency check.

The number of errors returned by the consistency check is an indication of how successful the merge process was. If you receive many errors, for example, over 300, you should analyze the reason for the errors. If the merge process failed to recognize that two objects are the same, you may need to edit the rename file or add your own rename file if you have renamed many of the objects and the upgrade engine failed to relate them to the original objects.

You also may need to change the actions you selected in the Decision drop-down list before rerunning the merge. This could save you time by reducing the number of errors that you will need to fix manually.

Once you are satisfied with the results of the merge, you should fix the remaining errors manually. It is important that you fix all errors before moving on to the next step. This repository serves as the input for the next stage.

You should also check that all of your customized objects are present and that no duplicate physical tables were introduced. To check for duplicate tables, search for physical tables using a query such as:
```
where name like '*#1'
```
Save the merged repository as New_Core_Pharma_merged.rpd.

F.2.7 Making Merge Decisions in the Administration Tool

When making decisions about merging repository objects in the Administration Tool, you should consider the following points:

For objects that do not appear in the new base repository, you should normally choose "current," which will incorporate the changes into the new base repository.
For objects added to the new base repository, you should normally choose "current," which will keep the changes.
For objects in the original repository that were replaced with new objects, you may see decisions for removing the old objects from the current repository and adding the new objects. Choosing "current" will replace the old objects.

For new customizations that you added to a repository, choose "modified" to keep the changes.
If an object is changed in both the customized repository and the new base repository, the description "changed in both," may appear. In such cases, choose "current" to keep the object as it is in the new base repository, or choose "modified," to keep the object as it is in the customized repository.

F.3 Replacing Common Dimensions After the Repository Merge

After the repository file merge, all preconfigured presentation dimension tables and columns should be merged properly and sourcing from the new logical dimensions in the Core model. For example, Account Name in the Account presentation table should source from "Core"."Dim - Customer"."Account Name," and Gross Margin in the Product presentation table should source from "Core"."Dim - Pharma Products"."Gross Margin."

However, customized presentation tables and columns may still source from old dimensions. Table F-7, Table F-8, and Table F-9 list the common dimensions that have new names in the new release. If you customized presentation tables or columns from the old dimensions listed in Table F-7, Table F-8, and Table F-9 you need to replace the old logical source tables or table columns with the new ones.

A way to quickly allocate these problematic presentation tables or columns would be to do the following:

In the Core logical folder in the Server Administration Tool, find the old dimension name as listed in Table F-7, Table F-8, or Table F-9, for example, "Dim - Accounts."
Right-click the old dimension name, then click Display Related, and then click Presentation Column.
Replace the presentation columns with the same columns from the new logical dimension, for example, "Dim - Customer"
To verify you replaced the presentation columns correctly, search for presentation columns on the Core logical dimension, such as "Core - Accounts". If the return is empty, then it is safe to delete the old dimension, for example, "Dim - Accounts"

The following common dimensions in 7.x need to be reviewed and removed.

Table F-7 Names for Pharma Analytics Common Dimensions in Pre-7.9.4 Releases

Name of Dimension in Pre-7.9.4 Releases	Name of Dimension in Release 7.9.4	Status	Comments
Dim - Accounts	Dim - Customer	Shared	None
Dim - Contacts	Dim - Contact	Shared	New name is singular
Dim - Time Period	Dim - Date	Shared	None

Table F-8 Names for Consumer Sector Analytics Common Dimensions in Pre-7.9.5 Releases

Name of Dimension in Pre-7.9.5 Releases	Name of Dimension in Release 7.9.5	Status	Comments
Dim - Accounts	Dim - Customer	Shared	None
Dim - Position Hierarchies	Not applicable	Shared	Merged into Dim - Position in Core
Dim - Positions	Dim - Position	Shared	Dim - Position combines both Position and Position Hierarchy
Dim - Start Date/Date	Dim - Start Date	Shared	None

Table F-9 Names for Vehicle Sales Analytics Common Dimensions in Pre-7.9.5 Releases

Name of Dimension in Pre-7.9.5 Releases	Name of Dimension in Release 7.9.5	Status	Comments
Dim - Accounts	Dim - Customer	Shared	None
Dim - Accounts Geography	Dim - Account Geography	Shared	None
Dim - Contacts Geography	Dim - Person Geography	Shared	None
Dim - Individuals	Dim - Contact	Shared	None
Dim - Lease/Loan Expiry	Dim - End Date	Shared	None
Dim - Products	Dim - Product	Shared	None
Dim - Vehicle	Dim - Asset	Shared	None