BI Applications 11g Migrating

Configurations and Customizations from

Development to a Test or a Production
Environment
This document describes how to move Oracle BI Applications 11g (version 11.1.1.8.1 and later)
configurations and customizations from one BI Applications environment to another. In this document,
the term source environment is used to refer to the BI Applications installation from which you want
to migrate the contents this is typically a development environment, and the term target
environment is used to refer to the BI Applications installation to which you want to migrate the
contents this is typically a test or a production environment.

Contents
Contents ........................................................................................................................................................ 1
1. Overview ............................................................................................................................................... 2
2. How To Create a Target BI Applications 11g Environment and Migrate Configurations and
Customizations.............................................................................................................................................. 3
2.1.

Creating a Target Test or Production Environment ...................................................................... 3

2.2.

Renumbering the Target ODI Repository...................................................................................... 4

2.3.

Migrating Customizations to the Target ODI Repository Using Export/Import............................ 5

2.4.

Migrating Customizations to the Target Business Analytics Warehouse ................................... 15

2.5

Migrating Customized Load Plan Dev Components to the Target ODI Repository. ................... 18

2.6

Migrating Customizations to the Target RPD and Presentation Catalog .................................... 22

2.7

Defining, Generating and Executing Domains Load Plan in the Target Environment ................ 24

2.8

Migrating Functional Setup Data to Configuration Manager in the Target Environment .......... 24

2.9

Defining, Generating and Executing Load Plans in the Target Environment .............................. 26

Appendix ..................................................................................................................................................... 27
A.

Things to know about ODI Smart Export and Import ..................................................................... 27

1

1. Overview
The high-level steps to create a target BI Applications environment (for example, Test or Production)
and to migrate configurations and customizations from the source environment to target (for example,
from Development to Test) are described below:
1.1. Create a test or production target environment following the BI Applications Installation Guide
for the 11g releases.
1.2. Renumber the ODI repository in your new target environment. This is a critical step and must
be performed before any updates or customizations are made to the target ODI repository.
Important: Please pick a numerical ID between 500 and 899. If you are planning to create
multiple OBIA environments, please ensure you give a different numeric ID for each ODI
repository that you create.
1.3. Export customizations from the ODI repository in source environment and import them into the
target environment.
Important: ODI customization should be done in one single ODI repository, typically your
development repository. You should not have multiple ODI repositories in which development
teams are making different changes. You can have multiple target repositories which you
import your ODI customization to. For example, you have one test environment and one
production environment. Youll first import the customization from the Development
environment into the Test environment. After testing completes in the Test environment, you
can then import the same changes from your Development environment into your Production
environment. You SHOULD NOT have cases where you have two development environments
and youre exporting changes from these two development environments into your Test or
Production environment.
1.4. Extend the Business Analytics Warehouse in the target environment to include customizations
using DDL procedure in ODI (alter DW schema using the model ODI data store).
1.5. Migrating Customized Load Plan Dev Components to the Target ODI Repository.

1.6. Migrate RPD and Presentation Catalog customizations from the source environment to the
target environment.
1.7. In Configuration Manager in the target environment, define and generate a Domains Load Plan.
Run the Domains Load Plan.

1.8. Export functional setup data from Configuration Manager in the source environment and
import them into Configuration Manager in your target environment.
1.9. Define and generate Load Plans for data loads. Execute the Load Plans.
Review Appendix A: Things to know about ODI Smart Export and Import.
Note: This Document is applicable for Oracle BI Applications 11g (11.1.1.7.1 or higher) and the
document links refers to current release of BI Applications (11.1.1.8.1).

2. How to Create a Target BI Applications 11g Environment and Migrate

Configurations and Customizations
The detailed steps to install a target BI Applications environment and to migrate configurations and
customizations from the source environment to target environment are described below.

2.1.Creating a Target Test or Production Environment

The target BI Applications 11g environment (Test or Production) is created by installing BI
Applications as described in Chapter 3 Installing and Setting Up Oracle BI Applications of the
Oracle Fusion Middleware Installation Guide for Oracle Business Intelligence Applications 11g.
a. Complete section 3.2 Installing Prerequisites for Oracle BI Applications and section 3.3
Installing and Configuring Oracle BI Applications.
b. Complete the following System Setups steps for your target environment:

4.1 Setting the Business Analytics Warehouse Connection in ODI

4.2 Performing Setup Steps for On-Premise Fusion Applications Sources
4.3 Registering Source Systems and Propagating Connection Details to ODI
NOTE: When registering the Source Systems in BI Applications Configuration
Manager in your target environment, you must enter the same Data Source
Number (DSN) as was entered for the same transactional source registered in
Configuration Manager in your source environment. Migration of functional setup
data between source and target environments will fail if the DSNs do not match.

