Home

About

Careers

Clients

Consulting

Training

Support

Articles

Blog

Migrating OBIEE Projects Between DEV and PROD Environments

April 28th, 2008 by Mark Rittm an

One of the clients Im working with this week wants to go through how OBIEE environments are migrated from one
environment to another. They are working on a solution for their organization where a team of developers put together an
initial first cut of the repository and web catalog, and then at various points from then onwards they will either completely
refresh the production environment using whats in development, or more usually theyll take an element of whats in
development, say an individual subject area, set of fact and dimension tables or a set of dashboards or reports, and deploy
those as a patch in to production.
When working with OBIEE, my understanding is that you can have one BI Server per physical/virtual server, which can
connect to one or more repositories, though only one of them is the default. You also normally then set up one BI
Presentation Server instance which connects through to the default repository for the corresponding BI Server. In reality this
means that each OBIEE environment consists of one BI Server and one Presentation server on the same physical server
(together usually with an installation of BI Publisher, configured to use BI Server security), or in some cases the BI Server and
BI Presentation Server might be split onto different physical servers, and possibly further clustered on to more servers if the
expected load is high.
You can, it should be noted, set up additional Presentation Servers on the same physical server, each of them connecting
through to the same BI Server but with different default repositories, which gives you a way to create your DEV, PROD and
other environments on the same physical server (if its a beefy Unix box, for example). However this is a fairly complex task
(see this blog posting by Borkur) and its usually easier to have a simple pairing of one BI Server, one Presentation Server
(plus the BI Publisher, Delivers etc servers) per environment with all of these contained on their own physical server. The rest
of the migration steps in this posting therefore assume that youve got each environment set up in this straightforward way,
with OBIEE already installed on each server and a single installation of BI Administrator that can connect to both of them.

Search the blog

Recent Posts
Analytics w ith Kibana and
Elasticsearch through Hadoop
part 3 Visualising the data in
Kibana
Analytics w ith Kibana and
Elasticsearch through Hadoop
part 2 Getting data into
Elasticsearch
Analytics w ith Kibana and
Elasticsearch through Hadoop
part 1 Introduction
UKOUG Partner of the Year
Aw ards
Oracle BI Cloud Service for SaaS
Application Reporting Part 1:
Integrating BICS to
Salesforce.com using REST APIs

Top Posts
OBIEE 11g Security Week :
Managing Application Roles and
Policies, and Managing Security
Migrations and Deployments
Upgrading OBIEE to 11.1.1.7

When you think about migrating an OBIEE environment, there are four main things youll want to move across:
1. The BI Server repository, which contains the enterprise semantic layer, variables, security settings (including users and
groups if you use RPD-based security) and connection pool settings through to the physical data sources. The contents

open in browser PRO version

Are you a developer? Try out the HTML to PDF API

OBIEE 11gR1 : Architecture and

Use of WebLogic Server
OBIEE 11g Security Week :
Connecting to Active Directory,
and Obtaining Group Membership

pdfcrowd.com

of the repository are normally contained with a single RPD file contained in the %ORACLEBI/%server/Repository
directory, with %ORACLEBI% being determined by the SAROOTDIR environment variable and the current RPD in use
(only one can be online at any one time per installation of OBIEE) being determined by the
%ORACLEBI%/server/config/NQSConfig.INI file.
2. The BI Presentation Server web catalog, which contains the reports, dashboards, prompts, ibots and so on, together
with a separate set of users and roles (usually propagated from the BI Server repository) and their permissions on the
web catalog objects. Unlike the BI Server repository, the web catalog is stored in a set of XML files, one per web catalog
object organized into folders, plus an ATR file per folder that contains permissions on the objects within them. The files
that make up the web catalog are held in the %ORACLEBIDATA%/web/catalog directory, with %ORACLEBIDATA%
being determined by the SADATADIR environment variable.
3. Connections through to physical datasources, held on the server containing the BI Server, which when working in an
Oracle environment are usually contained in a single TNSNAMES.ORA file. The connection pool settings in the BI
Server repository references the connections in this file.
4. The BI Publisher Report Catalog, which contains the XDO files that define the BI Publisher reports. It is assumed that BI
Publisher is configured to use BI Server security or LDAP security, therefore the users and groups in the BI Publisher
OC4J container will not need to be migrated. This catalog is normally found in the %ORACLEBI%xmlp/XMLP/Reports
directory.

