RITTMANMEAD OBIEE Masterclass

T : +44 (0) 8446 697 995 or (888) 631 1410 (USA) E : enquiries@rittmanmead.com W: www.rittmanmead.
com
Mark Rittman, Director, Rittman Mead
Venkatakrishnan Janakiraman, Principal Consultant, Rittman Mead
OBIEE Masterclass 2009
Wednesday, 2 December 2009
T : +44 (0) 8446 697 995 E : enquiries@rittmanmead.com W: www.rittmanmead.com T : +44 (0) 8446 697 995 E : enquiries@rittmanmead.com W: www.rittmanmead.com
Who Are We?
Mark Rittman is Technical Director at Rittman Mead
! Oracle ACE Director, 12 Years+ of Oracle BI experience
! Author of forthcoming Oracle Press OBIEE+ book
! Consultant and Trainer, based in the UK
! Blog at http://www.rittmanmead.com/blog
Venkatakrishnan Janakiraman is Principal Consultant, Rittman Mead
! Over 6+ Years of Oracle BI Implementation/Training experience
! Principal Consultant, Rittman Mead
! Blog at http://oraclebizint.wordpress.com
and now at
http://www.rittmanmead.com/blog
T : +44 (0) 8446 697 995 E : enquiries@rittmanmead.com W: www.rittmanmead.com
Rittman Mead Consulting
Oracle BI&DW Project Specialists
Consulting, Training, Support
Works with you to ensure OBIEE and
Oracle BI Applications project success
Small, focused team
OWB, Oracle BI, DW technical
specialists
Clients in the UK, Europe, USA
What is this Presentation About?
OBIEE 10g is a mature product with widespread adoption
We are all waiting for the 11g release
However there are still questions that commonly come up when customers adopt 10g
Around Data Modeling with the BI Server
Around managing the lifecycle of projects
This masterclass will therefore cover the following areas
! Introduction to OBIEE 10g
! Common data modeling scenarios
- Modeling normalized data
- Modeling single-table sources
- Modeling unconformed fact tables
! OBIEE project lifecycle
- Promoting between environments
- Version control
T : +44 (0) 8446 697 995 or (888) 631 1410 (USA) E : enquiries@rittmanmead.com W: www.rittmanmead.com
OBIEE Data Modeling
UKOUG OBIEE Masterclass 2009
Oracle Business Intelligence Enterprise Edition
Web Server
(IIS, Tomcat, Websphere, iPlanet)
Oracle BI Server Oracle BI Server
Intelligent Request Generation Intelligent Request Generation
Data Source Adapters Data Source Adapters
Navigator Navigator
Logical Request Generation Logical Request Generation
Aggregate
Navigator
Fragmentation
Optimization
Multi-Pass /
Sub-Request Logic
Optimized Query Rewrites Optimized Query Rewrites
Session Management Session Management
M
e
t
a
d
a
t
a

I
n
t
e
r
c
h
a
n
g
e
M
e
t
a
d
a
t
a

I
n
t
e
r
c
h
a
n
g
e
Logical SQL ODBC/JDBC (Logical Business Model) Logical SQL ODBC/JDBC (Logical Business Model)
Cache Cache
Services Services
Oracle BI Administration Oracle BI Administration
Analytical and Operational Data Sources
Metadata Documentation Services Metadata Documentation Services
Metadata Management Services Metadata Management Services
Multi-User Development Services Multi-User Development Services
Server Management Services Server Management Services
ODBC over TCP/IP (SSL)
S
y
s
t
e
m

/

S
y
s
t
e
m

/

P
e
r
f
P
e
r
f

M
o
n
i
t
o
r
i
n
g

M
o
n
i
t
o
r
i
n
g
ODBC, CLI, OCI, XML, MDX
Oracle BI Presentation Services Oracle BI Presentation Services
SOAP Web Services, XML and URL Interface SOAP Web Services, XML and URL Interface
Cache Services (Web) & Connection Cache Services (Web) & Connection Mngmt Mngmt
XML XML
Framework Framework
Web Web
Catalog Catalog
Service Service
User Profiling, Security and Session User Profiling, Security and Session Mngmt Mngmt
Oracle Interactive Oracle Interactive
Dashboards Dashboards
Oracle Answers Oracle Answers
Load Balancer Load Balancer
S
e
c
u
r
i
t
y

S
e
r
v
i
c
e
s
S
e
c
u
r
i
t
y

S
e
r
v
i
c
e
s
Q
u
e
r
y

G
o
v
e
r
n
.
Q
u
e
r
y