4.4 Enabling Offerings for Deployment

4.5 Setting Languages for Data Load into the Business Analytics Warehouse
4.9 Editing Preferred Currency Display Names and Enabling Document Currency

NOTE: At this time, do not complete any part of the step 4.6 Running the Domains Load Plan.
3

2.2.Renumbering the Target ODI Repository

It is important that you renumber the ODI repository ID right after the repository has been created.
You must use a numeric ID between 500 and 899.
If you are planning to create multiple OBIA environments, for example, one Test environment and
one Production environment please ensure that you use a different numeric ID for each repository
that you create. For example, the repository ID for your Test environment can be 510, and the
repository ID for your Production environment can be 550. If you have two Test environments, one
can have repository ID of 510 while the other can have repository ID of 520.
Please follow the instructions in Renumbering Repositories section of Oracle Fusion
Middleware Developer's Guide for Oracle Data Integrator to renumber the repository ID.
Please make sure you renumber the master repository first and then the work repository, and
not the other way around.
After renumbering the repository, the ODI J2EE agent, oraclediagent needs to be restarted.
For this, login to WLS Admin Console (E.g. http://host:7001/console). Click on Deployments from
the Domain structure tree and navigate to oraclediagent. Select the checkbox beside it and
select Stop -> Force Stop Now option from the top.

Navigate again to oraclediagent, check the box and select Start -> Servicing all requests to
restart.

2.3.Migrating Customizations to the Target ODI Repository Using

Export/Import
Use the ODI smart export/import feature to export any customizations done to ODI objects (models,
interfaces etc) from ODI repository in the source environment and import into target environment. This
section will explain how to do this export and import by taking an example scenario.
Before you begin:
Please read the Appendix A at the end of the document to understand a few things about the ODI smart
export/import feature, before you do the migration.
It is recommended to take the following backups before doing the migration.
ODI Repository: Backup the target ODI repository by taking a database dump of the ODI repository
schema using Oracle Database export utility.

Security Backup: Similarly, you may backup just the security metadata from the target ODI repository.
To do this, invoke the security export dialog as shown below

Example scenario:
Let us assume the following changes have taken place in the source repository which now needs to be
migrated to the target:

There is a new column WC_TEST in an existing data store W_ABSENCE_EVENT_D

A new custom data store WC_TEST_D

There is a custom change to an out of the box interface by making a copy of the folder

Perform the Migration:

The following steps explain how to export from the source repository and import into the target repository.
2.3.1. On Target Environment: The first step is to export the topology information from the ODI
Repository in the target environment for a backup. This will be used later to restore the topology settings
after the customizations are imported into target. To do this, login to the target ODI repository from ODI
studio. Export the Global context using Smart Export from Topology navigator, as shown in the
series of screenshots below

Select Export and then Smart Export:

Drag Global context into Smart Export window:

Click Next to review the export. Enter a filename to store the export and complete export:

2.3.2. On Source Environment: Now, login to the ODI repository in the source environment from ODI
Studio. Export the customized objects using Smart Export by clicking on the icon on the top right of
the Designer tab and choosing Export as shown. Then choose Smart Export in the dialog that
pops up.

10

2.3.3. Drag and drop in artifacts that have been changed and need to be Smart Exported.
In our example, the interfaces under custom folder SDE_ORA_JobDimension has changed, so drag and
drop the entire task folder into the Smart Export window. Similarly, drag and drop the customized
table/data store, Absence Event Dimension (W_ABSENCE_EVENT_D) and the new table/data store,
WC_TEST_D

11

When you drag the objects into the Smart Export, the dependent objects are computed and automatically
dragged in as well. For example, when task folders containing interfaces are dragged in, the data stores
corresponding to the interfaces are automatically dragged in. Thus, if you have changed an interface and
the corresponding target data store, it is enough to drag the interface/task folder and the data store will
be automatically exported. After you drag and drop the required objects into the smart export window,
you can review what is going to be exported including the dependent objects before executing the export.
In our example, where we have dragged 3 objects into the smart export window, the following screen
illustrates how the smart export looks like including the original objects (in yellow) and the dependent
objects (in blue).

12

Note: When dragging and dropping mapping folders, you may be asked for a confirmation whether to
automatically add all objects with the same release tag; in this case, select NO.

Depending on the type of changes, you can drag and drop the following objects in smart export window

13

TaskFolders: Leaf folders in BI Apps Project that directly contains the interfaces, package and
Scenario. Exporting the folder ensures all the components are exported at the same time.
DataStores - Individual data stores, either as customizations to an existing data store, or entirely new
custom data stores. Note: if the TaskFolder is being export and has a dependency on the data store
the datastore doesn't need to be explicitly added using smart export.
Load Plan Components
Variables
Sequences
User Defined Functions (UDF)
Knowledge Modules (KM)

Note: Since the smart export automatically includes the dependencies, the total objects exported may be
considerably greater than the objects selected. As calculating the dependencies is time and resource
intensive, it's recommended that this approach is used for a maximum of 50 task folders or other first
class objects (i.e. excluding dependencies) per export. If there are more than 50 objects, use multiple
smart exports and give each export filename a sequential number in order to know the order to import on
the target.
2.3.4. On Target Environment: Copy the export files to a drive on the target machine. Log in to the ODI
repository in target environment from ODI Studio. Invoke the Import -> Smart Import option by
clicking on the same icon on the top right of the Designer tab. Select the file to be imported; in case
of multiple files to be imported, select the files one at a time in the same sequence as they were
exported.

14

2.3.5. Click Next and review the import before submitting. Complete the import.

2.3.6. Now, you need to import the topology settings from the backup taken in step#3.1. For this, click on
Import from topology navigator and then Smart Import. Select the xml file that was created in
step#2.3.1 and complete the import.

Please refer to Exporting/Importing section in Oracle Fusion Middleware Developer's Guide for
Oracle Data Integrator for a detailed explanation of the export/import features.

2.4.Migrating Customizations to the Target Business Analytics Warehouse

As part of your customizations, you might have done some data model changes to the data
warehouse schema, such as creating new columns to existing tables or creating whole new
tables. In this section, we will see how to migrate these data model changes into the data
warehouse schema on the target environment.

15

As part of moving the ODI repository customizations in step#2.3, the model changes done in the
Oracle BI Applications model in the ODI repository would have been moved to the target ODI
repository. Now, we will use this model in the target ODI repository to generate a sql file that
will contain all the data model changes and later apply it onto the target data warehouse
schema.
2.4.1.Make sure the BIAPPS_DW physical data server in the Topology navigator is pointing to
the target data warehouse schema

2.4.2.From the Designer navigator, under Projects, navigate to : BI Apps Project -> Components > DW -> Oracle -> Generate DW DDL -> Packages -> Generate DW DDL -> Scenarios ->
GENERATE_DW_DDL Version 001. Right click on this scenario and click Execute.

16

2.4.3.Set the context, agent and log level and click OK.

2.4.4.Ensure to supply the value to the following variables in the popup dialog box and click OK.
UTIL_GENDDL_REFRESH_MODE: should be 'INCREMENTAL'
UTIL_GENDDL_RUN_DDL: should be 'N'
UTIL_GENDDL_CREATE_SCRIPT_FILE: should be 'Y'
UTIL_GENDDL_SCRIPT_LOCATION: This parameter specify the location where the alter
table script will be generated. The default value is C:/Temp. Please provide an absolute
path directory value.

2.4.5.There will be a confirmation box that the session has started. From Operator navigator,
you can monitor the execution status of the procedure. Verify that it executes successfully.

17

2.4.6.Once the session completes successfully, look for sql file with name
BIA_DW_Schema_DDL_<session#>.sql in the directory specified by the parameter value
UTIL_GENDDL_SCRIPT_LOCATION. Review the sql file to verify it has the necessary DDL
statements to reflect all the data model changes performed.
2.4.7. Execute this sql file on the data warehouse schema using any sql tool such as Oracle SQL
Developer or Oracle SQL Plus.

2.5

Migrating Customized Load Plan Dev Components to the Target ODI

Repository.
2.5.1
2.5.2
2.5.3
2.5.4

On Source Environment: Now, login to the ODI repository in the source environment
from ODI Studio
Go to ODI DesignerLoad Plan And Scenario BIAPPS Load Plan Load Plan Dev
Components
Expand SDE Folder
Select the relevant source version Load Plan and Scenario Folder and expand it

18

2.5.5

Export the customized Load Plan Dev Components objects using Smart Export by clicking
on the icon on the top right of the Designer tab and choosing Export as shown. Then
choose Smart Export in the dialog that pops up.

19

2.5.6

Drag and drop the artifact that has changed and need to be Smart Exported.

20

In our example, we have created a custom interface under custom folder

Custom_SDE_ORA_SectionDimension so we added the generated custom scenario and added
it into 3 SDE Dims X_CUSTOM_DIM EBS_12_1_3 dev component.

Drag and drop the entire Load Plan Dev Component into the Smart Export window.

Please refer the instructions in 1.2 Customizations: Adding Columns to Existing Fact or
Dimension Tables and Section 1.3 Customizations: Adding Additional Tables sections of Oracle
Business Intelligence Applications Administrator's Guide for understanding Customization in
Oracle Business Intelligence Applications 11g.
2.5.7

Similarly, drag and drop any other customized Dev Components under SDE/SIL/PLP
Folder.

2.5.8

On Target Environment: Copy the export files to a drive on the target machine. Log in to
the ODI repository in target environment from ODI Studio. Invoke the Import ->
Smart Import option by clicking on the same icon on the top right of the Designer tab.
21

Select the file to be imported; in case of multiple files to be imported, select the files
one at a time in the same sequence as they were exported.

2.5.9 Click next and review the import before submitting. Complete the import.
2.5.10 Click on Import from topology navigator and then Smart Import. Select the xml file
that was created in step#2.5.6 and complete the import.

2.6

Migrating Customizations to the Target RPD and Presentation Catalog

Migrating Oracle BI Repository Metadata (RPD)

This section provides instructions for migrating delta or incremental customizations in the RPD from
a source environment (for example, Development) to an existing RPD in a target environment (for
example, Test)
This procedure uses the Oracle BI Administration Tool to perform a three-way merge of the
following repositories:
The original, unmodified RPD that you received with Oracle BI Applications 11g. In the
Administration Tool user interface, this repository is referred to as the "Original Master Repository."
The customized RPD in your target environment. In the Administration Tool user interface, this
repository is referred to as the "Current Repository."

22

 The customized RPD in your source environment. In the Administration Tool user interface, this
repository is referred to as the "Modified Repository." This RPD contains the delta customizations
which are to be migrated to the RPD in the target environment.
1. Back up your current, production repository by copying the file from your runtime location
to a safe location of your choosing.
2. Open the Oracle BI Administration Tool.
3. Equalize the three repositories to be merged.
For instructions, see the section "Equalizing Objects" in Chapter 17 Managing Oracle BI
Repository Files of the Oracle Fusion Middleware Metadata Repository Builder's Guide for
Oracle Business Intelligence Enterprise Edition. This guide is part of the Documentation
Library for BI EE 11.1.1.7.
4. Open the RPD from your target environment (for example, Test environment) in offline
mode.
5. From the File menu, select Merge.
6. In the Merge Repository Wizard, select Full Repository Merge as the Merge Type.
7. In the Original Master Repository field, browse for and select the original, unmodified RPD
that you received with Oracle BI Applications 11g. Provide the password for this repository.
8. In the Modified Repository field, browse for and select the customized RPD from the source
environment (for example, Development environment). Provide the password for this
repository.
9. Click Next.
The Define Merge Strategy dialog displays a list of conflicts.
10. For each conflict displayed, select Current. This will apply your customizations contained the
source RPD to the RPD in the target environment.
For detailed information about merging repositories using the Oracle BI Administration Tool,
see "Merging Repositories," in Chapter 17 Managing Oracle BI Repository Files of the Oracle
Fusion Middleware Metadata Repository Builder's Guide for Oracle Business Intelligence
Enterprise Edition. This guide is part of the Documentation Library for BI EE 11.1.1.7.
Migrating Oracle BI Presentation Catalog Metadata

The process for moving the Oracle BI Presentation Catalog involves copying the customized
objects in the source catalog and pasting them into the target catalog. For instructions, see the
23

section titled "Copying and Pasting Objects" in Chapter 17 Configuring and Managing the Oracle
BI Presentation Catalog of the Oracle Fusion Middleware System Administrator's Guide for
Oracle Business Intelligence Enterprise Edition. This guide is part of the Documentation Library
for BI EE 11.1.1.7.

2.7

Defining, Generating and Executing Domains Load Plan in the Target

Environment
Define, generate and execute a Domains Load Plan in the target BI Applications 11g
environment as described in section 4.6 Running the Domains Load Plan in Chapter 3 Installing
and Setting Up Oracle BI Applications of the Oracle Fusion Middleware Installation Guide for
Oracle Business Intelligence Applications 11g.

2.8

Migrating Functional Setup Data to Configuration Manager in the Target

Environment
The migration of functional setup data (Data Load Parameters, Domains and Mappings,
Reporting Parameters) is performed by an export of the setup data from Configuration Manager
in the source environment and then an import of the data into Configuration Manger in the
target environment.
To migrate functional setup data:
2.8.1

Log into Configuration Manager in the source environment (for example, development)
as a user with BI Applications Administrator privileges. Navigate to Setup Data Export
and Import: Export Setup Data using the left hand Tasks pane.

2.8.2

From the Table tool bar on the Export Setup Data page, click on the Export icon to
display the New Data Entry Dialog: Export. In the Export dialog:
a. Provide a meaningful name for the export file name
b. Select the following objects to export:

Data Load Parameters

Domains and Mappings

Reporting Parameters

NOTE: Do not select System Setups. System setups have already been
completed as part of Step 1 Creating a Target Test or Production Environment
described in this document above.
24

Data Load Parameters: Required Before Executing Full Load Plan in Target Environment Click on
Manage Data Load Parameters to see project specific values to common parameters

Domains and Mappings: Domains are pre-seeded dimensional values that help define business
metrics. For Example: In Financial Analytics, domains store information about the General
Ledger accounts. Domains are typically located in the source system.

Reporting Parameters: For Viewing / Defining Reporting parameters, click on the Manage
Reporting Parameters and update Parameter values according to the Parameter name.

2.8.3

Click on the Export button. In the File Download dialog, click Save to save the ZIP file to a
location that you specify.
25

Steps 1-3 described how to export the functional setup data from the source Configuration
Manager to a zip file. Steps 48 below describe the import of the functional setup data into
Configuration Manager in the target environment.

2.9

2.8.4

Copy the ZIP file exported in step 3 above to a file location that is accessible from the
machine that will run the target Configuration Manager browser window.

2.8.5

Log into Configuration Manager in the target environment (for example, test) as a user
with BI Applications Administrator privileges. Navigate to Setup Data Export and Import:
Import Setup Data using the left hand Tasks pane.

2.8.6

From the Table tool bar on the Import Setup Data page, click on the Import data icon to
display the New Data Entry Dialog: Import Data.

2.8.7

In the Import Data dialog, browse to locate the ZIP file copied to the location in step 4
above.

2.8.8

Click OK to import the functional setup data into the target Configuration Manager. The
Import table is updated with details of the import.

Defining, Generating and Executing Load Plans in the Target

Environment
In Configuration Manager in the target environment define, generate and execute Load Plans for
data loads. See Oracle Fusion Middleware ETL Guide for Oracle Business Intelligence
Applications 11g.

26

Appendix
A.

Things to know about ODI Smart Export and Import

i)