and Obtaining Group Membership

from Database Tables
Analytics w ith Kibana and
Elasticsearch through Hadoop part 3 - Visualising the data in
Kibana

Random Posts
Introduction to the BI Apps
11.1.1.7.1 - Release Overview
Installing obi-metrics-agent,
Graphite, and collectl
MDS XML versus MUDE Part 4:
Simple Multi-Branch Development
Rittman Mead at ODTUG
KScope'14, Seattle

Note that this list isnt exhaustive if you know of anything else that needs migrating (perhaps to do with Disconnected
Analytics, perhaps the configuration files for the Presentation Server) let me know by adding a comment to this posting.

End-to-End ODI12c ETL on Oracle

Big Data Appliance Pt.3 : Enhance
w ith Oracle Reference Data via
Sqoop, and CKMs

In a typical customer situation, the environment migration lifecycle looks something like this:

Tags

Step 1 : Initial Development (First Cut)

All development of the repository and web catalog initially happens in DEV. At some point, the initial work is complete and the
DEV environment is ready to be copied into PROD (or TEST, or whatever)
Step 2 : First Deployment to Production
The initial creation of the PROD BI Server repository is done through copying the DEV RPD file in to the PROD environment.
Copying across the entire RPD file will bring across all subject areas, physical models, presentation models, security
settings, users and groups (if RPD security is used), variables and so on. If your OBIEE server does not have a
TNSNAMES.ORA file on it to connect to the source database, you will need to copy this across from the DEV server as well.
You can either copy this repository interactively by using the filesystem explorer application and cut and paste, or you can
script the copy using a batch or shell script. If you need to make changes to the repository en-route to the PROD
environment, you can instead of copying the repository whole, export it into a UDML text file using the using the
nQUDMLGen.exe utility within the %ORACLEBI/server/bin directory, alter any settings that you need to change using a perl
script for example, and then import the amended text file into a new, blank PROD repository using the nQUDMLExec.exe
utility. See this posting on this blog on UDML and repository migration and merging, and this posting by Venkat on

open in browser PRO version

Are you a developer? Try out the HTML to PDF API

11g Big Data Appliance

BIP BI Publisher dw em12c

Endeca exalytics
extremebi git

goldengate
hadoop Hive init.d install
linux MDS XML monitoring
new features nqcmd OBIA

obiee odi odi12c

opatch Oracle Oracle BI
Applications

oracle data

integrator Oracle
Endeca Oracle Endeca
Information Discovery ow b

performance Real Time

pdfcrowd.com

utility. See this posting on this blog on UDML and repository migration and merging, and this posting by Venkat on
automating changes to connection pool settings using UDML during a migration.
The corresponding Web Catalog is migrated by copying the contents of the %ORACLEBIDATA%/web/catalog directory to the
corresponding directory on the production server. This directory contains top-level folders for Delivers and
Answers/Dashboard contents, like this:

Decisions replication
ReportService RTD runReport

sampleapp screen scripting

security startup testing

training XML

With each top-level folder then containing sub-folders and then individual file pairs for each web catalog item, like this:

open in browser PRO version

Are you a developer? Try out the HTML to PDF API

pdfcrowd.com

