RITTMANMEAD_OBIEE_Masterclass

8/12/2019 RITTMANMEAD_OBIEE_Masterclass

1/118

T : +44 (0) 8446 697 995 or(888) 631 1410 (USA) E : [email protected] W: www.rittmanmead.com

Mark Rittman, Director, Rittman MeadVenkatakrishnan Janakiraman, Principal Consultant, Rittman Mead

OBIEE Masterclass 2009

Wednesday, 2 December 2009
http://www.rittmanmead.com/http://www.rittmanmead.com/mailto:[email protected]:[email protected]


2/118

T : +44 (0) 8446 697 995 E : [email protected] 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.comand now athttp://www.rittmanmead.com/blog

http://www.rittmanmead.com/http://www.rittmanmead.com/bloghttp://www.rittmanmead.com/bloghttp://www.rittmanmead.com/bloghttp://www.rittmanmead.com/http://www.rittmanmead.com/


3/118


Rittman Mead Consulting

Oracle BI&DW Project Specialists

Consulting, Training, Support

Works with you to ensure OBIEE andOracle BI Applications project success

Small, focused team

OWB, Oracle BI, DW technicalspecialists

Clients in the UK, Europe, USA

http://www.rittmanmead.com/http://www.rittmanmead.com/


4/118


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 projectsThis 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



5/118


OBIEE Data Modeling

UKOUG OBIEE Masterclass 2009



6/118


Oracle Business Intelligence Enterprise Edition



7/118


Web Server

(IIS, Tomcat, Websphere, iPlanet)

Oracle BI ServerOracle BI Server

Intelligent Request GenerationIntelligent Request Generation

Data Source AdaptersData Source Adapters

NavigatorNavigator

Logical Request GenerationLogical Request Generation

Aggregate

Navigator

Fragmentation

Optimization

Multi-Pass /

Sub-Request Logic

Optimized Query RewritesOptimized Query Rewrites

Session ManagementSession Management

MetadataInterchange

MetadataInterchange

Logical SQL ODBC/JDBC (Logical Business Model)Logical SQL ODBC/JDBC (Logical Business Model)

CacheCache

ServicesServices

Oracle BI AdministrationOracle BI Administration

Analytical and Operational Data Sources

Metadata Documentation ServicesMetadata Documentation Services

Metadata Management ServicesMetadata Management Services

Multi-User Development ServicesMulti-User Development Services

Server Management ServicesServer Management Services

ODBC over TCP/IP (SSL)

System/

System/

Perf

PerfMo

nitoring

Mo

nitoring

ODBC, CLI, OCI, XML, MDX

Oracle BI Presentation ServicesOracle BI Presentation Services

SOAP Web Services, XML and URL InterfaceSOAP Web Services, XML and URL Interface

Cache Services (Web) & ConnectionCache Services (Web) & Connection MngmtMngmt

XMLXMLFrameworkFramework

WebWebCatalogCatalogServiceService

User Profiling, Security and SessionUser Profiling, Security and Session MngmtMngmt

Oracle InteractiveOracle InteractiveDashboardsDashboards

Oracle AnswersOracle Answers

Load BalancerLoad Balancer

SecurityServic

es

SecurityServic

es

QueryGovern.

QueryGovern.

TCP/IP

(SSL)

Javascript

for Usability & Interactivity

Web Browser

XML, HTML,XLS, PDF, TXT

overHTTP/HTTPS

External Applications and Portals

HTML, SOAP

overHTTP/HTTPS

Execution EngineExecution Engine

SAW Bridge (J2EE/ISAPI)SAW Bridge (J2EE/ISAPI)

TCP/IP (SSL)Oracle BI PublisherOracle BI Publisher

Delivery ServerDelivery Server

Layout InterfacesLayout Interfaces

Data LogicData LogicXSL

Externalized

AuthenticationLDAP

DB Authentication

Custom Authenticator

Oracle BIOracle BI

Cluster ControllerCluster Controller

Oracle Delivers ServerOracle Delivers Server

Scheduling/Event ServicesScheduling/Event Services

Agent Execution LogicAgent Execution Logic

Device Adaptive ContentDevice Adaptive Content

OBIEE 10.1.3.2 Architecture



8/118


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 SQLin to optimized, physical SQL



9/118


Data Access

Reporting data may be sourced frommultiple 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 alogical business model

! Facts

!Dimensions



10/118


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, securityModel once, deploy anywhere