G
o
v
e
r
n
.
TCP/IP
(SSL)
Javascript
for Usability & Interactivity
Web Browser
XML, HTML,
XLS, PDF, TXT
over
HTTP/HTTPS
External Applications and Portals
HTML, SOAP
over
HTTP/HTTPS
Execution Engine Execution Engine
SAW Bridge (J2EE/ISAPI) SAW Bridge (J2EE/ISAPI)
TCP/IP (SSL)
Oracle BI Publisher Oracle BI Publisher
Delivery Server Delivery Server
Layout Interfaces Layout Interfaces
Data Logic Data Logic
XSL
Externalized
Authentication
LDAP
DB Authentication
Custom Authenticator
Oracle BI Oracle BI
Cluster Controller Cluster Controller
Oracle Delivers Server Oracle Delivers Server
Scheduling/Event Services Scheduling/Event Services
Agent Execution Logic Agent Execution Logic
Device Adaptive Content Device Adaptive Content
OBIEE 10.1.3.2 Architecture
Oracle BI Server
Calculation and Data Integration Engine
! Virtual Data Warehouse
! Allows reporting across multiple sources
! Data accessed though metadata layer
Connects to RDBMS and OLAP data
! Oracle Database (including Oracle OLAP)
! IBM DB2
! Microsoft SQL Server
! Teradata
! Microsoft Analysis Services (OLAP)
! SAP BW 'info cubes'
Security, Summary Management
Translates incoming logical SQL
in to optimized, physical SQL
Data Access
Reporting data may be sourced from
multiple databases, applications
! Oracle Database (including Oracle OLAP)
! IBM DB2
! Microsoft SQL Server
! Teradata
! Microsoft Analysis Services (OLAP)
! SAP BW 'info cubes'
! SAP, Peoplesoft, Siebel, E-Business Suite
Oracle BI Server joins this source
data together and presents a
logical business model
! Facts
! Dimensions
Customer
Common Enterprise Information Model
Enables consistency, security, reuse, flexibility
Role-based views of the organization
Single metadata model of the business
Consistent definition of business measures, metrics, calculations
Drill paths, summaries, security
Model once, deploy anywhere
Across any data source
Model First development
Data Modeling using Oracle BI Server
Design goal for the BI Server metadata layer is to create a Star Schema
! Fact tables, Dimension tables
! Drill paths
Source data can either be pre-integrated (data mart,
data warehouse) or integrated using
the BI Server (federated)
! Federated can be faster to deliver (report in place)
- Assumes data sources share common key values
! Data marts and data warehouses are simpler and can
be faster to query
MDX (OLAP, Multi-dimensional) data is converted into
RDBMS row-sets
In this presentation, we will look at how you can use the
data modeling features of OBIEE to create logical star schemas
Star Schema Design Approach
Classic Kimball approach
Fact tables contain measures, and joins to dimensions
! No attributes except for degenerate dimensions
! Leave IDs in, remove in Presentation layer
Dimension tables contain lookup data
! Customer, Product, Time etc
! Dimensions can however be facts
- Use alias tables to disambiguate
Dimension objects define drill path
! Multiple hierarchies supported
! Ragged hierarchies possible (see later)
! Time dimensions enable time-series queries
Sample Business Model
Data Modeling Workflow Steps
1. Define logical model (on paper or using BI Administrator)
2. Import physical data sources & define primary and foreign keys
3. Map logical model to physical model
4. Create initial calculations
5. Create dimensions
6. Create initial presentation model
7. Create complex calculations, time dimensions etc
8. Add additional columns to presentation model
Normalized Data Modeling Scenario
Global Company has a data warehouse, containing order and customer data
Requirement is to take the existing warehouse (normalized)
and turn it into a star schema (denormalized)
For now, OBIEE will be used to map the data
Step 1: Create Logical Layer
Firstly, create new logical model
Then create logical tables and columns
! Either create from scratch, then connect to physical
(best practice)
! Or define by dragging and dropping physical tables
Start from fact table and work outward to the dimensions
Do one fact/dimension combination first
Then add more facts
... and more dimensions
Add details on datatypes etc later on
Step 2: Create Physical Layer
Define ODBC connection from client or server to database
! ODBC only needed to define initial connection, import metadata
! Native connection (OCI etc) takes over from then
Import tables, views, keys etc from
data source
Define keys, foreign keys if needed
Update row counts
Define table aliases
Physical Join Types
If source data has foreign key joins, they will be imported
If not, they can be defined in the physical model
Two types of join
! Foreign key joins (e.g. CUSTID = CUSTID)
- 1:N joins only
! Complex joins (TRAN_DATE between
STARTDATEID and ENDDATEID)
- also supports 1:1, O:1, 1:O etc
Important to create physical joins
before importing in to logical layer
! Logical joins rely on physical joins
to define paths
! Makes life a lot simpler
Create joins using Join Manager,
Step 3: Mapping the Logical Model to the Physical Model(s)
Once you have your logical model and one or more physical models, you can map them
together
! The simpler the mapping, the better
Drag and drop physical columns
on to the logical model
Logical model will inherit
physical data types
Logical Table Sources
Logical tables can have more than one physical source
Can create >1 Logical Table Source
! BI Server creates two physical queries
! Useful when mapping data from
different levels
! and when using fragmentation
Each Logical table source can have
>1 table mapped
! BI server creates one query per LTS, joining
as per physical foreign key joins
! Used when you need columns from other
joined tables in your logical table
(join only happens if additional
columns requested)
Consider Where to Join Data
Again, consider where to integrate and join data
Whilst the BI Server can join data, it may be faster to load into a data mart
! ETL tools can integrate data at time of load
! Denormalized data structures can be faster than joining at report time
! Indexing, Summary Management, Query Optimization
Creating a data warehouse still is the optimal solution
! BIEE data source joining features are most appropriate when bringing
new data in thats not yet in the data warehouse
Logical Join Types
Logical tables are by default not joined
Logical layer supports both foreign key
and complex joins
Foreign key joins not recommended
! Restrict choices that BI server
can make over join paths
! Only there for backward compatibility
Complex joins are preferred
! Indicates relationship between
tables
! Allows BI Server to determine
best join path
- Useful when more than one
Logical Table Source
Step 4: Create Initial Calculations
Calculations are created as additional logical columns
Sit alongside existing logical columns derived from physical layer
Calculations can also
be created within report
OBIEE SQL and the Expression Editor
Calculations within the repository are defined using the Expression Editor
Uses OBIEE SQL Syntax
Reference functions,
expressions, logical
columns, constants,
variables
Same SQL syntax across
all supported databases
Ability to pass-through
function calls using
EVALUATE function
Create Calculations in the Optimal Location
Whilst the BI Server can create calculations, it may be more appropriate
to do this in the underlying database
! Oracle Database analytic functions (LAG, LEAD, RANK etc)
! Oracle Database OLAP functions (time-series, forecast, allocation)
Use the available architecture efficiently
! Perform calculations as close to the source data as possible
! Use dedicated OLAP technology if available
! Use BI Server to provide features not found in the sources
Just because the BI Server can do something, doesnt mean it should do something
Step 5: Create Dimensions and Hierarchies
Dimensions define hierarchical relationships between columns
! Also used when defining level-based measures
and summaries
Level-based, starts with Grand Total level
! One-way export out to Oracle dimensions (DDL)
also possible
Enables hyperlinks on columns within
dimension levels
! Drill-down through the hierarchy
! No drill-up or drill to related (yet)
Step 6: Create Initial Presentation Models
Business models themselves are not visible to users
! Users see presentation models whose columns are
defined in business models.
! Appear as subject areas
in the Oracle BI Answers
! Appear as databases to
client tools using ODBC
Can create multiple
Presentation Catalogs from
single Logical Model
Step 7: Creating Time Dimension and Time-Series Calculations
OBIEE 10.1.3.2 supports limited time-series functions
AGO value of a measure x months, quarters, years ago
AGO(Videostore."Sales fact view".Sales, Videostore.TimesDim."Month", 1)