Flexfields: Flexfield definitions are not moved by the Smart Export. If new flex fields are
created in the source ODI repository, they need to be recreated in the target repository
(with the same name), before the ODI migration can be started.

ii) Knowledge Modules: Remember that knowledge modules (KM) affect all the objects that
use the KM. So when you make changes to KMs and migrate them from source to target,
the change will affect all the mappings that use the KM, not just the mappings that are
migrated. So please do thorough testing of all the objects that are using the KM.
iii) When you export an object using smart export, it automatically includes any dependencies.
Hence, the total objects exported may be considerably greater than the objects selected. As
calculating dependencies is a time and resource intensive operation, it is recommended not
to export too many objects in a single export. It is recommended that a maximum of 50 task
folders or other first class objects (i.e. excluding dependencies) are included per export. If
there are more than 50 objects, use multiple smart exports and give each export filename a
sequential number in order to know the order to import on the target
iv) During the export/import process if ODI Studio is not responding and taking more time to
migrate of ODI repository content, then trimming BI Apps ODI Repository helps to improve
database performance and ODI responsiveness, trimming content is not suggested as a best
practice after deployment. This is just guidance for customers who may be experiencing
issues due to the large size of the ODI repository refer (Doc ID 1970123.1 Trimming BI Apps
ODI Repository) for details and steps. It is recommended to do export/import of ODI
repository mappings on the ODI Studio client on the machine where the ODI repository DB is
hosted.
v) When attempting to perform a smart export of a large project folders errors may be
encountered refer Doc ID 1909012.1 for details and fix
vi) When you do the import, ODI will first try to find if the object exists in the target repository,
and try to patch it if it already exists. For this, ODI primarily uses the object ID to match
between the objects to import and the object already present in the repository. If you
delete an object from your source (development) repository after it has been migrated into
target, and create the same object again in source, it is created with a new object ID. This
might cause ODI to consider this as a new object and thus will not be able to patch the
existing object in target appropriately. To avoid these situations, it is recommended to
NEVER delete objects from source repository once it is migrated into target.
27