BI Applications 11.1.1.7.

1
Migrating Configurations and
Customizations from Development
to a Test or a Production
Environment (Doc ID 1587872.1)
This document describes how to move Oracle BI Applications 11.1.1.7.1
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 11.1.1.7.1 Environment and Migrate
Configurations and Customizations............................................................................ 3
2.1.

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

2.2.

Renumbering the Target ODI Repository........................................................3

2.3.

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

2.4.

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

2.5.

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

2.6. Defining, Generating and Executing Domains Load Plan in the Target
Environment.......................................................................................................... 18
2.7. Migrating Functional Setup Data to Configuration Manager in the Target
Environment.......................................................................................................... 18
2.8.

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

Appendix.................................................................................................................. 21

A.

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

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 11.1.1.1.7.1 release.
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 youre
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.Migrate RPD and Presentation Catalog customizations from the source
environment to the target environment.
1.6.In Configuration Manager in the target environment, define and generate a
Domains Load Plan. Run the Domains Load Plan.

1.7.Export functional setup data from Configuration Manager in the source

environment and import them into Configuration Manager in your target
environment.
1.8.Define and generate Load Plans for data loads. Execute the Load Plans.
Review Appendix A Things to know about ODI Smart Export and Import.

2. How To Create a Target BI Applications 11.1.1.7.1

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 11.1.1.7.1 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 Release 1
(11.1.1.7).
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:

3.4.1 Setting the Business Analytics Warehouse Connection in ODI

3.4.2 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.

3.4.3 Enabling Offerings for Deployment

3.4.4 Editing Preferred Currency Display Names and Enabling
Document Currency

3.4.5 Setting Languages for Data Load into the Business Analytics
Warehouse

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

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 (Eg
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 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:
2.1. 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.

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

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).

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

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.

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.

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.

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.

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 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
11.1.1.7.1. 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."
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 11.1.1.7.1.
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 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.6.
Defining, Generating and Executing Domains Load
Plan in the Target Environment
Define, generate and execute a Domains Load Plan in the target BI
Applications 11.1.1.7.1 environment as described in section 3.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 Release 1 (11.1.1.7).

2.7.
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.7.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.7.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.

2.7.3. Click on the Export button. In the File Download dialog, click Save to
save the ZIP file to a location that you specify.
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.7.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.7.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.7.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.7.7. In the Import Data dialog, browse to locate the ZIP file copied to the
location in step 4 above.

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

2.8.
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 Release 1 (11.1.1.7).

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's 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) 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.