TODATE value of a measure to the end of a month, quarter, year
AGO(Videostore."Sales fact view".Sales, Videostore.TimesDim."Quarter", 1)
Requires at least one time dimension in the
metadata layer
! Requires at least one or more Chronological keys
! Monotonically increasing value (DAY etc)
Data Modeling Issues #1: Circular Joins
Data in your physical source system may use circular joins
! Valid in an OLTP system, and in tools such as Discoverer
! Causes issues in tools such as OBIEE as join path cannot be circular
Resolving Circular Joins : Creating Alias Tables
In this example, dimension information is held in three tables
! Employees, departments, regions
! Employees doubles-up as a table that provides details on regional managers as well
Solution is to create an alias for the employee table and join this to region instead
Resolving Circular Joins : Mapping the Logical Table Source
Once revised physical model, including alias table is created, the logical dimension table
can be created
Logical Table Source is then mapped to the revised physical tables
Circular join is removed, RPD is now valid
Data Modeling Issues #2: Fan Trap Queries
Caused when one master table (i.e. a dimension) joins to two fact tables (sales, budget)
You would expect the aggregations on each table to be correct, however regular
SQL queries can over-count totals due to cartesian joins forming
Known in the Discoverer world as fan trap queries
SQL> select a.acc_name,
2 sum(sales),
3 sum(budget)
4 from fan_trap_accounts a, fan_trap_sales s, fan_trap_budget b
5 where a.acc_id = s.acc_id
6 and a.acc_id = b.acc_id
7 group by a.acc_name
8 order by a.acc_name
9 /
ACC_NAME SUM(SALES) SUM(BUDGET)
-------------------- ---------- -----------
ACCOUNT1 900 1050
ACCOUNT2 130 200
ACCOUNT3 600 750
ACCOUNT4 600 600
Automatic Fan Trap Query Resolution
The Oracle BI Server automatically detects fan trap queries, and generates two
separate SQL queries which it combines at the BI Server level
Solves issue, functionally identical, but not quite as efficient as Discoverer
! Two SQL queries vs. one, and join done in BI Server memory
-------------------- Sending query to database named ora11g (id: <<2653>>):
select T6678.ACC_NAME as c1,
sum(T6685.SALES) as c2
from
CUST_ORDER_HISTORY.FAN_TRAP_ACCOUNTS T6678,
CUST_ORDER_HISTORY.FAN_TRAP_SALES T6685
where ( T6678.ACC_ID = T6685.ACC_ID )
group by T6678.ACC_NAME
order by c1
+++Administrator:2a0000:2a0001:----2008/08/26 17:24:48
-------------------- Sending query to database named ora11g (id: <<2690>>):
select T6678.ACC_NAME as c1,
sum(T6681.BUDGET) as c2
from
CUST_ORDER_HISTORY.FAN_TRAP_ACCOUNTS T6678,
CUST_ORDER_HISTORY.FAN_TRAP_BUDGET T6681
where ( T6678.ACC_ID = T6681.ACC_ID )
group by T6678.ACC_NAME
order by c1
Data Modeling Issues #3 : Single Table Source
Reasonably common requirement
! Typically the first source someone will bring into BI EE
! Also applies for Oracle OLAP 10g
Concept can be reused in many implementations
2 approaches are commonly used
! Use aliases on the source tables (potentially has pitfalls)
! Non-Aliasing LTS approach & advantages
ORDER_ID ORDERDATE STATUS PRICE
Single Table Souce
Single Table RPD Design - Physical Source
Source
! Orders table from OE schema
BI EE requires
! At least one Fact logical table
! At least one Dimension logical table
ORDER_ID ORDERDATE STATUS PRICE
PRICE
ORDERS
FACT
ORDER_ID
ORDERDATE
STATUS
ORDERS
DIMENSION
Single Table Souce
Logical Dimensional Model
Single Table RPD Design - Common Approach
Alias
! Similar to Aliasing Tables in SQL
Create a Dimension Alias
Create a Fact Alias
Join the aliases on a common key (Order Id)
Source Table
ORDER_ID
ORDERDATE
STATUS
ORDER_ID
PRICE
Dimension
ORDER_ID
ORDERDATE
STATUS
ORDER_ID
Fact
PRICE
Dimension Alias
Fact Alias
Design BMM Layer
! Dimension logical table - Dim Orders Alias
! Fact logical table - Fact Orders Alias
Dimension
ORDER_ID
ORDERDATE
STATUS
ORDER_ID
Fact
PRICE
Dimension Alias
Fact Alias
Dimension Logical Table
Fact Logical Table
Physical Layer
BMM Layer
Source Table
ORDER_ID
ORDERDATE
STATUS
ORDER_ID
PRICE
Disadvantages
! The SQL fired will contain self-joins
! Can degrade performance for big tables (like Orders etc)
Advantages
! Approach recommended for role-playing dimensions
select T29596.ORDER_ID as c1,
sum(T29605.PRICE) as c2
from
ORDERS T29596 /* Dim Orders */ inner join
ORDERS T29605 /* Fact Orders */ On T29596.ORDER_ID =
T29605.ORDER_ID
group by T29596.ORDER_ID, T29596.ORDER_TOTAL
order by c1, c2
Single Table RPD Design - New Approach - Classification
Aggregating Attributes
! Order Price
! Number of Orders (custom derived metric)
Non-Aggregating Attributes
! Order Date
! Order Id
! Order Status
! Comments
Dimension Logical Table
Fact Logical Table
Physical Layer
BMM Layer
Dimension
ORDER_ID
ORDERDATE
STATUS
ORDER_ID
Fact
PRICE
Source Table
ORDER_ID
ORDERDATE
STATUS
ORDER_ID
PRICE
Single Table RPD Design - BMM Design
In Non-Aggregating Attributes
! Identify Potential hierarchies
One hierarchy on Order Date
! Year -> Month -> Order Date
Start with a skeletal BMM design
! One logical table for Aggregating Attributes
! Multiple logical tables for Non-Aggregating Attributes
- Determined by number of potential hierarchies
Single Table RPD Design - BMM Design
For each logical table created
! Same physical source will be used in LTS
2 dimension logical tables
! Orders - For all Orders related attributes
! Order Date - For providing Order Date analysis hierarchy
1 Fact logical table
Single Table RPD Design - Queries
Reports created will always use only the single table modeled
No inner joins
Most common use case
! Modeling date hierarchies
! In some cases dates are stored as degenerate facts
! BI EE can be used to model them as dimensional hierarchies
select T17214.ORDER_ID as c1,
T17214.ORDER_TOTAL as c2,
sum(T17214.ORDER_TOTAL) as c3
from
ORDERS T17214
group by T17214.ORDER_ID, T17214.ORDER_TOTAL
order by c1, c2
Data Modeling Issues #4 : Fact Tables with Differing Granulatity
Most common scenario in a DW implementation
! Multi-Grain Facts
- Multiple Fact tables
- Multiple Dimensions
- Each Fact table joining to different set of dimensions
! Fact attributes as Dimensions
Multi Grain Facts - Example
2 Orders table
! ORDERS_SOLD
- Holds all the Orders Sold
- Also recorded is the Salesperson
! ORDERS_RETURN
- Holds all the returned orders
- Also holds the Return Reason
Reporting Requirement
! To find all orders returned
- By SalesPerson
- By Return Reason
- Both Sales Person & Return Reason
ORDERS_SOLD
ORDERS_RETURN
Date
Order
Sales Person
Return Reason
Only link between the 2 tables is through Order Id
Joins across fact tables not recommended
Leverage BI EE Conforming dimensions
Model Order Id as a Conforming dimension
Multi Grain Facts - Physical Layer
Both Fact tables joined to respective dimensions
No joins made between fact tables
Multi Grain Facts - BMM Design
Create logical table for Orders
! Map both the fact table Order Ids to this dimension
! Also map the matching Order attributes
Make Order Id as the table key
Create 2 separate fact tables
! One for ORDERS_SOLD
! Other for ORDERS_RETURN
Map the measure columns to the source columns
Create 2 new logical tables (each degenerate dimension)
! One for Return Reason
! The other for Sales Person
Model them as dimensions
Create 2 step hierarchies for both the dimensions
In each fact table
! Map each measure to the Total level of non-conforming dimension
! All Measures in ORDERS_SOLD
- Total Level of Return Reason
! All Measures in ORDERS_RETURN
- Total Level of Sold By
Multi Grain Facts - Queries
BI Server will join queries across fact tables
Will use Conforming Dimension based join
Queries will be fired separately to each fact table
OBIEE Software Configuration Management
UKOUG OBIEE Masterclass 2009
Managing Releases and OBIEE Development
OBIEE projects typically have DEV, TEST and PROD environments
How do we succesfully migrate projects between environments?
How do we handle incremental changes to the project?
How do we version releases of the project?
How do we manage project branching and merging?
The BI Server Repository file (RPD file)
The BI Presentation Server Web Catalog file (webcat)
Various Server Configuration files
Various Artifact files
Various web configuration CSS files etc
Elements to be Managed within an OBIEE Project
Do an initial release of the whole project
Do subsequent releases (or enable small updates to the project)
Branch elements, or the whole project, and then merge the changes back in
Version the project using a tool such as Subversion
Typical OBIEE Project SCM Tasks
Simple Project Architecture (Repeat for TST, UAT etc)
DEV Server
Presentation
Server
BI Server
PROD Server
Presentation
Server
BI Server
Release
Promotion
Viewing Reports
Creating Reports
Developing System
Promoting Changes
1. Copy whole RPD to TEMP directory
2. Archive shared and user areas of web catalog to TEMP using Catalog Manager
3. Gather other file artifacts to TEMP directory, ZIP and transfer to target server
4. Copy source files to correct locations on target server
5. Create new web catalog on target server
6. Unarchive shared and user web catalog archives to new web catalog
7. Update connection pool settings on target server
8. Make target RPD read-only
9. Restart target BI Server and Presentation Server
Promoting the initial release : DEV to PROD
Initial Release Flowchart
S
t
a
r
tCopy RPD from
DEV to Temp Folder
Zip up Webcat from
DEV, copy into
Temp Folder
Gather additional
config, CSS etc files
from DEV into Temp
Folder
Copy files across to
PROD server
Copy files across to
PROD server
Copy files in Temp
folder to relevant
locations
Update PROD
connection pool
settings
Make PROD RPD
read-only
Restart PROD
BI and Presentation
Servers
Test
E
n
d
Promoting the initial release Step 1 : Copy RPD to TEMP Dir
Create a temporary directory to hold all release files
Show down BI Server if RPD is running online
Copy RPD file to temporary directory
Promoting the initial release Step 2 : ZIP Webcat to TEMP
Locate webcat in $ORACLEBIDATA/web/catalog
Zip it up (or otherwise archive it)
Copy file to TEMP directory
Promoting the initial release Step 3 : Gather File Artifacts to TEMP
Gather additional file artifacts to TEMP directory
!
$ORACLEBI/server/config/*.*
!
$ORACLEBIDATA/web/config/
instanceconfig.xml
!
xdo.cfg
!
$ORACLEBI/web/javahost/
config/config.xml
!
$ORACLEBI/xmlp/XMLP/Users
!
$ORACLEBI/xmlp/XMLP/Reports
This consitutes the initial release
ZIP up the directory and FTP to target
server
Promoting the initial release Step 4 : Copy files to Target Locations
Stop BI Server, Presentation Server, OC4J
Migrate any database data (exp, dpexp etc)
Copy all files back to appropriate locations
!
$ORACLEBI/server/config/*.*
!
instanceconfig.xml
!
xdo.cfg
!
$ORACLEBI/web/javahost/
config/config.xml
!
$ORACLEBI/xmlp/XMLP/Users
!
$ORACLEBI/xmlp/XMLP/Reports
Check that all file locations in config files are correct (cache path etc)
Update config files to reflect new machine naming etc (or use perl/awk etc)
Promoting the initial release Step 5 : Unzip the Webcat
Unzip the Web Catalog from the ZIP file
Copy to the target location
Ensure instanceconfig.xml points to this new folder
Promoting the initial release Step 6 : Update DB Passwords
RPD Connection Pool settings contain
DB passwords
Will need to update if PROD passwords
are different to DEV
Either perform manually using
Administration Tool
Undocumented API for Administration Tool
makes scripted update possible
Save changes after update
Promoting the initial release Step 7 : Make RPD Read-Only
Use Operating System tools to make the target RPD read-only
Prevents accidental changes
to the repository
RPD changes are only made
in DEV, and then promoted to PROD
Important : Make copy of RPD, use
this as the baseline for subsequent
three-way merges (incremental
updates to RPD)
Promoting the initial release Step 8 : Restart Pres. Serv. & OC4J
Restart Oracle BI Server service
Restart Oracle BI Presentation Server service
Restart OC4J, Java Host etc
services
! or Unix/Linux equivalents
(Optionally) Create New Reports in Production
New reports can either be created in development
! Typically used when reports depend on new RPD items
! Also used when all reports created as a package and then released
Or they can be created in production
! Usual approach, assumes no further development involvement
Changes to the RPD will need to be packaged as releases
Reports can either be developed in PROD, or developed in DEV if reliant on new RPD
features and included in the release
RPD files need to be copied in entirety, and either overwrite PROD RPD or three-way
merged
Updated Web Catalog folders can be copied using Catalog Manager, or individual
reports can be copied using Content Accelerator Framework
Copy across any artifact files (changed config files etc) if needed
PROD user directories are usually excluded from any updates, overwrites etc
Handling Subsequent Releases
Subsequent Release Flowchart
Has
development
happened
in PROD
RPD?
S
t
a
r
t
3-Way Merge
DEV and PROD
RPD
Yes
Copy across
DEV RPD
to prod server
No
Are we
copying and
entired webcat
folder?
Yes
Do
reports
use calculations
not in DEV
webcat?
Use Catalog
Manager cut
and paste
between DEV
and PROD
Use Catalog
Manager CAF
to clone report +
RPD calculations
Yes
No
E
n
d
Test
Incremental Release Scenario
There are DEV and PROD environments
After initial deployment, users have developed new reports in PROD
Now some RPD updates have happened in DEV, together with some new reports
These need to be transferred to PROD, whilst preserving what is already in PROD
Uses the following techniques and utilities
! Three-Way RPD Merge
! Content Accelerator Framework
Incremental Release Step 1 : Select Three-Way RPD Merge
If no changes have been made to the RPD in PROD,
the DEV RPD can be copied across and
used to replace the PROD one
Otherwise a three-way merge will be required
! Usually the safest approach regardless
! Preserves changes in PROD RPD
! Highlights changes to be introduced
in DEV RPD
! Replaces Import from Repository
- Now deprecated
Three-Way Merge : Conceptual
Standard concept in software configuration management
Allows development to be concurrent, as opposed to serial
Concurrent development allows changes to the same file by multiple developers
Works by merging and reconciliation
! Most merges should not conflict
! Those that do, prompt manual
intervention
Three-Way Merge creates a fourth file,
based on second and third files
baselined against their
common parent
Original File
Merged File
Version 1
+
Version 2
File Version 2 File Version 1
Three-Way Merge : Applied to OBIEE
Same concept applied to OBIEE
RPD is the file that is being merged
Oracle BI Administrator tool performs
merge, compares changes, provides
interface for manual resolution of
conflicts
Original RPD
Merged RPD
Current RPD
+
Modified RPD
Modified RPD Current RPD
Three-Way Merge : With No Parent (i.e. Two-Way Merge)
Equivalent to deprecated Import from Repository
Merges two RPDs with no common parent
Relies on a blank RPD with no metadata to
perform role of Original RPD
! BI Administrator will see all objects in
DEV RPD as new
! Select existing PROD RPD to merge into
- System will ask for Decision on which
Presentation Catalogs (and related
objects) to merge
- Choose Current to merge
- Choose Modified (D) to ignore
Blank RPD
New Combined RPD
Project 1 RPD
+
Project 2 RPD
Project 2 RPD Project 1 RPD
Incremental Release Step 2 : Gather RPDs for Three-Way Merge
Requires three RPD files
! The original RPD after initial project deployment (analyticsproject_original.rpd)
! The Development RPD (analyticsproject_dev.rpd)
! The existing Production RPD (analyticsproject_prod.rpd)
Copy all three into a common directory
Incremental Release Step 2 : Open Admin Tool and DEV RPD
Open BI Administration Tool
Open the Production RPD in offline mode
Incremental Release Step 3 : Start Merge, select Blank RPD
Select File > Merge from BI Administrator menu
Choose the baseline (analyticsproject_original.rpd) RPD as the original RPD
Incremental Release Step 4 : All DEV Objects Marked as New
Compared to the original RPD (the baseline), on first incremental update
nothing will have changed
After this updates, the changes
we introduce from DEV will
mean that this screen will
in future show changes
vs. the baseline RPD
Incremental Release Step 5 : Select DEV RPD as Modified RPD
For the modified RPD, select the DEV one (analyticsproject_dev.rpd)
The compare will probably show no conflicts, if there is just a single workstream
Press Stats... button to see how
many new items will be added
Incremental Release Step 6 : Select Name for New PROD RPD
Modify the name for the new PROD RPD (analyticsproject_prod_new.rpd)
This will contain the merged
RPD items
Press Merge button to
create the merged RPD
Incremental Merge of Web Catalog Entries
Now that the RPD changes have been migrated, we can now look at the webcat
There are three options for moving across webcat content
! Use Catalog Manager to copy across whole folder (Shared etc)
! Use Content Accelerator Framework to copy across individual reports
! Use Catalog Manager Three-Way Merge
Development Webcat Production Webcat
The Catalog Manager
Java Utility for maintaining the web catalog
Preserves permissions, supported way of manipulating Web Catalog
Change permissions, view properties
Three-way Web Catalog merge
Create new Catalogs
Archive and Unarchive
The Catalog Manager : Archiving and Unarchiving Catalogs
1
2
3
The Catalog Manager : Viewing and Changing Permissions
Select object to view/change permissions on
Right-click and select Permissions
Uncheck Show groups only
to see users as well
Use shuttle buttons to add or
remove user/group permissions
The Catalog Manager : Viewing and Changing Properties
Select object to view/change permissions on
Right-click and select Properties
Use dialog to change ownership,
make item hidden, view/copy XML
Using Catalog Manager to Copy Folders and Reports
Open two copies of the Catalog Manager
Right-click on object to be copied, select Copy,
Move to second Catalog Manager, select Paste
Warning : will overwrite whole folder. Do not copy whole webcat incl. System folder,
only copy Shared and Users
Performing a Webcat Three-Way Merge using Catalog Manager
The Catalog Manager has a three-way merge feature as well
Not recommended, not as clean a merge as the RPD merge
Not a generally used way of upgrading web catalogs
The Content Accelerator Framework
Plug-in for the Catalog Manager
Copies reports from one webcat
to another
Maps source and target columns
Creates calculated columns as required
Synchronizes webcats and RPDs
across environments
Downloadable from OTN
Useful for migrating individual
reports and any calculations they
are dependent on
! More complicated than
Catalog Manager cut-and-paste,
requires copies of RPDs
Installing the Content Accelerator Framework : Step 1
Download from OTN
Unzip to the $ORACLEBI directory
Run the CAFV102_Install.bat batch file
Edit ContentAccelerator.Properties
1
2
3
Incremental Release Step 7 : Start CAF, Select Report to Clone
Start Catalog Manager
Connect to DEV webcat
Select report you wish to
clone to PROD
Incremental Release Step 8 : Select DEV and PROD Webcat + RPD
Select offline copies of DEV and PROD RPDs
Select online copy of PROD webcat
Enter relevant passwords for DEV and PROD
Select Subject Area on which the report is based
Incremental Release Step 9 : Map DEV columns to PROD
Map columns in DEV RPD to PROD RPD
Required for full logical columns
! If not present, will need to be
brought across using 3-Way RPD
Merge
Calculated columns will be created
by CAF
Mapping can be saved to CSV file
Incremental Release Step 10 : Select PROD Webcat Path
Select path in PROD webcat to create new report in
Choose whether to create dashboard for report
Choose whether to perform consistency check on updated PROD RPD
Press Finish to start CAF process
Incremental Release Step 11 : Review Updated Webcat + RPD
PROD RPD will have any required calculated logical columns added
PROD webcat will have the new report added to /shared/cloned
OBIEE project may be branched for several reasons
! To perform an emergency fix
! To have separate development teams working on separate projects
! To permit concurrent development of separate areas
OBIEE has two main capabilities in this area
! Three-way merge
! Multi-User Development
Does not handle source control, but handles splitting/merging of code branches
Project Branching
Merged RPD
Current RPD
+
Modified RPD
Modified RPD
Original RPD
Updated Original
RPD
Modified RPD
Code Branch
Code Merge
Multi-User Development Example
Existing RPD is to be split into two projects (branches)
Project 1 will maintain ITEMS fact table
Project 2 will maintain RETURNS fact table
Multi-User Development will be used to handle separate projects
Multi-User Development Step 1 : Define Projects in Master RPD
Connect to RPD (online or offline)
Define projects based on selection of fact tables, init blocks, users etc
1
2
3
4
Multi-User Development Step 2 : Copy Master RPD to Shared Drive
Create shared directory accessible to all developers
Copy master copy of RPD with projects defined, to this directory
Multi-User Development Step 3 : Configure Admin Tool for MUDE
Each developer workstation has to be prepared for multiuser development
Tools > Options > Multiuser
Set location of shared network drive
Set full name of developer
(for audit logs)
Once set, Multiuser Development
Option now available in menu
Multi-User Development Step 4 : Check Out Project
Projects are checked out from the BI Administrator menu
Prompted to select project
Project RPD fragment is then saved to the users local /Repository directory
1
2
3
4
Multi-User Development Step 5 : Work with RPD Subset
Developer then works with RPD subset locally
All changes are made to this RPD fragment
Contains just the items required for this project
Local $ORACLEBI/server/repository directory contains subset RPD, plus original
copy of this RPD (for
comparison purposes)
Multi-User Development Step 6 : Report on Changes Made
Select File > Multiuser > Compare with Original to identify changes made
compared to original RPD extract
Multi-User Development Step 7 : Start RPD Merge Process
Select File > Multiuser > Merge Local Changes to apply changes back to local original
RPD fragment
Multi-User Development Step 8 : Complete RPD Merge Process
Merge is performed using Three-Way Merge facility
Any conflicts are highlighted, to be resolved manually
But there shouldnt be any, as you are merging back to your own local copy
Multi-User Development Step 9 : Copy Back to Master RPD
Final step is to copy your updated, original RPD fragment back to the master RPD
Select File > Multiuser > Publish to Network
to copy back to master RPD
All local RPD fragments will then be deleted
Check out the project again to make
further changes
Source Control
The are no built-in source control features in Oracle BI Enterprise Edition
It is however possible to store the RPD, Webcat, configuration files in a system
such as Subversion, CVS etc
Due to nature of RPD, webcat etc, it is only safe to copy the entire RPD, and
the archived webcat (Users, Shared), to source control
! Uploading fragments of the webcat, UDML not supported
! Config files etc safe to upload individually
Using SVN With OBIEE Step 1 : Create SVN Folders
Use a tool such as VisualSVN Server to create an SVN folder
structure for OBIEE
Follow standard SVN format of branch, trunk and tags folders
! Enables branching of code etc
Create folders for RPD, webcat,
configuration files
Create folders for DAC, INFA etc
if using BI Applications
Using SVN With OBIEE Step 2 : Checkout Folders Locally
Using a tool such as TortoiseSVN, check out a local copy of the SVN folders
1
2
3
Using SVN With OBIEE Step 3 : Copy RPD into SVN Folders
Copy RPD file into SVN
folder structure
! Copy offline with all
changes saved
Possible to copy UDML
fragments, but not supported
or recommended
Using SVN With OBIEE Step 4 : Copy Webcat into SVN Folders
Only supported webcat archive mechanism is through Catalog Manager
! Do not try to upload individual files, reports, folders
Only archive the Users and Shared folders
! System folders permissions do not transfer properly to other webcats
Using SVN With OBIEE Step 5 : Copy Config Files to SVN Folders
Copy any additional files to the SVN folders
! Configuration files
! CSS files, graphics etc
! Writeback files
! Any other artifacts
Using SVN With OBIEE Step 6 : Commit Files to SVN Repository
Commit files to SVN repository, selecting any files new to SVN
1
2
3
Using SVN With OBIEE Step 7 : Update Local Copy from SVN
Subsequently, any developers local copy of the SVN repository can
be checked for updates
Copies down any new files from the SVN repository
Using SVN With OBIEE Step 8 : Download New Local Copy
Developers who do not have a local copy can create one from SVN
Copies complete SVN folder structure
Can select HEAD revision, or a particular revision number
1
2
3
Using SVN With OBIEE Step 9 : OBIEE Files Under SVN Versioning
All files within folder structure are now under SVN versioning
Copy to relevant location after checkout, edit using BI Administration Tool,
Catalog Manager etc, then copy back to SVN folders and commit
Further Reading & Questions
Visit our website at http://www.rittmanmead.com
More OWB articles available at http://www.rittmanmead.com/owb
Articles and presentations available at http://www.rittmanmead.com/articles
Contact me at mark.rittman@rittmanmead.com
Visit us at Stand 50 at the Exhibition
Ask me questions now
Thank you for attending
Mark Rittman, Director, Rittman Mead
Venkatakrishnan Janakiraman, Principal Consultant, Rittman Mead
OBIEE Masterclass 2009

RITTMANMEAD OBIEE Masterclass

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

RITTMANMEAD OBIEE Masterclass

Uploaded by

Copyright:

Available Formats

T : +44 (0) 8446 697 995 or (888) 631 1410 (USA) E : enquiries@rittmanmead.com W: www.rittmanmead.

You might also like