Across any data source

Model First development



11/118


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 usingthe 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 canbe faster to query

MDX (OLAP, Multi-dimensional) data is converted intoRDBMS row-sets

In this presentation, we will look at how you can use thedata modeling features of OBIEE to create logical star schemas



12/118


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



13/118


Sample Business Model



14/118


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 dimensions6.Create initial presentation model

7.Create complex calculations, time dimensions etc

8.Add additional columns to presentation model



15/118


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



16/118


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 tablesStart 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



17/118


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 sourceDefine keys, foreign keys if needed

Update row counts

Define table aliases



18/118


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 joinsbefore importing in to logical layer

! Logical joins rely on physical joinsto define paths

!Makes life a lot simpler

Create joins using Join Manager,



19/118


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 themtogether

! The simpler the mapping, the better

Drag and drop physical columnson to the logical model

Logical model will inheritphysical data types



20/118


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, joiningas per physical foreign key joins

!

Used when you need columns from otherjoined tables in your logical table(join only happens if additionalcolumns requested)



21/118


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 OptimizationCreating a data warehouse still is the optimal solution

!BIEE data source joining features are most appropriate when bringingnew data in thats not yet in the data warehouse



22/118


Logical Join Types

Logical tables are by default not joined

Logical layer supports both foreign keyand complex joins

Foreign key joins not recommended

!Restrict choices that BI servercan make over join paths

!Only there for backward compatibility

Complex joins are preferred

! Indicates relationship betweentables

!

Allows BI Server to determinebest join path

- Useful when more than oneLogical Table Source



23/118


Step 4: Create Initial Calculations

Calculations are created as additional logical columns

Sit alongside existing logical columns derived from physical layer

Calculations can alsobe created within report



24/118


OBIEE SQL and the Expression Editor

Calculations within the repository are defined using the Expression Editor

Uses OBIEE SQL Syntax

Reference functions,expressions, logicalcolumns, constants,variables

Same SQL syntax acrossall supported databases

Ability to pass-throughfunction calls usingEVALUATE function



25/118


Create Calculations in the Optimal Location

Whilst the BI Server can create calculations, it may be more appropriateto 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 cando something, doesnt mean it shoulddo something



26/118


Step 5: Create Dimensions and Hierarchies

Dimensions define hierarchical relationships between columns

!Also used when defining level-based measuresand summaries

Level-based, starts with Grand Total level

!One-way export out to Oracle dimensions (DDL)also possible

Enables hyperlinks on columns withindimension levels

!Drill-down through the hierarchy

!No drill-up or drill to related (yet)



27/118


Step 6: Create Initial Presentation Models

Business models themselves are not visible to users

!Users see presentation models whose columns aredefined in business models.

!Appear as subject areasin the Oracle BI Answers

!Appear as databases toclient tools using ODBC

Can create multiplePresentation Catalogs fromsingle Logical Model



28/118


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 themetadata layer

!Requires at least one or more Chronological keys

!Monotonically increasing value (DAY etc)



29/118


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



30/118


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



31/118


Resolving Circular Joins : Mapping the Logical Table Source

Once revised physical model, including alias table is created, the logical dimension tablecan be created

Logical Table Source is then mapped to the revised physical tables

Circular join is removed, RPD is now valid



32/118


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 regularSQL 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 b5 where a.acc_id = s.acc_id6 and a.acc_id = b.acc_id7 group by a.acc_name8 order by a.acc_name9 /

ACC_NAME SUM(SALES) SUM(BUDGET)-------------------- ---------- -----------ACCOUNT1 900 1050

ACCOUNT2 130 200ACCOUNT3 600 750ACCOUNT4 600 600



33/118


Automatic Fan Trap Query Resolution

The Oracle BI Server automatically detects fan trap queries, and generates twoseparate 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: ):

select T6678.ACC_NAME as c1, sum(T6685.SALES) as c2from CUST_ORDER_HISTORY.FAN_TRAP_ACCOUNTS T6678, CUST_ORDER_HISTORY.FAN_TRAP_SALES T6685where ( T6678.ACC_ID = T6685.ACC_ID )group by T6678.ACC_NAMEorder by c1

+++Administrator:2a0000:2a0001:----2008/08/26 17:24:48

-------------------- Sending query to database named ora11g (id: ):

