BI Apps 11.1.1.7.1 Migrating
BI Apps 11.1.1.7.1 Migrating
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.
2.2.
2.3.
2.4.
2.5.
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.
Appendix.................................................................................................................. 21
A.
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.
2.1.
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.
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 custom change to an out of the box interface by making a copy of the
folder
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.
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
2.4.5. There will be a confirmation box that the session has started. From
2.4.6. Once the session completes successfully, look for sql file with name
2.5.
Migrating Customizations to the Target RPD and
Presentation Catalog
Migrating Oracle BI Repository Metadata (RPD)
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.
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,
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:
Reporting Parameters
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.