The BI Publisher report catalog is migrated by copying the contents of the %ORACLEBI%/xmlp/XMLP/Reports directory and
the %ORACLEBI%/xmlp/XMLP/users directories over to the production BI Publisher environment.
In all cases, the RPD file, the contents of the Web Catalog files, any UDML files and BI Publisher report files can be stored in
a version control system to create versioned releases of your project metadata.
3. Subsequent Full Refreshes of Production
If production ever needs to be fully refreshed with what is in development, then the above process can be repeated. Note
however that ordinarily, any reports or customizations that happened in the production environment (including users custom
dashboards) will be overwritten using this process; these can however be preserved if the sub-folders below the
%ORACLEBIDATA%/web/catalog/web _catalog_name/root/users`are saved before being overwritten by the DEV web catalog
files, and then copied back after the migration takes place.

open in browser PRO version

Are you a developer? Try out the HTML to PDF API

pdfcrowd.com

4. Incremental Refreshes of Individual Subject Areas, Tables, Columns & Corresponding Presentation Areas
Incremental migrations of elements of the BI Server repository can either be done interactively or through scripting.
Interactive migrations are carried out using the Copy / Paste feature in BI Administrator, and can be used to copy across any
element from subject area down to individual column from one repository to another. To do this, open two copies of BI
Administrator with one having the DEV repository loaded offline and one having the production repository loaded offline. Use
the Copy and Paste feature of the tool to copy elements from one repository to another, like this:

Check the repository consistency afterwards, and if all is OK then open the production repository online to start using the
migrated objects.

open in browser PRO version

Are you a developer? Try out the HTML to PDF API

pdfcrowd.com

Automated (scripted) migrations are carried out using the nQUDMLGen.exe and nQUDMLExec.exe utlitiies, which can export
and import repository elements from one repository to another (again this posting on this blog for examples of these utilities
in use.) Automated migration in this manner is usually preferred in real, production situations as it removes the chance of
operator error when migrating from one environment to another. If the physical tables to which logical tables map are the
same in both the DEV and PROD environments (which they ideally should be) then logical tables should preserve their
mappings when migrated from one environment to another. Scripted migrations are also the only way of migrating non-table
and dimension settings from one environment to another, such as variable settings, user and filter settings etc). You can
also take the text files created using these utilities and store them in a version control system to create versioned patches
to your OBIEE metadata.
5. Incremental Refreshes of Individual Reports, Dashboards, Alerts, Prompts etc from the Web Catalog
Like repository migrations, Web Catalog migrations can be done either interactively or through manually copying filesystem
objects, potentially in an automated fashion using batch files.
Interactive migrations are carried out in a similar way to repository migrations, but this time using two copies of the Catalog
Manager application open, one connected to the DEV web catalog and one connected to the PROD web catalog. Like the BI
Server repository, the web catalog can be opened offline by navigating to the %ORACLEBIDATA%/web/catalog/catalog_name
directory (be careful that you open the correct directory, otherwise the Catalog Manager application will helpfully create a new
web catalog for you rather than point out that it cannot find one at this location), or online by connecting to the BI Presentation
Services URL. Once connected, you can cut and paste objects between the two catalogs as shown in this blog posting here.
Automated (scripted) web catalog item migrations can be accomplished by copying the web catalog element (a file of the
same name as the report, dashboard etc with no file extension) and its corresponding ATR file (the same name with ATR at
the end, as shown in the screenshot above) from the DEV web catalog to the PROD one using filesystem copies.
These copies can be batched up and automated using .BAT or unix shell scripts in order to copy across multiple reports and
other elements, note the comment on this by Adrian Ward at the end of this blog post. Again its worth noting that automated
migration in this way is usually preferred by customers as it removes the chance of someone inadvertently or deliberately
changing a report during migration, or needing live access to the production environment. Note also that the two Web
Catalogs need to have the same user and group settings for permissions to migrate correctly across both environments.
Miscellaneous Object Migrations
On any mature OBIEE system, there are no doubt other elements of each environment you would also wish to migrate. Some
of these might include dashboard themes (XSL and other files), TNSNAMES.ORA files and/or ODBC DSNs, any clustering

open in browser PRO version

Are you a developer? Try out the HTML to PDF API

pdfcrowd.com

files and settings and BI Server users and groups if you are using RPD security (this would need, I believe, to be done using
UDML scripting, see this other posting by Venkat). If anyone reading this knows of any others then add these as comments
to the postings.
Migration Example : Complete Environment Refreshes whilst Preserving User Reports and Dashboards
So thats the theory of how you go about migrating from one OBIEE environment to another. For this particular customer
though, we can take a slightly simplified approach and release updates to the production environment by just copying across
whats in development, as long as we have a method to preserve any reports or dashboards that users create in the
production environment and restore them after the migration takes place. This is a bit of a simpler process than using
nqUDMLGen.exe and nqUDMLExec.exe as we wont be migrating across individual parts of the repository or individual
reports or dashboards. In addition, this customer uses the same database instance for their DEV and PROD OBIEE
installations, so we can use the same TNSNAMES.ORA contents for all environments.
To put in place a routine for this migration, we will need to carry out the following steps, organized in to two parts; the first part
(steps 1-5) will be concerned with gathering up all the repository and report metadata from the DEV environment and copy it
to a staging area, with the second part (steps 6-9) copying this metadata across to the PROD area, after first taking a copy of
any user-generated reports and dashboards.
1. Somewhere in a staging area, we create a directory for the metadata to be migrated. We call this OBI_RELEASE_x, with
x being the release number.
2. Within this directory, we create four subdirectories
1.
2.
3.
4.

RPD
WEBCAT
WEBCAT_USERS
TNSNAMES

3. We then create two Windows or Unix batch/script files, with three input parameters
1. REPOSITORY_NAME (to hold the name of the repository to be migrated)
2. ORACLEBI (to hold the root directory of the Oracle BI Server installation)
3. ORACLEBIDATA (to hold the root directory of the Oracle BI Presentation Server installation)
4. For this customers installation, they are not using BI Publisher or Delivers, so we will leave this out of the migration at
this stage.

open in browser PRO version

Are you a developer? Try out the HTML to PDF API

pdfcrowd.com

5. We then create a first script that copies the DEV environment metadata into the OBIEE_RELEASE_x directory ready for
migration. This script performs the following steps:
1. copy the %REPOSITORY_NAME%.RPD file from %ORACLEBI%/server/repository/ into /RPD directory.
2. Copy the %ORACLEBIDATA%/web/catalog/%REPOSITORY_NAME% folder to /WEBCAT
3. Copy the TNSNAMES.ORA file used on the server to /TNSNAMES
6. We then create a second script, which is used to copy the metadata from the OBIEE_RELEASE_x directory to the PROD
server. It carries out the following steps:
1.
2.
3.
4.
5.
6.
7.

Shut down BI Server so that you can overwrite the repository file.
Copy the /RPD directory to %ORACLEBI%/server/repository directory
Copy the %ORACLEBIDATA%/web/catalog/%REPOSITORY_NAME%/root/users to /WEBCAT_USERS
Copy the /WEBCAT directory to %ORACLEBIDATA/web/catalog/
Copy the /WEBCAT_USERS directory to %ORACLEBIDATA%/web/catalog/%REPOSITORY_NAME%/root/users
Copy the /TNSNAMES directory to the database client /network/admin directory
Restart the BI Server

7. Once these scripts have run, to test that migration has happened correctly we perform the following steps:
1. Go in to BI Administrator, check you can connect, check you can do row counts, check global consistency. Check
that all users you expect are there
2. Log in to dashboard, check that all reports and all users reports and dashboards are present.
Ive tested this approach out on my DEV and TEST environment and it migrates all data, reports and dashboards correctly.
As I mentioned previously, what I havent tested it with is BI Publisher and Delivers, but the principal should still be the same.
As usual, any comments or suggestions are most welcome.
Share

Tw eet

Like

Posted in Oracle BI Suite EE | 6 Comments

Comments
ia Says:

open in browser PRO version

Are you a developer? Try out the HTML to PDF API

pdfcrowd.com

April 29th, 2008 at 3:49 pm

Thanks for an interesting article!

Some objects you also have to migrate are: -custom images, to be copied to 2+ different locations, Java and style
folder(s)
-custom scripts like javascripts executed with iBots
-xml-files needed for writebacks

Chris Says:
May 1st, 2008 at 5:43 pm

Can the export/import method be used to transfer between DEV and PRD BIEE environements if they are different
platforms?

Praveen Chand Says:

May 28th, 2008 at 6:02 pm

Hello,
Can you also give your advice for migrating DAC and Informatica changes from DEV to PROD?
Thanks

Ken Guzzetta Says:

May 30th, 2008 at 11:18 pm

In doing scripted incremental migrations (essentially patches) from DEV to PROD, are you talking about copying the
directory structure folder and associated atr file on a windows server, or is this some other method such as using web
services. We are doing manual migrations right now meaning we take an archive of the top most folder of the dash or
report we want to move in DEV and copy the archived file to the PROD server and using catalog mgr unarchive it into the
prod catalog. With many changes this can be tedious and error prone. From this and the associated post migratingobiee-reports-between-web-catalogs it appears as long as include both the file/folder and its associated atr file, it can
be batched and copied to the prod directory without any problem. Does this sound right? Someone in our group had tried

open in browser PRO version

Are you a developer? Try out the HTML to PDF API

pdfcrowd.com

that in the past, but the catalog became corrupted, so we didnt think it was a possibility.

Mark Rittman Says:

June 1st, 2008 at 5:37 pm

@ia good comment, yes those are indeed other items that should be migrated as well. Thanks for this.
@chris I think so, though Ive not tried myself. The repository RPD file should be platform-neutral, as should the files
that make up the Web Catalog. You may need to take file permissions into account if you go from Windows to Unix, but in
theory it should work.
@Praveen not yet, but this is something were looking at. Keep an eye on the blog for details on this at a later date.
@Ken yes, this is an alternative to using the Catalog manager, and other people have commented that they use the
manual copy approach (scripted) rather than the Catalog Manager as it removes the possibility of human error. I havent
heard about corruptions being introduced this way, certainly in theory it works perfectly fine.
regards, Mark

Peter Scott Says:

June 4th, 2008 at 7:57 am

@Praveen
I have been taking a quick look at migration of changes for OBIEE Applications.
As you say, you only need to migrate when custom changes have been made.
There is not yet a single Oracle document to describe the process but documentation exists for the operations you need
to complete in Informatica and for the DAC.
For Informatica, follow the steps in the Repository Guide PowerCenter (8.1.1), chapter 9 Exporting and Importing
Objects.
For the DAC the corresponding process is documented in the OBIEE Data Warehouse Administration Console Guide,
chapter 6: importing, exporting and distributing DAC metadata.

open in browser PRO version

Are you a developer? Try out the HTML to PDF API

pdfcrowd.com

Call us now to talk about your BI project:

+44 (0) 1273 911 268 (UK) or (888) 631-1410 (USA)
or +61 3 9596 7186 (Australia & New Zealand) or
+91 997 256 7970 (India) or +32 280 882 11 (Belgium)
Hom e

Services

About Us

> Consulting
> Training
> Support

>
>
>
>

About us
About our team
Contac t us
Our clients

Consulting
Services
>
>
>
>
>
>

Projects
Expert Services
OBIEE 11g
Sustainability
On Discoverer?
Orac le DW

Training

Resources

Blog Authors

> OBIEE
Bootcamp
> OBIEE End-User
> Exalytics
> ODI 11g
Bootcamp
> Oracle BI Apps

> Articles
> Blog
> OBIEE 11g

>
>
>
>
>
>
>

Mark Rittman
Venkat J
Peter Scott
Borkur S
Mike Vickers
Robin Moffatt
Jon Mead

Rittman Mead Consulting ltd.

Registered Office : Suite B,
First Floor Moore House,
13 Black Lion Street,
Brighton, East Sussex,
BN1 1ND, United Kingdom
Company No. : 6032852
VAT No. : 900 3839 48
Rittman Mead America, Inc.
Registered Office : 4550 North Point Parkway Suite
390 Alpharetta, Georgia 30022, USA
Rittman Mead Oceania Pty Ltd.
Registered Office : 12 Moore Street,
Brighton East,
Victoria, 3187, Australia
Australian Company No. : 149 458 935
Rittman Mead Consulting Pv t Ltd.
Registered Office : Unit 105-106
Regent Prime
Whitefield Main Road
Whitefield
Bangalore
560066
Rittman Mead Belgium
Registered Office : Chausse de Louvain 426
1380 Lasne
Belgium

2010-2011 Rittm an Mead Consulting.

open in browser PRO version

Privacy Policy

E: info@rittm anm ead.com

Are you a developer? Try out the HTML to PDF API

pdfcrowd.com

Website Design & Build: tymedia.co.uk

open in browser PRO version

Are you a developer? Try out the HTML to PDF API

pdfcrowd.com