select T6678.ACC_NAME as c1, sum(T6681.BUDGET) as c2from CUST_ORDER_HISTORY.FAN_TRAP_ACCOUNTS T6678, CUST_ORDER_HISTORY.FAN_TRAP_BUDGET T6681where ( T6678.ACC_ID = T6681.ACC_ID )group by T6678.ACC_NAMEorder by c1

mailto:[email protected]://www.rittmanmead.com/http://www.rittmanmead.com/mailto:[email protected]:[email protected]


34/118


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

Single Table Souce



35/118


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

Single Table Souce

Logical Dimensional Model



36/118


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) Dimension Alias

Fact Alias



37/118



Design BMM Layer

!Dimension logical table - Dim Orders Alias

! Fact logical table - Fact Orders Alias

Dimension Alias

Fact Alias

Dimension Logical Table

Fact Logical Table

Physical Layer BMM Layer



38/118



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 c2from

ORDERS T29596 /* Dim Orders */ inner join ORDERS T29605 /* Fact Orders */ On T29596.ORDER_ID =T29605.ORDER_IDgroup by T29596.ORDER_ID, T29596.ORDER_TOTALorder by c1, c2



39/118


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

!CommentsDimension Logical Table

Fact Logical Table

Physical Layer

BMM Layer



40/118


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



41/118


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



42/118


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 c3from ORDERS T17214group by T17214.ORDER_ID, T17214.ORDER_TOTALorder by c1, c2



43/118


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



44/118


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



45/118



ORDERS_SOLD

ORDERS_RETURN

Date

Order

Sales Person

Return Reason



46/118



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



47/118


Multi Grain Facts - Physical Layer

Both Fact tables joined to respective dimensions

No joins made between fact tables



48/118


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



49/118



Create 2 separate fact tables

!One for ORDERS_SOLD

!Other for ORDERS_RETURN

Map the measure columns to the source columns



50/118



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



51/118



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



52/118


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



53/118


OBIEE Software Configuration ManagementUKOUG OBIEE Masterclass 2009



54/118


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?



55/118


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



56/118


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



57/118


Simple Project Architecture (Repeat for TST, UAT etc)

ReleasePromotion

Viewing Reports

Creating Reports

Developing System

Promoting Changes



58/118


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



59/118


Initial Release Flowchart

Start

End



60/118


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



61/118


62/118


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

!$ORACLEBIDATA/web/config/

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 targetserver



63/118


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/*.*

!$ORACLEBIDATA/web/config/

instanceconfig.xml

!$ORACLEBIDATA/web/config/xdo.cfg

!$ORACLEBI/web/javahost/config/config.xml

!$ORACLEBI/xmlp/XMLP/Users

!$ORACLEBI/xmlp/XMLP/ReportsCheck 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)



64/118


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



65/118


Promoting the initial release Step 6 : Update DB Passwords

RPD Connection Pool settings containDB passwords

Will need to update if PROD passwordsare different to DEV

Either perform manually using

Administration ToolUndocumented API for Administration Tool

makes scripted update possible

Save changes after update



66/118


Promoting the initial release Step 7 : Make RPD Read-Only

Use Operating System tools to make the target RPD read-only

Prevents accidental changesto the repository

RPD changes are only madein DEV, and then promoted to PROD

Important :Make copy of RPD, usethis as the baseline for subsequentthree-way merges (incrementalupdates to RPD)



67/118


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 etcservices

! or Unix/Linux equivalents



68/118


(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



69/118


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 RPDfeatures and included in the release

RPD files need to be copied in entirety, and either overwrite PROD RPD or three-waymerged

Updated Web Catalog folders can be copied using Catalog Manager, or individualreports 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



70/118


Subsequent Release Flowchart

Start

Yes

No Yes

Yes

No

End



71/118


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



72/118


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 andused 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



73/118


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 manualintervention

Three-Way Merge creates a fourth file,based on second and third filesbaselined against theircommon parent



74/118


Three-Way Merge : Applied to OBIEE

Same concept applied to OBIEE

RPD is the file that is being merged

Oracle BI Administrator tool performsmerge, compares changes, providesinterface for manual resolution of

conflicts



75/118


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 toperform 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 whichPresentation Catalogs (and relatedobjects) to merge

- Choose Current to merge

- Choose Modified (D) to ignore



76/118


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



77/118


Incremental Release Step 2 : Open Admin Tool and DEV RPD

Open BI Administration Tool

Open the Production RPD in offline mode



78/118


79/118


Incremental Release Step 4 : All DEV Objects Marked as New

Compared to the original RPD (the baseline), on first incremental updatenothing will have changed

After this updates, the changeswe introduce from DEV willmean that this screen will

in future show changesvs. the baseline RPD



80/118


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 howmany new items will be added



81/118


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 mergedRPD items

Press Mergebutton tocreate the merged RPD



82/118


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



83/118


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



84/118


The Catalog Manager : Archiving and Unarchiving Catalogs



85/118


The Catalog Manager : Viewing and Changing Permissions

Select object to view/change permissions on

Right-click and select Permissions

Uncheck Show groups onlyto see users as well

Use shuttle buttons to add or

remove user/group permissions



86/118


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



87/118


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



88/118


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



89/118


The Content Accelerator Framework

Plug-in for the Catalog Manager

Copies reports from one webcatto another

Maps source and target columns

Creates calculated columns as required

Synchronizes webcats and RPDsacross environments

Downloadable from OTN

Useful for migrating individualreports and any calculations theyare dependent on

!More complicated thanCatalog Manager cut-and-paste,requires copies of RPDs



90/118


Installing the Content Accelerator Framework : Step 1

Download from OTN

Unzip to the $ORACLEBI directory

Run the CAFV102_Install.batbatch file

Edit ContentAccelerator.Properties



91/118


Incremental Release Step 7 : Start CAF, Select Report to Clone

Start Catalog Manager

Connect to DEV webcat

Select report you wish toclone to PROD



92/118


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



93/118


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 bebrought across using 3-Way RPDMerge

Calculated columns will be createdby CAF

Mapping can be saved to CSV file



94/118


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 Finishto start CAF process



95/118


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



96/118


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

Code Branch Code Merge



97/118


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



98/118


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



99/118


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



100/118


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 DevelopmentOption now available in menu



101/118


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 /Repositorydirectory

mailto:[email protected]:[email protected]://www.rittmanmead.com/http://www.rittmanmead.com/http://www.rittmanmead.com/mailto:[email protected]:[email protected]


102/118


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)



103/118


Multi-User Development Step 6 : Report on Changes Made

Select File> Multiuser> Compare with Originalto identify changes madecompared to original RPD extract



104/118


Multi-User Development Step 7 : Start RPD Merge Process

Select File> Multiuser> Merge Local Changesto apply changes back to local originalRPD fragment



105/118


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



106/118


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 Networkto copy back to master RPD

All local RPD fragments will then be deleted

Check out the project again to make

further changes



107/118


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 systemsuch as Subversion, CVS etc

Due to nature of RPD, webcat etc, it is only safe to copy the entire RPD, andthe archived webcat (Users, Shared), to source control

!Uploading fragments of the webcat, UDML not supported!Config files etc safe to upload individually



108/118


109/118


Using SVN With OBIEE Step 2 : Checkout Folders Locally

Using a tool such as TortoiseSVN, check out a local copy of the SVN folders



110/118


Using SVN With OBIEE Step 3 : Copy RPD into SVN Folders

Copy RPD file into SVNfolder structure

!Copy offline with allchanges saved

Possible to copy UDML

fragments, but not supportedor recommended



111/118


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



112/118


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



113/118


Using SVN With OBIEE Step 6 : Commit Files to SVN Repository

Commit files to SVN repository, selecting any files new to SVN



114/118


Using SVN With OBIEE Step 7 : Update Local Copy from SVN

Subsequently, any developers local copy of the SVN repository canbe checked for updates

Copies down any new files from the SVN repository



115/118


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



116/118


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



117/118


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 [email protected]

Visit us at Stand 50 at the ExhibitionAsk me questions now

Thank you for attending

mailto:[email protected]://www.rittmanmead.com/mailto:[email protected]:[email protected]://www.rittmanmead.com/articleshttp://www.rittmanmead.com/articleshttp://www.rittmanmead.com/owbhttp://www.rittmanmead.com/owbhttp://www.rittmanmead.com/http://www.rittmanmead.com/http://www.rittmanmead.com/http://www.rittmanmead.com/mailto:[email protected]:[email protected]


118/118

Mark Rittman, Director, Rittman MeadVenkatakrishnan Janakiraman, Principal Consultant, Rittman Mead

OBIEE Masterclass 2009

RITTMANMEAD_OBIEE_Masterclass

Documents

Transcript of RITTMANMEAD_OBIEE_Masterclass