BI Apps Training Student Guide

Oracle BI Applications 7.
9: Implementation for Oracle EBS

Student Guide
D55409GC11 Edition 1.1 February 2010 D65505
Oracle Internal & Oracle Academy Use Only
Author
Jim Sarokin
Copyright 2010, Oracle and/or its affiliates. All rights reserved. Disclaimer This document contains proprietary information and is protected by copyright and other intellectual property laws. You may copy and print this document solely for your own use in an Oracle training course. The document may not be modified or altered in any way. Except where your use constitutes "fair use" under copyright law, you may not use, share, download, upload, copy, print, display, perform, reproduce, publish, license, post, transmit, or distribute this document in whole or in part without the express authorization of Oracle. The information contained in this document is subject to change without notice. If you find any problems in the document, please report them in writing to: Oracle University, 500 Oracle Parkway, Redwood Shores, California 94065 USA. This document is not warranted to be error-free. Restricted Rights Notice
Technical Contr ibutor s and Reviewer s

Dan Hilldale Mitravinda Kolachalam Manmohit Saggi Phillip Scott Kasturi Shekhar Albert Walker Jr.
Jayanthy Keshavamurthy
U.S. GOVERNMENT RIGHTS The U.S. Governments rights to use, modify, reproduce, release, perform, display, or disclose these training materials are restricted by the terms of the applicable Oracle license agreement and/or the applicable U.S. Government contract. Trademark Notice Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners.
Publisher
If this documentation is delivered to the United States Government or anyone using the documentation on behalf of the United States Government, the following notice is applicable:
Contents
I Course Introduction Lesson Agenda I-2 Instructor and Class Participants I-3 Training Site Information I-4 Course Audience I-5 Course Prerequisites I-6 Course Goal I-7 Course Objectives I-8 Course Methodology I-9 Course Materials I-10 Course Agenda I-11 Summary I-15 Oracle Business Intelligence Applications Overview Objectives 1-2 The Evolving Role of Business Intelligence 1-3 Enterprise Performance Management System 1-4 Oracle BI Applications: Overview 1-5 Oracle BI Applications: Multisource Analytics 1-6 Sales Analytics 1-7 Service Analytics 1-8 Contact Center Telephony Analytics 1-9 Marketing Analytics 1-10 Supply Chain and Order Management Analytics 1-11 Financial Analytics 1-12 Human Resource Analytics 1-13 Procurement and Spend Analytics 1-15 Oracle BI Applications Components 1-16 Common Enterprise Information Model 1-17 Analytic Workflows 1-18 Speeds Time to Value and Lowers TCO 1-20 Application Integration: Security 1-21 Application Integration: Action Links 1-22 Guided Navigation 1-23 Deployment Options 1-24 Summary 1-25 Oracle Business Intelligence Applications Architecture Overview Objectives 2-2 Oracle BI Applications Components 2-3 Oracle BI Applications Architecture 2-5
iii
Oracle Business Analytics Warehouse Content Objectives 3-2 The Oracle Business Analytics Warehouse (OBAW) Content 3-3 Star Schema 3-4 Selected Star Schemas of the OBAW 3-5 Star Schema Example: General Ledger Revenue 3-6 OBAW Tables 3-7 Fact Tables 3-9 Types of Fact Tables 3-10 Dimension Tables 3-11 Conforming Dimension Tables 3-12 Minidimension Tables 3-13 Subset Dimension Tables 3-14 Hierarchy and Helper Tables 3-15 Staging Tables 3-17 Aggregate Tables 3-18 Internal Tables 3-19 Standardized Codes 3-20 Standardized Codes: Accounts Receivable Process Example 3-22
iv
ETL Overview 2-6 Data Extraction and Load Process 2-7 Universal Business Adaptor 2-9 Data Warehouse Administration Console (DAC) 2-10 Physical Data Model: Overview 2-11 Server Repository: Overview 2-12 Metrics and Calculations 2-13 Presentation Catalog: Overview 2-14 Oracle BI Enterprise Edition Platform Architecture 2-15 Oracle BI Applications Architecture 2-16 Data Warehouse Load Process 2-17 ETL: Process Flow 2-18 DAC Architecture 2-19 Deployment Considerations 2-20 ETL Servers Component 2-21 The OBAW Database Component 2-22 ETL Repositories Component 2-23 ETL Clients Component 2-24 ETL Client Component Contents 2-25 Deployment Summary 2-26 Summary 2-27 Practice 2-1: Matching Oracle Business Analytics Warehouse Components 2-28 Practice 2-2: Locating the Oracle Business Analytics Warehouse Components 2-29
Currency and Multitenancy Support 3-25 Summary 3-26 4 Installing Oracle BI Applications Objectives 4-2 Oracle Business Intelligence Applications Installation and Configuration Tasks 4-3 Verify Preinstallation Requirements 4-5 Satisfy Mandatory Preinstallation Requirements 4-6 Complete Mandatory Preinstallation Tasks 4-7 Install Oracle BI Applications Software 4-8 Install Informatica PowerCenter Software 4-9 Restore the Oracle BI Prebuilt Repository 4-10 Copy Source Files and Lookup Files 4-11 Set Code Page Validation 4-12 Set PowerCenter Integration Services Custom Properties 4-13 Install the DAC Client 4-14 Copy Hibernate Libraries 4-15 Install JDBC Drivers 4-16 Verify DAC Connection Configuration 4-17 Enable DAC Client Communication with Informatica 4-18 PMCMD Command 4-19 Create a DAC Connection 4-20 Create the DAC Repository Schema 4-21 Import DAC Metadata 4-22 Create the Data Warehouse Tables 4-23 Configure Connection Between DAC Server and DAC Repository 4-24 Set DAC System Properties 4-25 Register the Informatica Services in the DAC 4-26 Set Physical Data Sources in the DAC 4-27 Configure Relational Connections in Informatica Workflow Manager 4-28 Oracle BI Applications Topology 4-29 Summary 4-31 Practice 4-1 Overview: Configuring the Training Environment 4-32 Understanding the ETL Process Objectives 5-2 ETL Process: Overview 5-3 ETL Process Steps 5-5 Data Extraction and Load Process: Extract 5-6 Universal Adaptors 5-7 Data Extraction and Load Process: Load 5-8
Working with Informatica Designer Objectives 6-2 Informatica Designer 6-3 Informatica Designer User Interface 6-4 Key Terms 6-5 Folder 6-6 Source Definition 6-8 Target Definition 6-9 Mapping 6-10 Transformation 6-11 Transformation Type 6-12 Mapplet 6-13 Port 6-14 Port Type 6-15 Informatica Designer Tools 6-16 Source Analyzer 6-17 Example: Importing a Source Definition 6-18 Target Designer 6-19 Mapping Designer 6-20 Mapplet Designer 6-21 Linking Components 6-22 Validating Mappings 6-23 Copying Existing Objects 6-24 Saving the Repository 6-25 Summary 6-26 Practice 6-1: Working with Informatica Designer 6-27 Working with Informatica Workflow Manager Objectives 7-2 Informatica Workflow Manager 7-3 Workflow 7-4 Session 7-5
vi
ETL Mappings 5-9 Full and Incremental ETL 5-10 DAC Tasks 5-11 DAC Task Phases 5-12 Internal Tables 5-14 Change Capture 5-15 Restart Mechanisms 5-16 Unspecified Mappings 5-17 Executing ETL 5-18 ETL Process: Summary 5-19 Summary 5-20 Practice 5-1: Exploring Oracle BI ETL Metadata 5-21
Exploring SDE and SIL Mappings Objectives 8-2 Anatomy of a Typical SDE Mapping 8-3 Business Component Mapplet 8-4 Source Qualifier Transformation 8-5 Expression Transformation 8-6 Source Adapter Mapplet 8-7 Target Definition 8-8 Anatomy of a Typical SIL Mapping 8-9 SIL Source Definitions 8-10 SIL Source Qualifier 8-11 MPLT_GET_ETL_PROC_WID Mapplet 8-12 Lkp_W_GL_REVN_F Lookup Procedure 8-13 Exp_W_GL_REVN_F_Update_Flg Expression 8-14 Fil_W_GL_REVN_F Filter 8-16 mplt_Curcy_Conversion_Rates Mapplet 8-17 EXP_Custom Expression 8-18 MPLT_LKP_W_CUSTOMER_FIN_PROFL_D Mapplet 8-19 mplt_SIL_GLRevenueFact Mapplet 8-20 Upd_W_GL_REVN_F_Ins_Upd Update Strategy 8-21 W_GL_REVN_F Target Definition 8-22 Unspecified Mappings 8-23 Summary 8-24 Practice 8-1 Overview: Exploring a Prebuilt SDE Mapping 8-25 Practice 8-2 Overview: Exploring a Prebuilt SIL Mapping 8-26 Working with the Data Warehouse Administration Console Objectives 9-2 Data Warehouse Administration Console 9-3 DAC Application-Specific Capabilities 9-4
vii
Creating and Running Workflows 7-6 1. Connect to the Repository 7-7 2. Open Workflow Designer 7-8 3. Create a Workflow 7-9 4. Add a Session to the Workflow 7-10 5. Link Workflow Tasks 7-11 6. Edit Session Properties 7-12 7. Validate the Workflow 7-13 8. Start the Workflow 7-14 9. Monitor the Workflow 7-15 10. Check Log File 7-16 Summary 7-17 Practice 7-1: Creating and Running an Informatica Workflow 7-18
10 Configuring Analytical Applications Objectives 10-2 Configuration Required Before a Full Load 10-3 Initial Extract Date 10-4 Global Currencies 10-5 Exchange Rate Types 10-6 Fiscal Calendars 10-7 DATASOURCE_NUM_ID 10-8 Setting General Ledger Account Hierarchies Using Flexfield Value Sets Definitions 10-9
viii
DAC Features 9-5 Source System Containers 9-6 DAC Repository Objects 9-7 DAC Repository Object Hierarchy 9-9 DAC Repository Object Hierarchy with Examples 9-10 DAC Client User Interface 9-11 DAC Client Tools Menu 9-12 DAC Views 9-13 Design View: Subject Areas Tab 9-14 Design View: Tables Tab 9-15 Design View: Source System Parameters Tab 9-16 Design View: Source System Folders Tab 9-17 Design View: Tasks Tab 9-18 Design View: Source Tables Subtab 9-20 Design View: Target Tables Subtab 9-21 Design View: Phase Dependency Subtab 9-22 Setup View 9-23 Setup View: DAC System Properties Tab 9-24 Setup View: Informatica Servers Tab 9-25 Setup View: Physical Data Sources Tab 9-26 Setup View: Refresh Dates 9-27 Setup View: Email Recipients Tab 9-28 Execute View 9-29 Execute View: Execution Plans Tab 9-30 Execute View: Parameters Subtab 9-31 Execute View: Prune Days 9-32 Execute View: Current Run Tab 9-33 Execute View: Run History Tab 9-34 Execute View: Scheduler Tab 9-35 Resetting the Data Warehouse 9-36 Object Ownership in the DAC 9-37 Summary 9-38 Practice 9-1: Exploring the DAC 9-39
11 Customizing DAC Metadata and Running an Execution Plan Objectives 11-2 Customizing DAC Metadata and Running an Execution Plan 11-3 Creating or Copying a Source System Container 11-4 Creating a Subject Area 11-5 Assembling a Subject Area 11-6 Creating an Execution Plan 11-7 Generating Execution Plan Parameters 11-8 Building an Execution Plan 11-9 Verifying DAC Server Is Started 11-10 Running an Execution Plan 11-11 Monitoring an Execution Plan 11-12 Viewing Run History for an Execution Plan 11-13 Viewing Predefined Reports 11-14 Verifying Data 11-15 Summary 11-16 Practice 11-1 Overview: Customizing DAC Metadata 11-17 12 Customizing Oracle Business Analytics Warehouse Objectives 12-2 Customization 12-3 Customization Scenarios 12-4 Upgrade Considerations 12-5 Type I Customization: Adding Columns to Existing Tables 12-6 Type I Customization: Extending Mappings 12-7 Type I Customization: Safe Path 12-8 Type I Customization: Extension Categories 12-9 Type I Customization: Impact of Customization on Upgrade 12-10 Type I Customization: Points to Remember 12-11
ix
Mapping Oracle GL Natural Accounts to Group Account Numbers 10-11 Creating a New Metric Based on a New Group Account Number 10-12 Create a New Group Account Number 10-13 Duplicate an Existing Measure 10-14 Rename the Measure and Modify the Filter 10-15 Add the Measure to the Presentation Layer 10-16 Summary 10-17 Practice 10-1 Overview: Configuring Common Areas and Dimensions Before Running a Full Load 10-18 Practice 10-2 Overview: Configuring General Ledger Account Hierarchies 10-19 Practice 10-3 Overview: Mapping Oracle GL Natural Accounts to Group Account Numbers 10-20 Practice 10-4 Overview: Creating a New Metric Based on a New Group Account Number 10-21
13 Adding Columns to an Existing Dimension Table Objectives 13-2 Type I Customization: Adding Columns to Existing Tables 13-3 Type I Customization Scenario 13-4 Type I Customization Steps 13-5 Step 1: Creating Custom SDE and SIL Folders in Informatica 13-6 Step 2: Copying SDE and SIL Mappings and Workflows to Custom Folders 13-7 Step 3: Building Custom SDE and SIL Mappings 13-8 Step 4: Editing Workflows 13-9 Step 5: Using DAC to Add New Column Objects to Data Warehouse 13-10 Step 6: Registering Custom Folders in DAC 13-11 Step 7: Modifying Existing DAC Tasks to Use Custom Mappings and Workflows 13-12 Step 8: Creating a Custom Subject Area in DAC 13-13 Step 9: Creating and Running a Custom Execution Plan in DAC 13-14 Verifying Results 13-15 Summary 13-16 Practice 13-1: Creating a Custom SDE Mapping 13-17 Practice 13-2: Creating a Custom SIL Mapping 13-18 Practice 13-3: Adding DAC Tasks and Running Customized ETL 13-19 14 Adding a New Dimension in OBAW Objective 14-2 Type II Customization: Adding Additional Tables 14-3 Type II Customization Scenario 14-4
Type I Customization: Typical Steps to Extend Mappings 12-12 Type II Customization: Adding Additional Tables 12-13 Type II Customizations: Considerations 12-14 Type II Customization: Required Columns 12-15 Type II Customization: DATASOURCE_NUM_ID 12-16 Type II Customization: Custom Folders 12-17 Type II Customization: Custom Workflows 12-18 Additional Customization Considerations 12-19 Table Definitions in Oracle Format 12-20 Update Strategy 12-21 ETL Process 12-22 Truncating Target Tables 12-23 ETL_PROC_WID 12-24 DATASOURCE_NUM_ID 12-25 Creating Indices 12-26 Naming Conventions 12-27 Configuring DAC 12-28 Summary 12-29
15 Integrating Security for Oracle Business Intelligence Applications Objectives 15-2 Oracle BI Security Options 15-3 Oracle BI Application Security 15-4 Security Manager 15-5 Synchronizing BI Server Groups 15-6 Oracle BI Presentation Services Administration Page 15-7 Synchronizing Presentation Catalog Groups 15-8 Authorization 15-9 Data Security Integration 15-10 Ledger Data Security in Oracle EBS 15-11 Ledger Security in Oracle BI Applications 15-12 Ledger Security: USER System Variable 15-13 Ledger Security: EBS Single Sign-On Integration Session Variable 15-14 Ledger Security: EBS Security Context Initialization Block 15-15 Ledger Security: Ledgers Initialization Block 15-16 Summary 15-17 16 Managing OBAW Performance Objectives 16-2 Maximizing the OBAW Performance 16-3 Common Performance Bottlenecks 16-4 Performance Overview 16-5 Informatica Server Throughput 16-6 ETL Parallel Processing 16-7 ETL Parallel Processing: Example 16-8 ETL Performance Troubleshooting 16-9 ETL Performance Leading Practices 16-10 OBAW Database Server Throughput 16-11
xi
Type II Customization Steps 14-5 Step 1: Creating and Running DDL for New Tables 14-6 Step 2: Registering New Tables in DAC 14-7 Step 3: Setting Table Properties 14-8 Step 4: Importing Table Columns 14-9 Step 5: Adding a Foreign Key Column to the Fact Table 14-10 Completing the Remaining Steps 14-11 Summary 14-12 Practice 14-1: Adding a New Dimension in OBAW 14-13 Practice 14-2: Creating an SDE Mapping to Load the Dimension Staging Table 14-14 Practice 14-3: Creating an SIL Mapping to Load the Dimension Table 14-15 Practice 14-4: Creating an SDE Mapping to Load the Fact Staging Table 14-16 Practice 14-5: Creating an SIL Mapping to Load the Fact Table 14-17 Practice 14-6: Adding DAC Tasks and Running Customized ETL 14-18
OBAW Database: Indices 16-12 OBAW Database: Optimizer Statistics 16-13 OBAW Database: Aggregate and Subdimension Tables 16-14 Aggregate Tables: Examples 16-15 Subdimension Tables: Examples 16-16 Summary 16-17 Appendix A: Exploring the Date Dimension Date Dimension A-2 W_DAY_D A-3 Star Schema with Date Dimension: Example A-4 Source System Parameters A-5 Considerations A-6
xii
Course Introduction
Copyright 2010, Oracle and/or its affiliates. All rights reserved.
Lesson Agenda
This lesson provides an introduction to: Instructor and class participants Training site information Course:
Oracle BI Applications 7.9: Implementation for Oracle EBS I - 2
Audience Prerequisites Goal Objectives Methodology Materials Agenda
Instructor and Class Participants

Who are you?
Name Company Role
What is your prior experience?
How do you expect to benefit from this course?
Business intelligence Data warehouse design Database design
Training Site Information
Bathrooms
Class duration and breaks
Telephones
Fire exits
Questions?
Meals and refreshments
Course Audience
This course is designed for: Technical architects Technical business analysts Configurators or developers Application administrators Database administrators
Course Prerequisites
Recommended: Working knowledge of Informatica PowerMart or PowerCenter Basic knowledge of SQL Domain experience in business intelligence, data warehouse design, dimensional modeling, and database design
Course Goal
To enable students to install, design, customize, and configure Oracle Business Intelligence (BI) Applications and Oracle Business Analytics Warehouse
Course Objectives
Explore Oracle Business Intelligence Applications and the Oracle Business Analytics Warehouse (OBAW) foundational concepts and architecture. Install and configure Oracle BI Applications Explore the prebuilt extract, transform, and load (ETL) metadata for Oracle BI Applications Use the Data Warehouse Administration Console (DAC) to run ETL routines to populate the OBAW Customize DAC metadata Customize and extend the OBAW Manage the security and performance of Oracle BI Applications
Course Methodology
Subject matter is delivered by: Lecture and slide presentations Software demonstrations Class discussions Hands-on practices
Course Materials
Student Guide
All slides presented during lecture Student notes
Activity Guide
Hands-on practices and solutions
Course Agenda
Day One: Lesson I: Course Introduction Lesson 1: Oracle Business Intelligence Applications Overview Lesson 2: Oracle Business Intelligence Applications Architecture Overview Lesson 3: Oracle Business Analytics Warehouse Content Lesson 4: Installing Oracle Business Intelligence Applications
Course Agenda
Day Two: Lesson 5: Understanding the ETL Process Lesson 6: Working with Informatica Designer Lesson 7: Working with Informatica Workflow Manager Lesson 8: Exploring SDE and SIL Mappings Lesson 9: Working with the Data Warehouse Administration Console
Course Agenda
Day Three: Lesson 10: Configuring Analytical Applications Lesson 11: Customizing DAC Metadata and Running an Execution Plan Lesson 12: Customizing the Oracle Business Analytics Warehouse Lesson 13: Adding Columns to an Existing Dimension Table
Course Agenda
Day Four: Lesson 14: Adding a New Dimension in the Oracle Business Analytics Warehouse Lesson 15: Integrating Security for Oracle Business Intelligence Applications Lesson 16: Managing OBAW Performance
Summary
This lesson provided an introduction to the: Instructor and class participants Training site information Course:
Audience Prerequisites Goal Objectives Methodology Materials Agenda
Oracle Business Intelligence Applications Overview

Objectives
After completing this lesson, you should be able to: Describe Oracle Business Intelligence (Oracle BI) Applications Explain the key components of Oracle BI Applications Describe Oracle BI Applications integration with transactional applications
Oracle BI Applications 7.9: Implementation for Oracle EBS 1 - 2
The Evolving Role of Business Intelligence

From: Analysts Historical data Fragmented view Reporting results To: Pervasive use Real-time, predictive data Unified, enterprise view Insight-driven business process optimization Unified infrastructure and prebuilt analytic solutions
Analytic tools
The Evolving Role of Business Intelligence The role of business intelligence in an enterprise is undergoing a change: Usage is moving from a few analysts to pervasive use across many organizational functions. This is supported by the use of prebuilt applications that support multiple roles. Data storage is moving from purely historical information to up-to-the-minute analysis, and even predictive data that allows analysis into the future. Organizations want to bring together formerly fragmented silos of information, often stored in transactional systems, into a unified enterprise view of their organization. There is a trend toward using prebuilt BI Applications that offers packaged value instead of building individual reports on an as-needed basis using Analytics tools.
Enterprise Performance Management System

Web Office Desktop Mobile
BI APPLICATIONS
Sales Svcs. Mktg. Contact Order Supply HR Finance Center Mgmt. Chain
Performance Management Applications
Fusion Middleware
OLTP & ODS Systems
Data Warehouse Data Mart
Essbase
SAP, Oracle, Siebel, PeopleSoft, Custom
Excel XML
Business Process
Enterprise Performance Management System Oracles Enterprise Performance Management system is a portfolio of technology and applications that include management applications for category-leading financial performance, operational BI applications, BI foundation, and tools. It also leverages Oracles Fusion Middleware technologies, such as Oracle Application Server and Oracle Identity Management. The top layer is the information delivery layer. This pervasive access layer allows information to be personalized and delivered based on individual needs and roles in the organization through Web-based dashboards or Microsoft Office products. Additionally, alerts can be pushed to mobile devices to notify managers of emerging issues or growing variances. Financial Performance Management Applications are a modular suite of integrated applications that support the entire financial management cycle of goal setting, modeling, planning, monitoring, analysis, and reporting. Business Intelligence Foundation is the core technology of Oracles EPM system. It uses a common enterprise information model as the consistent semantic layer. Fusion Middleware provides an open, comprehensive, standards-based approach for deploying service-oriented architectures (SOAs) using Web services, an enterprise service bus, and the Oracle BPEL (Business Process Execution Language) Process Manager. Its portfolio includes products for integration, business process management, business intelligence and data management, developer tools for applications, and many other components.
Business Intelligence Foundation
Oracle BI Applications: Overview

Service & Contact Center Order Management & Fulfillment Supply Chain Human Resources
Sales
Marketing
Financials
Oracle BI Applications
Interactive Dashboards Reporting & Publishing Ad hoc Analysis Proactive Detection and Alerts Disconnected Analytics MS Office Plug-in Web Services
Oracle BI Suite EE
PeopleSoft Siebel SAP

Packaged ETL maps DW Schema Universal adaptors IVR, ACD, CTI MS Excel Other data sources
Oracle BI Applications: Overview Oracle BI Applications is a complete, prebuilt Business Intelligence solution that both delivers intuitive, role-based intelligence for everyone in an organization, from frontline employees to senior management, and enables better decisions, actions, and business processes. Oracle BI Applications is a complete, end-to-end BI environment that includes the Oracle BI EE platform and the prepackaged analytic applications. The platform includes a server and end-user tools such as dashboards, query and analysis, enterprise reporting, and disconnected access to data, all supported by a unified, model-centric server architecture. On top of this platform, Oracle BI Applications consumes transactional operational data sources via packaged extract, transform, and load (ETL) mappings, and metadata, which load a data warehouse for analysis. Analyzing the data warehouse, Oracle BI Applications delivers rolebased analysis via prebuilt reports, dashboards, alerts, briefing books, and other channels provided by the platform.
Oracle BI Applications: Multisource Analytics

Auto Comms & Media Complex Mfg Consumer Energy Financial High Sector Services Tech Marketing Campaign Scorecard Response Rates Product Propensity Loyalty and Attrition Market Basket Analysis Campaign ROI PeopleSoft Order Management & Fulfillment Order Linearity Orders vs. Available Inventory Cycle Time Analysis Insurance & Health Supply Chain Supplier Performance Spend Analysis Procurement Cycle Times Inventory Availability Employee Expenses BOM Analysis SAP Life Sciences Financials A/R & A/P Analysis Public Sector Travel & Trans
Sales Pipeline Analysis Triangulated Forecasting Sales Team Effectiveness Up-sell/ Cross-sell Cycle Time Analysis Lead Conversion
Service & Contact Center Churn Propensity Customer Satisfaction Resolution Rates Service Rep Effectiveness Service Cost Analysis Service Trends
Human Resources Employee Productivity
GL/ Balance Compensation Sheet Analysis Analysis Customer & Product Profitability P&L Analysis Expense Management Cash Flow Analysis HR Compliance Reporting Workforce Profile Turnover Trends Return on Human Capital
Backlog Analysis Fulfillment Status Customer Receivables Siebel
Prebuilt adaptors:
Other Operational & Analytic Sources
Oracle BI Suite Enterprise Edition
Multisource Analytics Oracle BI Applications covers everything in the enterprise: from demand chainincluding sales, service, and marketingto supply chain, and also the important back-office capabilities. In many cases, financial analytics combine with other applications to offer a breadth of analysis. For example, financial analytics may be combined with supply chain analytics to analyze performance with regard to procurement. Oracle BI Application families take advantage of the strengths of the Oracle BI EE platform to deliver packaged analytics content. Prebuilt ETL consumes information from multiple transactional sourcesincluding Oracle eBusiness Suite (EBS), Peoplesoft, Siebel, SAP, and other operational systemsto deliver broad business insight into these applications. Applications include the general, role-based analytical application families as well as a number of specific, vertical applications tailored to specific industriesfor example, automotive, high technology, and life sciences industries. Each Oracle BI application is discussed in detail in the slides that follow.
Sales Analytics
Improves the effectiveness of a sales organization: Analyze pipeline opportunities to determine actions required to meet sales targets Determine which products and customer segments generate the most revenue Understand which competitors are faced most often and how to win against them Identify up-sell and cross-sell opportunities within existing accounts
Sales Analytics Oracle Sales Analytics provides hundreds of key performance indicators and more than 130 prebuilt reports in five customizable dashboards. These analytics solutions dramatically improve the effectiveness of a sales organization by providing real-time, actionable insight into every sales opportunity at the point of customer contact. With more accurate sales forecasts and enhanced identification of potential problems and opportunities, Oracle Sales Analytics helps close business faster and increase overall sales revenue. Sales Analytics analyzes pipeline opportunities and forecasts to determine the actions required to meet sales targets. The application determines which products and customer segments generate the most revenue and how to effectively cross-sell and up-sell to them. It also evaluates which competitors are faced most often and how to win against them. Oracle Sales Analytics provides the following benefits: Analyzing pipeline opportunities to determine actions required to meet sales targets Determining which products and customer segments generate the most revenue Understanding which competitors are faced most often and how to win against them Identifying up-sell and cross-sell opportunities within existing accounts
Service Analytics
Provides a comprehensive customer service solution: Monitor, analyze, and manage the service center based on key performance metrics Track customer service representative performance Provide customer service representatives a more complete view of a customers account
Service Analytics Oracle Service Analytics provides a comprehensive customer service solution, with hundreds of key performance indicators and more than 102 reports delivered in eight interactive dashboards. This consolidated view of customer service effectiveness leads to improved service levels while lowering service costs, and increased customer satisfaction that translates into higher revenue per customer. Oracle Service Analytics provides the following benefits: Service Effectiveness: Monitor, analyze, and manage the service center based on key performance metrics such as service request aging and average resolution time, increasing customer satisfaction and reducing costs. Employee Effectiveness: Understand customer service representative performance to enable improvements in employee productivity, effectiveness, training programs, and retention. Customer Insight: Provide customer service representatives a more complete view of a customers account, potential value, and propensity to buy more products, enabling faster resolution of issues and increased cross-selling rates.
Contact Center Telephony Analytics

Provides the ability to analyze all aspects of contact center performance: Optimize performance across multiple service channels to maximize service effectiveness Optimize staffing levels for anticipated call volumes and service request types Gain insight into how training, tenure, and rewards impact agent performance Track and measure initial incident-to-issue resolution rates. Maximize cross-sell and up-sell rates
Contact Center Telephony Analytics Oracle Contact Center Telephony Analytics provides organizations with powerful insight that enables them to analyze all aspects of contact center performance. Contact Center Telephony Analytics provides more than 72 reports in five interactive dashboards with hundreds of bestpractice metrics, alerts, and key performance indicators (KPIs), enabling companies to take targeted action to improve employee productivity, reduce costs, and increase customer satisfaction. Oracle Contact Center Telephony Analytics provides the following benefits: Customer Service: Optimize performance across multiple service channels to achieve greater process efficiency and maximize service effectiveness and customer satisfaction. Agent Performance: Increase service effectiveness while minimizing costs, optimize staffing levels for anticipated call volumes and service request types, and gain insight into how training, tenure, and rewards impact agent performance. Service and Delivery Cost: Track and measure initial incident-to-issue resolution rates, measure service costs by customer, channel, and product type to reduce overall service costs, and maximize customer satisfaction. Contact Center Sales: Increase revenue per agent, maximize cross-sell and up-sell rates, and maximize revenue performance across customer, product, service, and regions.
Marketing Analytics
Provides a complete, up-to-the-minute picture of customer preferences, buying behavior, and profitability: Achieve better campaign response rates Profile customers for more effective event-based promotion Allocate resources more effectively by identifying what drives campaign results Track and measure campaign effectiveness in real time Compare individual campaign results to target metrics Gain better insight into segmentation characteristics
Marketing Analytics Oracle Marketing Analytics provides the ability to obtain maximum results from marketing investments by providing the entire marketing team with a complete, up-to-the-minute picture of customer preferences, buying behavior, and profitability. Oracle Marketing Analytics helps you to develop closer, more valuable customer and prospect relationships and improve marketing effectiveness. Oracle Marketing Analytics provides the following benefits: Marketing Planning: Achieve better campaign response rates, profile customers for more effective event-based promotion, and allocate resources more effectively by identifying what drives campaign results. Campaign Performance: Track and measure campaign effectiveness in real time, understand factors that drive campaign results and lead conversion rates, and compare individual campaign results to target metrics. Customer Insight: Understand product affinity for targeted promotions, profile customers buying behavior for more effective promotions, and gain better insight into segmentation characteristics.
Supply Chain and Order Management Analytics

Provides insight into order and inventory data so you can make better decisions in each stage of the order lifecycle: Improve revenue recognition with faster order to booking conversion and fewer bottlenecks in the order-to-cash cycle Improve inventory management for those products that consistently fall into backlog due to a lack of appropriate stock levels Gain visibility into inventory activities to minimize unnecessary expenditures and optimize inventory to conserve working capital
Supply Chain and Order Management Analytics Oracle Supply Chain and Order Management Analytics delivers deep customer insight into order and inventory data so you can make better decisions in each stage of the order lifecycle. Oracle Supply Chain and Order Management Analytics enables you to assess inventory levels, determine likely product fulfillment needs before the order has been booked, quickly identify potential order backlog issues, and stay on top of critical accounts receivable (A/R) and days sales outstanding (DSO) issues. By leveraging actionable and fact-based insights, you can transform your current Supply Chain and Order Management processes to improve financial performance and customer satisfaction. Oracle Supply Chain and Order Management Analytics provides the following benefits: Better Business Performance: Improve revenue recognition with faster order to booking conversion and fewer bottlenecks in the order-to-cash cycle. Better Order Fulfillment: Improve inventory management for those products that consistently fall into backlog due to a lack of appropriate stock levels. Better Inventory Management: Gain visibility into inventory activities to minimize unnecessary expenditures and optimize inventory to conserve working capital.
Financial Analytics
Provides the ability to improve financial performance with complete, up-to-the-minute information on expenses and revenue contributions: Assess cash-management Monitor operational effectiveness of the payables department to ensure the lowest transaction costs Monitor DSOs and cash cycles to manage working capital Manage financial performance across locations, customers, products, and territories Identify the most profitable customers, products, and channels Understand profitability drivers across regions, divisions, and profit centers
Financial Analytics Understand and manage the key drivers of shareholder value and profitability. Oracle Financial Analytics helps frontline managers improve financial performance with complete, up-to-theminute information on their departments expenses and revenue contributions. Hundreds of key performance indicators and more than 200 reports enable financial managers to improve cash flow, lower costs, and increase profitability while maintaining more accurate, timely, and transparent financial reporting that helps ensure Sarbanes-Oxley compliance. Oracle Financial Analytics provides the following benefits: Payables: Assess cash-management and monitor operational effectiveness of the payables department to ensure the lowest transaction costs. Receivables: Monitor DSOs and cash cycles to manage working capital, manage collections, and control receivables risk. General Ledger: Manage financial performance across locations, customers, products, and territories, and receive real-time alerts on events that may impact the financial condition. Profitability: Identify most profitable customers, products, and channels, and understand profitability drivers across regions, divisions, and profit centers.
Human Resource Analytics

Provides the ability to improve overall workforce performance and managerial effectiveness: Understand how compensation impacts performance Align incentive compensation with objectives and company goals Assess HR performance against recruitment and retention goals Understand drivers of employee turnover Reduce time and cost of compliance reporting
Human Resource Analytics Oracle Human Resources Analytics helps organizations improve overall workforce performance and managerial effectiveness while reducing costs. With numerous key performance indicators, more than 85 reports, and four dashboards, Oracle Human Resources Analytics provides human resources (HR) professionals and frontline managers with the tools to gain up-to-the-minute insight into productivity levels across an organization. The resulting benefits help reduce workforce costs, increase employee productivity, effectively manage employee compensation, improve retention, and reduce voluntary turnover. Oracle Human Resources Analytics provides the following benefits: Compensation: Understand how compensation impacts performance, ensure compensation is equitable and consistent across roles, and align incentive compensation with objectives and company goals. HR Performance: Assess HR performance against recruitment and retention goals, monitor and improve employee productivity, and assess compensation competitiveness to attract top talent. Retention: Understand drivers of employee turnover, proactively identify top performers who are likely to be recruited by competitors, and reduce recruiting and involuntary termination costs.
Human Resource Analytics (continued) Workforce Profile and Compliance: Reduce time and cost of compliance reporting, increase employee satisfaction and retention, and manage overall profile and background of workforce.
Procurement and Spend Analytics

Provides the ability to optimize supply-side performance by integrating data from across the enterprise value chain: Gain detailed visibility into direct and indirect spending Identify opportunities to consolidate spending and reduce costs Monitor price, delivery, and product quality to determine best- and worst-performing suppliers
Procurement and Spend Analytics Oracle Procurement & Spend Analytics provides the ability to optimize supply-side performance by integrating data from across the enterprise value chain and enables executives, managers, and frontline employees to make more informed decisions. Oracle Procurement and Spend Analytics increases visibility into the complete procure-to-pay process, including comprehensive spendand-procurement analysis, supplier performance analysis, and supplier payables analysis. Through complete end-to-end insight into the factors that impact company performance, you can significantly reduce costs, enhance profitability, increase customer satisfaction, and gain competitive advantage. Oracle Procurement and Spend Analytics provides the following benefits: Improved Procurement and Spend: Gain detailed visibility into direct and indirect spending, and identify opportunities to consolidate spending and reduce costs. Better Supplier Performance: Monitor price, delivery, and product quality to determine best- and worst-performing suppliers.
Oracle BI Applications Components

Oracle BI Applications includes four key components: Prebuilt data warehouse with conforming dimensions Prebuilt ETL to extract data from Oracle and non-Oracle sources Premapped metadata embedding best practices for metrics and KPIs Best practice library of dashboards and reports
BI Application Components Oracle BI Applications includes the same four key components: A prebuilt data warehouse data model that is optimized for the various supported databases. This data model incorporates the best practices that have been used in BI, decision support, and data warehousing. For example, there are more than 15 star schemas designed for analysis and reporting on Financial Analytics. Prebuilt ETL logic that extracts and transforms data using a source-specific understanding of the supported transactional system before loading it into the data warehouse data model. The prebuilt ETL extracts data from over 3,000 operational tables and loads it into the data warehouse, sourced from SAP, Peoplesoft, Siebel, Oracle E-Business Suite, and other sources. Premapped metadata, which connects the physical data sources, provides logical models defining all the key performance indicators (KPI) and metrics, and finally defines the presentation of data in a role-based way to the users of the system. For example, there are different prebuilt presentations for roles such as Finance Managers, Procurement Managers, Call Center Agents, Sales Representatives, and so on. A library of metrics, reports, and alerts that are embedded in Interactive Dashboards and presented to users on the basis of individual roles, such as CFO, Finance Controller, Financial Analyst, AR/AP Managers, and Executives.
Common Enterprise Information Model

Unified metadata model provides consistent information across the enterprise
PRESENTATION LAYER
User roles, preferences Simplified view Logical SQL interface
Role-based views of the information relevant to users
SEMANTIC OBJECT LAYER

PHYSICAL LAYER
Map Physical Data Connections Schema
Model once, deploy everywhere
Across any data sources

Common Enterprise Information Model Oracle BI Applications is built on the Oracle Business Intelligence Foundation. At the heart of the Oracle Business Intelligence Foundation is a key technology differentiator for Oraclethe Common Enterprise Information Model. This is a unified metadata model, which is accessed by all the end user tools, so every end user and every department across the enterprise has the same consistent view of information, tailored to their role. As a result, organizations no longer need to maintain multiple metadata environments for different types of users. Oracle provides the ability to model once, deploy everywhere. The metadata model consists of three tiers: The physical layer enables you to import the table structures of your existing data sources. The semantic layer enables you to create a simplified representation of multiple data sources, creating a logical model of your business in ways your managers think about it dimensions, hierarchies, and metrics. The presentation layer further simplifies this model making the data appear to end users as a single data source with a single table structure of dimensions, measures, and derived measures. This common enterprise information model enables you to define key metrics and calculations in one place, assuring that everyone has a consistent view of information (tailored to their role) and assuring alignment across departments.
Dimensions Hierarchies Measures Calculations Aggregation Rules Time Series
Consistent definition of business measures, metrics, and calculations
Analytic Workflows
Business objectives/ issues
Maximize Cash Flow
Is DSO on target? Is DPO on target? Is Overdue Balances trending up? Are Payment Terms in compliance?
Who are the Customers and Collectors? Drill to Overdue Invoice Detail. Target collection efforts to reduce overdue balances.
Drill to Due Balances by Region.
Take action
Business Function: Receivables Role: Director, Credits and Collections Objectives: 1) Maximize Cash Flow. 2) Control Risk of Receivables Portfolio.
Analytic Workflows Analytic workflows are built around standard paths of discovery for business issues. In this example, a Director of Credits and Collections in the Receivables function of Finance and Accounting is monitoring the Maximize Cash Flow objective. This objective is composed of several key questions and KPIs around Days Sales Outstanding (DSO), Days Payable Outstanding (DPO), and others. Each one of these subsequently leads to more questions about the core components of the KPIfor example, DSO being on target requires overdue balances to be on target, customers to be paying in line with their terms, and so on. These workflows are supported in Oracle BI Applications as standard exploration paths.
Gain insights
How long is the underlying Overdue Balance pending?
What is the aging of Due Balances?
Analytic Workflows
Business objectives/ issues
Maximize Cash Flow
Is DSO on target?
Is Overdue Balances trending up? How long is the underlying Overdue Balance pending?
Who are the Customers?
Drill to Overdue Invoice Detail.
Take action
Target collection efforts to reduce overdue balances.
Analytic Workflows (continued) Continuing with the example from the previous slide, following one branch of the Maximize Cash Flow analytic workflow, each part of the flow is supported by prebuilt reports and navigation that allow users to easily drill down to further levels of detail as required. Because the application and the supporting data warehouse model, and ETL are built to capture information at the transaction-line level, users can easily drill down from the summary information to the most atomic level of information. Ultimately this allows the user to not only monitor progress on an objective, but also to easily navigate to the right information, so that in the end any required corrective action can be proactively taken. Notice, for example, that in the Take Action area of the workflow, the user is drilling down from the BI Applications transactional invoice level report back to the originating transactional application to take action in the operational system.
Gain insights
Drill to Detail
Speeds Time to Value and Lowers TCO

Build from the beginning with traditional BI tools Training/Rollout Define Metrics & Dashboards DW Design Training/Rollout Back-end ETL and Mapping Define Metrics & Dashboards DW Design Back-end ETL and Mapping Oracle BI Applications
Oracle BI Applications solutions approach: Faster time to value Lower TCO Assured business value
Easy to use, easy to adapt Prebuilt DW design, adapts to your EDW Role-based dashboards and thousands of predefined metrics Prebuilt Business Adaptors for Oracle, PeopleSoft, Siebel, SAP, and others
Speeds Time to Value and Lowers TCO Compared with a traditional business intelligence deployment, which entails using ETL and BI platforms to build, load, and report on a custom data warehouse schema, Oracle BI Applications can provide a significant benefit in the value and total cost of ownership (TCO). The prebuilt nature of the applications, including the data warehouse data model and ETL, BI metadata, and reports and dashboards, allows significant savings in deployment time, creating business value in the significantly reduced timeframes. Built-in best practices, KPIs, metrics, and workflows reduce time, ensure successful business analysis, and reduce TCO.
Application Integration: Security

Shared security with Oracle EBS and Siebel CRM EBS Security Integration
FND_User security Shared responsibilities between Oracle EBS and Oracle BI Applications Oracle Single Sign-On (SSO)
Siebel CRM Security Integration

Siebel native security Shared responsibilities between Siebel CRM and Oracle BI Applications
Hot-Pluggable Security
Prebuilt security roles in BI Applications Users/roles synchronized with selected security environment
Application Integration: Security A shared security model between Oracle BI Applications and Oracle transactional applications supports SSO and enables a consistent view of the users and their hierarchies, and the roles within the organization. Oracle BI Applications is compatible with and shares user responsibilities with EBS and Siebel CRM security. Finally, prebuilt security roles in the BI Applications can be synchronized with additional security environments, for example Lightweight Directory Access Protocol (LDAP).
Application Integration: Action Links

Seamless navigation from analytical information to transactional detail while maintaining context Works with Oracle EBS, Siebel CRM, PeopleSoft
Action Links
Application Integration: Action Links Action Links allow navigation from Oracle BI Application reports back to Oracle EBS. Action Links can move into the EBS screens in the context of the record shown in the report. This can be accomplished by: Installing the appropriate EBS patch for SSO integration with Oracle BI EE Retrieving the URL for the EBS page that you want to drill down to Creating an Action Link with this URL to navigate to the Oracle Application page It is important to note that the lowest grain of records possible is loaded into the Oracle BI Applications from EBSfor example, general ledger and inventory transactions, order and invoice lines, human resources employees, and events. Because of this, it is easy for users to drill from the high-level, summary BI information that is created from these details down to successively more detailed information until they reach the most granular levels possible. Once here, users may want to make changes to some of the transactional records related to this detailed information. Action Links make it easy to navigate from the detailed records in BI to records in the transactional system while maintaining context.
Guided Navigation
Guided navigation: Enables users to quickly navigate a standard path of analytical discovery specific to their function and role
Guided Navigation Guided navigation and alerts drive the business user to greater insight and action. As a result, users are guided to make informed and effective decisions that enhance the performance of the entire organization. Guided navigation links enables users to quickly navigate a standard path of analytical discovery specific to their function and role. This enhances usability and lowers the learning curve for new users. It is also possible to set up conditional navigation links, which appear only when certain conditions are met, alert users to potential out-of-the-ordinary conditions that require attention, and guide users to the next logical step of analytical discovery.
Conditional navigation: Appears only when conditions are met and alerts users to potential out-of-the-ordinary conditions that require attention
Deployment Options
Stand-alone dashboards Portal integration Embedded directly in Oracle EBS
Deployment Options BI content can be published in line with other standard content in a number of contexts. Besides the traditional stand-alone dashboards shown through the client, Oracle BI Applications can be embedded into any JSR 168 standardsbased portals such as Oracle Portal. Reports can also be embedded directly in the Oracle Application pages.
Summary
In this lesson, you should have learned how to: Describe Oracle Business Intelligence (Oracle BI) Applications Explain the key components of Oracle BI Applications Describe Oracle BI Applications integration with transactional applications
Oracle Business Intelligence Applications Architecture Overview

Objectives
After completing this lesson, you should be able to: Describe the Oracle Business Intelligence (BI) Applications logical architecture Explain the process flow of building the data warehouse Employ the recommended deployment options to maximize data warehouse performance List the components supporting the Oracle Business Analytics Warehouse (OBAW) and the functions performed by each core component

Oracle BI Applications includes four main components: Prebuilt extract, transform, and load (ETL) processes and tools to configure, customize, manage, monitor, and maintain the OBAW
Prebuilt Informatica mappings and workflows Informatica Integration Services for processing the prebuilt ETL mappings and workflows Informatica tools for creating, customizing, extending, and testing the prebuilt Informatica mappings and workflows Data Warehouse Administration Console (DAC) server and client with prebuilt metadata for configuring, running, and monitoring the ETL processes for source-specific containers
Prebuilt Oracle Business Analytics Warehouse data model with prebuilt star schemas and conforming dimensions
Oracle BI Applications Components Oracle Business Intelligence Applications includes four main components. Prebuilt extract, transform, and load (ETL) processes and tools that you can use to configure, customize, manage, monitor, and maintain the Oracle Business Analytics Warehouse. This includes: - Prebuilt Informatica mappings and workflows used to load the OBAW - Informatica Integration Services for processing the prebuilt ETL mappings and workflows - Informatica tools for creating, customizing, extending, and testing the prebuilt Informatica mappings and workflows - The Data Warehouse Administration Console (DAC) server and client with prebuilt metadata for configuring, running, and monitoring the ETL processes for sourcespecific containers A prebuilt Oracle Business Analytics Warehouse data model with prebuilt star schemas and conforming dimensions

Prebuilt Oracle BI Server repository
Logical business model mapped to physical data sources Key performance indicators and metrics definitions Presentation layer that exposes the business model to business users Administration Tool for building and customizing the repository Oracle BI Server for query processing
Prebuilt Oracle BI Presentation Catalog

Prebuilt Interactive Dashboards and Oracle BI Answers reports Tools for modifying the prebuilt dashboards and reports
Oracle BI Applications Components (continued) A prebuilt Oracle BI Server repository that includes a logical business model mapped to physical data sources, key performance indicators and metrics definitions, a Presentation layer to expose the business model to business users, an Administration Tool for building and customizing the repository, and the Oracle BI Server for query processing A prebuilt Oracle BI Presentation Catalog that includes prebuilt Interactive Dashboards and Oracle BI Answers reports, and tools for modifying the prebuilt dashboards and reports Because Oracle BI Applications provides a prebuilt data warehouse solution, you can focus on customizing and extending the prebuilt components to support your specific business requirements.
Oracle BI Applications Architecture

Dashboards by role Reports, analysis/analytic workflows Metrics/KPIs Oracle BI Presentation services
Role-based dashboards Analytic workflow Guided navigation Security/visibility Alerts and proactive delivery Logical to physical abstraction layer Calculations and metrics definition Visibility and personalization Dynamic SQL generation Abstracted data model Conformed dimensions Heterogeneous database support Database-specific indexing Highly parallel Multistage and customizable Deployment modularity
Logical model/Subject areas Administration Physical map OBAW Data model Direct access to source data Load process Staging area Extraction process
Oracle BI server
Metadata
ETL DAC
Oracle
SAP R/3
Siebel
PSFT
EDW Other
Federated Data Sources
Oracle BI Applications Architecture The Oracle BI Applications architecture can be divided into four components: Extract, transform, and load (ETL), including the Data Warehouse Administration Console (DAC), which is used to support extract from packaged and other source transactional data, and load into the OBAW data warehouse. Physical OBAW data warehouse data model for the Oracle Business Analytics Warehouse, which is designed to support multiple databases and provide an abstracted data model with conformed dimensions that support cross-domain analysis. Server repository metadata, which provides physical to logical mappings, calculations, and metrics, as well as security Presentation Catalog contents, including prebuilt role-based Interactive Dashboards, security, and analytics workflows and guided navigation
ETL Overview
Three approaches to accessing or loading source data: Batch ETL (Full or Incremental) Oracle BI Present Micro ETL Dashboards by Role ation Direct access to source data from Services Oracle BI server Reports, Analysis/Analytic Workflows ETL Layered architecture for extract, universal staging, and load: Provides isolation, modularity, and Metrics/KPIs extensibility Oracle BI Has the ability to support source Logical Model/Subject Areas server system version changes quickly Administration Metadata Has the ability to extend with Physical Map additional adaptors Architected for performance: OBAW All mappings architected with Data Model incremental extractions Direct Access Load Process Highly optimized and concurrent to loads Source Staging Area ETL DAC Bulk Loader enabled for all Data databases Extraction Process Data Warehouse Administration Console (DAC): Application administration, execution, and monitoring
Oracle SAP R/3 Siebel PSFT EDW Other
ETL Overview The ETL process is divided into two major subprocesses: extraction and load. The architecture segregates all source-specific logic in the extract layer. Because of this, support for a new version of a source adaptor or a new source adaptor requires update or addition of only the extract layer. Performance tuning has been implemented in various areas for all platforms, including the use of bulk loaders and database-specific indexing. The DAC is a critical tool used for application installation, administration, and ETL scheduling and monitoring.
Data Extraction and Load Process

Source Dependent Extract: Is source-specific and supports universal business adaptors Exposes simplified business entities from complex source systems Converts source-specific data to universal staging table format Is lightweight and designed for performance and parallelism Is extensible
Business Analytics Warehouse
Source Independent Load
Load
Staging tables
Source Dependent Extract

SQL SQL SQL
Power connect Power connect
App Layer
Siebel OLTP
Oracle
App Layer
ABAP
Extract
Other
PeopleSoft SAP
Data Extraction and Load Process The extraction process provides source-specific adaptors (Siebel/Oracle/SAP/PeopleSoft) as well as universal business adaptors, which are used for legacy or other data sources. Extract mappings encapsulate the complexity of the source and expose a simplified view of the business entities, loading data in a universal staging table format into staging tables in the OBAW.
SQL
Data Extraction and Load Process

Business Analytics Warehouse
Source Independent Load: Encapsulates warehouse load logic Handles:

Slowly changing dimensions Key lookup resolution/ surrogate key generation Insert/update strategies Currency conversion Data consolidation
Source Independent Load
Load
Staging tables
Source Dependent Extract

SQL SQL SQL
Power connect Power connect
App Layer
Siebel OLTP
Oracle
App Layer
ABAP
SQL
Uses bulk loaders on all database platforms
Extract
Other
PeopleSoft SAP
Data Extraction and Load Process (continued) After the data has been staged from various sources, the load process loads it into the warehouse, performing calculations and necessary aggregations before loading final destination tables in the OBAW. The load process manages slowly changing dimensions, which store historical versions of attribute data, generates and resolves warehouse keys, manages insert and update strategies, and performs currency conversions. Finally, the load process manages data consolidation, whereby data from multiple sources, with different codes for similar respective entities, is standardized for common analysis in the OBAW.
Universal Business Adaptor

Is used for sources with no prepackaged business adaptor Extracts, transforms, and loads data from universal sources:
Extract mappings get data from files. No source-specific logic is embedded. Sources are flat files. Adaptors are easily modified to support relational and MQSeries sources.
Universal Business Adaptor Universal Business Adaptors are used to extract and load data from nonpackaged sources. The adaptors conform to the same extraction and load process, but provide generic sources, specifically flat file source definitions, to which data from legacy or other sources can be conformed for load during extract into the standardized OBAW staging tables. Note: MQSeries is an IBM software family whose components are used to tie together other software applications so that they can work together. This type of application is often known as business integration software or middleware.
Data Warehouse Administration Console (DAC)

Is used by warehouse developers and ETL administrators Is an ETL orchestration tool that enables:
Application configuration Execution and recovery Monitoring Pin-point deployment Load-balancing Reduced load windows Fine-grained failure recovery
Data Warehouse Administration Console (DAC) The following are some of the elements to be deployed and managed in a data warehouse. Data warehouse objects (tables/indices) ETL code Seed data Variety of configurations for ETL The DAC is used to administer, install, maintain, and monitor ETL runs. It is also used by ETL administrators in production to monitor and restart jobs.
Allows:
Physical Data Model: Overview
Dashboards by Role Reports, Analysis/Analytic Workflows Metrics/KPIs Logical Model/Subject Areas Administration Physical Map Data Warehouse/ Data Model Direct Access to Source Data Load Process Staging Area Extraction Process Oracle BI server Oracle BI Presentation Services
Metadata
ETL DAC
Oracle
SAP R/3
Siebel
PSFT
EDW Other
Physical Data Model: Overview Data in the OBAW is stored at the lowest possible grain provided by the source system. This allows drilldown to the finest transactional level of detail during analysis and also provides the ability to link to the transactional record in the transactional system in context. Recall that data consolidation is performed during load, taking data from multiple sources, with different codes for similar respective entities, and standardizing it for common analysis in the OBAW.
Is a modular enterprisewide data warehouse data model with conformed dimensions: Sales, Service, Marketing, Distribution, Finance, Workforce, Operations, and Procurement Data integrated from multiple data sources Code standardization Stores transaction data in the most granular fashion Tracks historical changes Supports multiple currencies and languages Is implemented and optimized for Oracle, SQL server, IBM UDB/390, and Teradata
Server Repository: Overview
Dashboards by Role Reports, Analysis/Analytic Workflows Metrics/KPIs Logical Model/Subject Areas Administration Physical Map Data Warehouse/ Data Model Direct Access to Source Data Load Process Staging Area Extraction Process
Multilayered Abstraction:
There are separate physical, logical, and presentation layers. Logical modeling builds upon complex physical data structures. Logical models are independent of physical data sources; that is, the same logical model can be remapped quickly to another data source. There are multipass complex calculated metrics (across multiple fact tables). One logical fact can span several table sources, including aggregates and real-time partitions.
Oracle BI Presentation Services
Oracle BI server
Metadata
Metrics/KPIs:
ETL DAC
Aggregate navigation Federation of queries Prebuilt hierarchy drills and cross-dimensional drills Security and visibility
Tight integration with Oracle eBusiness Suite (EBS) and Siebel Customer Relationship Management (CRM)
Oracle
SAP R/3
Siebel
PSFT
EDW Other
Server Repository: Overview The Oracle BI Application server repository contains metadata for three separate layers: physical, logical, and presentation. Data from the physical layer is mapped to the logical layer, which includes the logical metrics, KPIs, and hierarchies to support analysis and drill paths. The repository includes aggregate navigation, which describes the path used by report queries to access fact data, beginning, where possible, with appropriate aggregate fact tables for summary data, and then drilling further down to the transactional grain, where necessary, or for detailed analysis. The different types of fact tables in the OBAW are covered in the lesson titled Oracle Business Analytics Warehouse Content.
Metrics and Calculations

The applications provide several complex metrics defined logically with an expression builder: Share base (for example, percentage share of one product sales over all products sales) Indices (for example, this divisions performance as a ratio of all divisions) Cross-subject area metrics (across sales and workforcefor example, revenue per employee) Variances (for example, Budget vs. Actual) Time series metrics: Month to Date/Year to Date/Running balances/Moving Averages (for example, Revenue Change percentage year to date) Period Ago Metrics (for example, revenue a year ago) Snapshot at any point of time (for example, number of open service requests) All these are done logically without adding data model or ETL complexity.
Metrics and Calculations All the above metrics and calculations are included in the packaged Oracle BI Applications, in addition to the calculations, KPIs and metrics that are prebuilt during ETL in the physical data model.
Presentation Catalog: Overview

Dashboards by Role Reports, Analysis/Analytic Workflows Metrics/KPIs Logical Model/Subject Areas Administration Physical Map Data Warehouse/ Data Model Direct Access to Source Data Load Process Staging Area Extraction Process Oracle BI server Oracle BI Presentation Services
Metadata
ETL DAC
Oracle
SAP R/3
Siebel
PSFT EDW Other
Presentation Catalog: Overview Oracle BI Applications delivers role-based Interactive Dashboards supporting organizational roles spanning from executives to line managers and individual contributors. Included in the dashboards, which contain tabular as well as graphical interactive elements and reports, are analytic workflows and guided analytics that help to drive critical business decisions and insight. Action Links, as described in the lesson titled Oracle Business Intelligence Application Overview, can drive the user from analytical reports and dashboards back to the transactional application in context to take action on the results of their analysis. Alerts and conditional highlighting provide ways to alert users to business-critical conditions, good and bad, and drive insight and action.
Role-based dashboards Covering more than 100 roles Navigation Most reports have at least one level of navigation embedded. Drill to details from many interactive elementsfor example, chart segments Guided Navigation Conditional navigational links Analytic Workflows Action Links Direct navigation from record to transactional while maintaining context Alerts Scheduled and Conditional iBots Highlighting Conditional highlighting that provides context on metrics (is it good or bad?)
Oracle BI Enterprise Edition Platform Architecture

Does not include the OBAW or BI Applications
Client
Web server Presentation services

Return results
Presentation catalog
Oracle BI server
Query Other data sources
Oracle BI repository
Read/ Write
Oracle BI Enterprise Edition Platform Architecture The diagram in the slide represents the logical relationship between the components of Oracle BI Enterprise Edition (EE). The physical architecture may vary, but a typical instance is described in this lesson. This logical architecture does not account for all utilities required to administer and extend the data warehouse. Oracle BI EE is offered in two major architecture options: Oracle Business Intelligence Platform and Oracle Business Intelligence Applications. Oracle Business Intelligence Platform provides the following: An infrastructure to model data so that users can understand it A server to generate SQL and access, merge, and sort data from multiple sources A simple, highly interactive, Web-based analysis tool, and the ability to construct dynamic reports and alerts
Oracle BI Applications Architecture

Includes infrastructure components and the following: The OBAW and ETL components to load it Informatica, DAC, and BI server metadata
Web server Presentation services DAC repository Read/ Write DAC server Return Analytics results Read Presentation catalog
Client
Informatica repository ETL repository
Informatica Integration Services (ETL)
Transactional database
Oracle BI server
Oracle BI repository Read/ Write
Query Write OBAW Other data sources
Oracle BI Applications Architecture The diagram in the slide represents the logical relationship between the components of Oracle BI Applications. The physical architecture may vary, but a typical instance is described in this module. This logical architecture does not account for all utilities required to administer and extend the data warehouse. Oracle BI Applications provides all that the platform does, plus: Prebuilt Oracle BI repository containing all the mappings, logic, metrics, and KPIs required for the deployed applications Prebuilt Presentation catalog with role-based Interactive Dashboards and reports to support the needs of line managers to chief executive officers Prebuilt OBAW database designed for analytical processing with prebuilt routines to extract, load, and transform data from transactional databases, and the DAC components and a repository used to configure and execute the ETL process
Data Warehouse Load Process

The DAC generates a metadata-driven ETL plan and executes ETL tasks. Informatica Integration Services performs ETL using source-totarget mappings and transformations.
Extraction: Sources are transactional databases. Transformation: Cleansing, translations, aggregation (facts) Load: Target is the OBAW star schemas.
DAC client DAC server Informatica Integration Services (ETL) Informatica repository
Extract
Load OBAW
Workflow
Data Warehouse Load Process The Informatica repository is a small relational database containing metadata necessary for ETL processing. The DAC repository stores metadata about the ETL process, including source and target information, Informatica and other ETL tasks, warehouse and source tables, and other information. All Informatica mappings and workflows are stored in the Informatica repository. Metadata about these mappings are stored in the DAC repository for use by the DAC server in issuing ETL requests to Informatica Integration Services. ETL Tasks A majority of the tasks are of the Informatica type, in which case the DAC server communicates with Informatica Integration Services.
DAC repository
ETL: Process Flow

1
Administrator initiates ETL in the DAC client. The DAC server issues ETL tasks. Informatica ETL tasks are issued against Informatica Integration Services. Informatica Integration Services accesses workflows in the Informatica repository. Informatica Integration Services processes the workflows. Data is extracted from the transactional databases. Data is transformed and then loaded into the OBAW. DAC server
DAC client
Load
Mappings and metadata
Metadata about ETL processing, source and target tables 5
Extract
Informatica 4 Integration Services (ETL)
OBAW
Informatica repository
ETL: Process Flow Extraction: Source Dependent Extract (SDE) routines extract data. Transformation and Load: Source Independent Load (SIL) routines transform and load data into star schemas within the OBAW.
DAC repository
Data warehouse tables
DAC Architecture
Informatica client Client tier
DAC client JDBC
TCP/IP
Informatica Integration Services DAC Server
Server tier
Native DB libraries Database tier OLTP
JDBC DW
DAC Architecture The DAC client is a command and control interface for the data warehouse to allow for the setup, configuration, administration, and monitoring of data warehouse processes. The DAC Server executes instructions from the DAC client and manages data warehouse processes, including scheduling, loading of the ETL, and configuring the subject areas to be loaded. It dynamically adjusts its actions based on information in the DAC repository. The DAC Server issues its ETL commands against Informatica Integration Services, which in turn accesses the Informatica repository for workflow metadata. Informatica client utilities are used to configure and customize the Informatica repository metadata, and are covered in later lessons. JDBC drivers are required for DAC database connectivity. You must install the appropriate JDBC driver in the DAC\lib directory to enable DAC database connectivity. Installation is covered in detail in the lesson titled Installing Oracle BI Applications. The DAC is covered in detail in the lesson titled Working with Data Warehouse Administration Console.
Informatica repository
DAC repository
Deployment Considerations
To maximize ETL performance, it is recommended that four component machines are set up. These are in addition to any transactional databases.
Transactional databases ETL servers
OBAW database ETL clients ETL repositories
Deployment Considerations The above represents a recommended physical deployment of the architecture. ETL Repositories Depending on performance and requirements, the components of ETL repositories can also reside on the same component machine as the OBAW database.
ETL Servers Component

Supports the ETL process Contains:
DAC server: Organizes ETL tasks for processing Informatica Integration Services: Processes ETL Informatica Repository Service: Accepts connections to the Informatica repository from Informatica servers and clients
ETL servers
OBAW database
ETL repositories
ETL clients
ETL Servers Component All servers used in the ETL process reside on this machine. These include the DAC server, Informatica Integration Services, and the Informatica Repository Service. Informatica Integration Services Informatica Integration Services is the third-party software used to populate the OBAW from the source transactional database using ETL routines. You can also install Informatica Integration Services on other machines to increase performance. The other ETL servers can also be hosted on other machines.
The OBAW Database Component

Contains the OBAW database Stores the data accessed from the Oracle BI client Is a database instance whose requirements are entirely dependent on your usage and performance requirements
A unique database instance allows instantiation of optimized parameters
ETL servers
OBAW database
ETL repositories
ETL clients
The OBAW Database Component Single Database These components are all part of the OBAW and are contained in a single database. It is recommended that the OBAW Database machine should be a dedicated machine with its own instance of a supported RDBMS platform. Supported Platforms Supported RDBMS platforms include: Oracle IBM DB2 Universal Server Microsoft SQL Server Teradata
ETL Repositories Component

Supports ETL processing Is a database instance whose requirements are entirely dependent on your usage and performance requirements A unique database instance allows instantiation of optimized parameters Contains: The Informatica repository: Stores mappings and workflows specifying data transformation and flow used by Informatica Integration Services in ETL processing The DAC repository: Is unique to each database warehouse, stores metadata representing warehouse objects and processes, and is used by the DAC client and server to configure and schedule ETL execution plans
ETL servers
OBAW database
ETL repositories
ETL clients
ETL Repositories Component The Informatica and DAC repositories store metadata information about the source and target databases, mappings that dictate data flow, and information about processing performed by the DAC and Informatica Integration Services. Although the OBAW database and the repository databases can exist on one machine, you should separate the repositories onto their own machines, or at least into different databases or schemas on the same machine to maintain the integrity of data. Mappings They provide a set of instructions for retrieving data, performing computations, and loading data.
ETL Clients Component

Contains the clients used to create and administer the OBAW, the DAC repository, and the Informatica repository DAC client:
Used to run, configure, and customize the OBAW ETL objects and processes
Informatica clients:
Used to configure and customize the Informatica repository
ETL servers
OBAW database
ETL repositories
ETL clients
ETL Clients Component This machine is used to manage and extend the Informatica repository and to administer ETL. The DAC client is used to run, schedule, and configure the ETL execution.
ETL Client Component Contents

DAC client:
Is used to schedule, monitor, configure, and customize the OBAW ETL Accesses metadata about ETL mappings, dependencies, and tables in the DAC repository
Informatica Workflow Manager and Designer:
Informatica Repository Manager:

Is used to administer the Informatica repository
Informatica Repository Service Administration Console:

Is used to administer the Repository Service
Is used to customize and test mappings, workflows, and other objects in the Informatica repository
Deployment Summary
Recommended configuration for the OBAW components:
Transactional databases
ETL servers
DAC server and Informatica Integration Services
OBAW database
OBAW
ETL clients
DAC and Informatica clients
ETL repositories
DAC and Informatica repositories
Summary
In this lesson, you should have learned how to: Describe the Oracle Business Intelligence Applications logical architecture Explain the process flow of building the data warehouse Employ the recommended deployment options to maximize data warehouse performance List the components supporting the Oracle Business Analytics Warehouse and the functions performed by each core component
Practice 2-1: Matching Oracle Business Analytics Warehouse Components

This practice covers matching definitions with their corresponding components.
Practice 2-1: Matching Oracle Business Analytics Warehouse Components In this practice, you match the core OBAW components with their corresponding functions.
Practice 2-2: Locating the Oracle Business Analytics Warehouse Components

This practice covers matching components with their setup locations.
Practice 2-2: Locating the Oracle Business Analytics Warehouse Components In this practice, you determine the recommended location for each core component of the OBAW.
Oracle Business Analytics Warehouse Content

Objectives
After completing this lesson, you should be able to: Describe the contents of the Oracle Business Analytics Warehouse Explain the warehouse tables
The Oracle Business Analytics Warehouse (OBAW) Content

Data stored in prebuilt star schemas Supporting tables used for staging and processing
Star Schema
Is a denormalized format that is more effective for query processing Is populated by ETL processes Is composed of:
One fact table A set of dimension tables The joins that relate the dimension tables to the fact table
Star Schema The OBAW data model was designed using dimensional modeling techniques to support the analysis requirement of Oracle Business Intelligence (BI) Applications. Because complex queries run slowly on transactional databases, the database requirements for Oracle BI are different from those of transactional applications. In Oracle BI, you modify data much less frequently than in transactional systems, but you need quick results when viewing new analyses, drilling down to detailed charts and graphs, and creating new briefings. The star schema is optimized for these uses.
Selected Star Schemas of the OBAW

Sales Opportunities Quotes Pipeline Order Management Sales Order Lines Sales Schedule Lines Bookings Pick Lines Billings Backlogs Marketing Campaigns Responses Marketing Costs Supply Chain Purchase Order Lines Purchase Requisition Lines Purchase Order Receipts Inventory Balance Inventory Transactions Finance Receivables Payables General Ledger COGS Call Center ACD Events Rep Activities Contact-Rep Snapshot Targets and Benchmark IVR Navigation History Service Service Requests Activities Agreements Workforce Compensation Employee Profile Employee Events Pharma Prescriptions Syndicated Market Data Financials Financial Assets Insurance Claims Public Sector Benefits Cases Incidents Leads Conforming Dimensions Customer Products Suppliers Cost Centers Profit Centers Internal Organizations Customer Locations Customer Contacts GL Accounts Employee Sales Reps Service Reps Partners Campaign Offers
Selected Star Schemas Oracle BI Applications offers a breadth of analysis, spanning sales, service, and marketing to back-office functions, and include several verticalized areas. To meet the analytical requirements, the OBAW contains a number of horizontal as well as vertical star schemas, as shown in the slide. This is just a sample of the total number of star schemas available. For example, in the pharmaceutical industry, specific star schemas are included to store information about prescriptions and industry syndicated market data. The star schemas listed in the slide can be deployed in the OBAW depending on the applications that are selected, and the use of conforming dimensions allows consistent analysis across different subject areas, applications, and areas of analysis. Conforming dimensions are discussed in detail later in the lesson.
Star Schema Example: General Ledger Revenue

W_GL_REVN_F stores all the revenue transaction amounts in document and local currency and maintains three global currency exchange rates.
OBAW Tables
Fact tables Dimension tables Minidimension tables Subset dimension tables Hierarchy and helper tables Staging tables Aggregate tables Extension tables Internal tables
OBAW Tables
Staging tables Aggregate tables Extension tables Internal tables
Fact Tables
Are central tables in star schemas Typically contain numeric measurements Can be aggregated
Examples: Revenue and units
Also store the most atomic transactional grain Are surrounded by dimension tables
Each dimension table related to the fact table by a single join
Are identified with the suffix _F
Fact Tables In a star schema, the central table is a fact table. It usually contains numeric measurements and has multiple joins to dimension tables surrounding it. Dimension tables are related to the fact table by a single join.
Allows drilling to transactional details during analysis
Types of Fact Tables

All base facts are based on a single business functionfor example, Sales Order Lines, Sales Cycle Lines, and so on. Types of fact tables: Transactional
Mirror of transactional data from the source Lowest atomic grain of each transactional record Examples: Order Lines Fact, Account Receivable Transactions
Snapshot
Cycle Lines
Derived from multiple fact tables, typically store process cycle times Sales Order Cycle Lines, Purchase Cycle Lines Required for specialized transition count metrics Customer State transitions (# New, # Inactive, # Dormant customers, and so on) Performance enhancement on key metrics
State Transition
Aggregate
Types of Fact Tables Transactional fact tables provide the lowest granularity of transactional information available in the source transactional system and can be thought of as mirroring the transactional data from the source. Snapshot fact tables store totalsfor example, theinventory and account balance for a specific point in time. Cycle Lines fact tables provide time-series aggregationsfor example, storing the amount of time that passed between different stages in a sales cycle. State Transition fact tables store specialized transition count metrics that are used in customer segmentation. Aggregate fact tables aggregate detail data at one or more higher levels to aid in query performance.
Snapshot of balances across time Examples: Inventory and Account Balances, Accounts Receivable and Accounts Payable aging snapshots, and Opportunity Pipeline
Dimension Tables
Store descriptions of the characteristics of a business Contain fewer records with many columns Are identified with the suffix _D Have columns that represent attributes of the dimension Have a single primary key joined to the fact table
Join each dimension table with its corresponding fact tables Join the dimension with any associated hierarchy or extension table
Examples: Date, account, and product
Dimension Tables The dimension tables in a star schema store descriptions of the characteristics of a business. A dimension is descriptive information that qualifies a fact. For example, each record in a product dimension represents a specific product. Typically, dimension tables are wide and short because they contain fewer records with many columns. The columns of a dimension table are also called attributes of the dimension. Each dimension table in a star schema has a single primary key joined to the fact table.
Unique numeric key (ROW_WID) for each dimension table is generated during the load process Key is used to:
Conforming Dimension Tables

Are common dimension tables shared by fact tables Enable cross-fact analysis Are used by the OBAW Ensure a consistent view across the OBAW
Provides enterprisewide business analysis
Dimension
Fact
Dimension
Dimension
Fact
Dimension
Conforming Dimensions Conforming dimension tables are shared by multiple fact tables allowing consistent analysis across multiple star schemas.
Minidimension Tables
Include most queried attributes of parent dimensions Are used to increase query performance Are identified with the suffix _MD Prebuilt minidimension tables include:
Minidimension Tables Minidimension tables, which contain subsets of heavily queried attributes of parent dimensions, accrue benefits from segregating these attributes in their own tables.
Responses Agreements Assets Opportunities Orders Quotes Service Requests
Subset Dimension Tables

Are large dimension tables that include well-defined subsets Are extracted from dimension tables Enhance query performance by segregating subsets of frequently queried data Examples:
The Person dimension (W_PERSON_D) includes contacts as well as employees. The Employee subset dimension (W_EMPLOYEE_D) is used in queries concerning employees.
Subset Dimension Tables Subset dimension tables speed up queries, which otherwise would require a significantly costly WHERE clause on a dimension that stored a superset of the queried information. By segregating a commonly queried subset of the data in a dimension, these dimensions increase query performance.
Hierarchy and Helper Tables

Helper tables resolve M:M relationships Hierarchy tables
Flatten tree hierarchies and maintain transactional hierarchies in denormalized dimension tables Enable users to drill through the hierarchy in reports
Internal organization hierarchy table (W_INT_ORG_DH)
Hierarchy and Helper Tables Hierarchy and helper tables are the other special types of tables used in the OBAW. Hierarchies stored in transactional systems are flattened in hierarchy tables in the data warehouse. For example, W_ORG_DH stores the hierarchy relationships for the organization dimension; W_PRODUCT_DH stores hierarchy relationships for the product dimension, and so on. Hierarchy tables are rebuilt with each ETL run. Examples of hierarchy tables in the data warehouse include: Industry (W_INDUSTRY_DH) Organization (W_ORG_DH) Internal Organization (W_INT_ORG_DH) Employee Positions (W_POSITION_DH) Product (W_PRODUCT_DH) The screenshot shows a partial view of W_INT_ORG_DH, which stores the flattened hierarchy of internal organizations. When one organization rolls up into multiple hierarchies, the multiple hierarchies are stored in this table. Each hierarchy is differentiated by a hierarchy number and name.
Hierarchy and Helper Tables (continued) Helper table help to resolve many-to-many relationships. For example, W_PROG_OFFR_H is a helper table that resolves the many-to-many relationship between W_PROGRAM_D and W_OFFER_D. This table is incrementally rebuilt. W_POSITION_H is a helper table that stores the position hierarchy with the level difference between two positions. This table is rebuilt during every ETL process. For more information, refer to the Oracle Business Analytics Warehouse Data Model Reference.
Staging Tables
Are intermediate storage tables within the OBAW Hold data for transformation before loading into the dimension and fact tables
Data is loaded from Oracle and non-Oracle transactional databases.
Truncated after each load
Are loaded by source-dependent processes

Contain the prefix SDE (Source Dependent Extract)
Are sources for Source Independent Load (SIL) processes that load and transform staging table data, internal and external, into the dimension and fact tables
Staging Tables Staging tables are intermediate storage tables within the OBAW. Oracle BI uses these tables as a place to hold data for transformation before loading it into the dimension and fact tables. By performing transformations in staging tables, Oracle BI segregates processing from the transactional system.
Are normally populated only with incremental data Are not persistent
Aggregate Tables
Summarize detail-level facts at a higher level Can dramatically improve query performance Are identified with the suffix _A
Examples:

Daily to yearly sales Sum the fact data by date or sales region Aggregate Table
Month_ID Region_ID Sale_$ 100,000 rows
Base Fact Table

DayTime_ID Store_ID Customer_ID Sale_$ 5 million rows
Aggregate Tables One of the main uses of a data warehouse is to sum up fact data with respect to a given dimension. Performing this summation at query run time is resource intensive and slows down the response time. Thus, some of these sums are precalculated and stored in aggregate tables.
Internal Tables
Assist in the load process and contain warehouse metadata Examples:
A new row is entered into the W_ETL_RUN_S table with a new process ID for every load. W_EXCH_RATE_G stores exchange rates.
Internal Tables Internal tables in the OBAW are those tables that cannot be classified as staging, fact, dimension, hierarchy, extension, or dimensional map tables. These tables store important information that is used during the ETL process, are rebuilt during each ETL process, and are not used by end-user query tools. Internal tables include the following: W_COSTLST_G: The cost list information used by the ETL process. It is mirrored in the Siebel transactional database by S_ETL_COSTLST. W_DUAL_G: The table used by the ETL process to generate calculated values. It is similar to S_DUAL in the Siebel transactional database. W_EXCH_RATE_G: The exchange rate information used by the ETL process. It is mirrored in the transactional database by S_ETL_EXCH_RATE. W_DIM_TABLES_G: A list of data warehouse tables that are map enabled W_LOV_EXCPT_G: An intermediate table for finding exceptions in List of Values W_LST_OF_VAL_G: A list of Values used in the ETL process
Standardized Codes
Intuitive and nonintuitive codes must be standardized across source systems. W_CODE_D stores all the standardized code and name combinations for all languages in the OBAW. Code lookups in load mappings perform a separate extract for codes and insert codes and descriptions into W_CODE_D.
Standardized Codes Some source systems use intelligent codes that are intuitively descriptive, such as HD for hard disks, while other systems use nonintuitive codes (such as numbers, or other vague descriptors), such as 16 for hard disks. While codes are an important tool with which to analyze information, the variety of codes and code descriptions used poses a problem when performing an analysis across source systems. The lack of uniformity in source system codes must be resolved to integrate data for the OBAW. There is a code lookup in load mappings that integrates both intelligent and nonintuitive codes by performing a separate extract for codes, and inserting the codes and their description into the W_CODE_D table. The codes table provides the load mapping with a resource from which it can perform a lookup for code descriptions. The load mapping integrates multiple source system codes by designating one source system instance as a master in a mapping. All other source system codes are then mapped to the master. The screenshot shows a partial view of W_CODE_D: DATASOURCE_NUM_ID: Unique identifier of the source system from which data was extracted SOURCE_CODE: Concatenated value of the various source codes in the hierarchy SOURCE_NAME_2: Description of the source code MASTER_ DATASOURCE_NUM_ID: Unique identifier of the master system
Standardized Codes (continued) MASTER_VALUE: Identifies the description for the master code in the master source system MASTER_CODE: Identifies the corresponding master code for the source code
Standardized Codes: Accounts Receivable Process Example

Key baseline analytic requirements: Invoices Schedules Adjustments (Credit Memo/Debit Memo/Others) Payments Payment Applications Further analysis supported: Aging Buckets Balances Efficiency Volume Risks (Outstanding Balance against Credit Limit)
Standardized Codes: Accounts Receivable Process Example In this Accounts Receivable process example, the need for multisource data consolidation on invoices, schedules adjustments, and so on, can be seen. Based on the analytic requirements, source transactional data must be transformed to standardized OBAW warehouse codes that represent a superset of the required data for all supported source transactional systems. To support source-specific analysis and the ability to drill back to the source transactional system in context, the native transactional codes are retained as well during load.

Standard Warehouse Code Oracle PeopleSoft SAP
Invoice CR Memo/DR Memo Payments
Invoice and Payment Schedules CR Memo and DR Memo Cash Receipts and so on
Invoice items CR Memo and DR Memo items Payments/ Deposits
AR documents with DR document type AR documents with DA document type AR documents with DA document type and A as special indicator AR documents with DZ document type All other types of AR documents
Payment Applications Other
Cash/CR Memo applications/Adjustments All other types of transactions
Payment Item Activities BI/AR: All other types of items
Standardized Codes: Accounts Receivable Process Example (continued) For analysis purposes, all BI Application reporting is based on the standard warehouse code in the table shown in the slide. In the source transactional systems that are extracted for load into the OBAW, invoice, payment, and other types of information are stored in the indicated codes and formats. During the load process, these are standardized to the standard warehouse code for efficient analysis.

All source transaction type code values are stored and appended with standardized warehouse codes. All higher layers in the architecture and metrics use the same standardized warehouse codes. Stored source transaction type code values enable integration back into each transactional system. SAP
Credit memo Credit memo list Credit memo cancellation Debit memo Intercompany credit memo Intercompany invoice Invoice cancellation Pro forma invoice Invoice list Invoice Credit Memo Credit Memo Credit Memo Cancellation Debit Memo Intercompany Credit Memo Intercompany Invoice Invoice Cancellation Pro forma Invoice Standard Invoice Standard Invoice Debit Memo Debit note Invoice Contra Debit Memo Debit note Invoice Contra Debit Memo Debit Memo Standard Invoice Standard Invoice Credit Memo On-Account Credit Credit Memo On-Account Credit Credit Memo Credit Memo
O 4 S P 6 5 N U 3 M
Standardized Codes: Accounts Receivable Process Example (continued) These tables illustrate another example of how invoice and credit information would appear respectively in SAP and Oracle eBusiness Suite (EBS) transactional tables. Notice that they are standardized into an OBAW code during load. In the example of the Standard Invoice warehouse code, you can see that there are multiple type codes and type descriptions in each of the source systems that properly conform to the warehouse code used by the OBAW. However, none of these would be apparent as having the same characteristics. For example, it could require significant research of the SAP schema to understand that Invoice list and Invoice are the same. The strength of the packaged source-specific ETL adapters is that the business process, source table, and code analysis required to standardize all these source codes is available immediately.
TYPE CODE
TYPE_DESC
WAREHOUSE CODE
TYPE CODE
TYPE_DESC
WAREHOUSE CODE
Currency and Multitenancy Support

Support for multiple currencies: Three global and one local transactional (enterprise only) exchange rates available Local amount is stored as a field and not as a conversion rate Common currency conversion mechanism Multitenancy Tenant ID supported in all enterprise analytics tables
Currency and Multitenancy Support Multiple currency support includes precalculation of all supported currency conversions. For example, you might have international customers and transactions occurring in yen and euros. Instead of storing a conversion rate and performing the conversion to the currency required for analysis at query run time, the local amount is stored and converted, for example, into dollars during the ETL process. You will learn more about setting up global currencies in the lesson titled Configuring Analytical Applications. Multitenancy allows a unique Tenant ID to be stored in a dimension table. The column is used, for example, in the Application Service Provider (ASP)/Software As a Service (SOAS) models.
Summary
In this lesson, you should have learned how to: Describe the contents of the Oracle Business Analytics Warehouse Explain the warehouse tables
Installing Oracle BI Applications

Objectives
After completing this lesson, you should be able to install and configure Oracle Business Intelligence Applications and related components.
Oracle Business Intelligence Applications Installation and Configuration Tasks

1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. Verify Preinstallation Requirements. Satisfy Mandatory Preinstallation Requirements. Complete Mandatory Preinstallation Tasks. Install Oracle BI Applications Software. Install Informatica PowerCenter Software. Restore the Oracle BI Prebuilt Repository. Copy source and lookup files. Set code page validation. Set PowerCenter Integration Services custom properties. Install the DAC client. Copy Hibernate libraries. Install JDBC drivers.
Oracle Business Intelligence Applications Installation and Configuration Tasks The Oracle Business Intelligence Applications installation and configuration process consists of the tasks listed in this slide and the next. Each of the steps is covered in detail in the slides that follow. Please note that for the purposes of this training, steps 15, and steps 10 and 11 are already completed in your training environment. You complete the remaining steps in the practices. For more information about installation and configuration, consult the Oracle Business Intelligence Applications Fusion Edition Installation and Configuration Guide.
Oracle Business Intelligence Applications Installation and Configuration Tasks

13. Verify DAC connection configuration. 14. Enable DAC client communication with Informatica. 15. Create a DAC connection. 16. Create the DAC repository schema. 17. Import DAC metadata. 18. Create data warehouse tables. 19. Configure connection between DAC Server and DAC repository. 20. Set DAC system properties. 21. Register Informatica Services in the DAC. 22. Set physical data sources in the DAC. 23. Configure relational connections in Informatica Workflow Manager.
Oracle Business Intelligence Applications Installation and Configuration Tasks (continued) Please note that for the purposes of this training, steps 16 and 17 are already completed in your training environment. You complete the remaining steps in the practices.
Verify Preinstallation Requirements

For operating system, driver, and connectivity software requirements, review the System Requirements and Supported Platforms for Oracle Business Intelligence Applications Fusion Edition. For general guidelines for setting up Oracle Business Analytics Data Warehouse (OBAW), review the Oracle Business Intelligence Applications Fusion Edition Installation and Configuration Guide. For database-specific guidelines for your source OLTP database, review the Oracle Business Intelligence Applications Fusion Edition Installation and Configuration Guide.
Verify Preinstallation Requirements Before you install and deploy Oracle Business Intelligence Applications, you should review the preinstallation and predeployment requirements. The technical documentation, System Requirements and Supported Platforms for Oracle Business Intelligence Applications Fusion Edition, provides information about the supported versions of the following Oracle Business Intelligence Applications components: ETL Servers, ETL Clients, the Oracle Business Analytics Warehouse, and ETL repositories (DAC and Informatica). This includes information about operating systems, software, connectivity, and drivers. The technical documentation, Oracle Business Intelligence Applications Fusion Edition Installation and Configuration Guide, provides general guidelines for setting up Oracle Business Analytics Warehouse (OBAW). This includes information about separating online transactional processing (OLTP) databases and online analytical processing (OLAP) databases, such as the OBAW, recommended tablespace configuration, and so on. The technical documentation, Oracle Business Intelligence Applications Fusion Edition Installation and Configuration Guide, also provides database-specific guidelines for the source OLTP databases that you are using: IBM, SQL Server, Teradata, and Oracle. Please refer to the documentation mentioned here for more information.
Satisfy Mandatory Preinstallation Requirements

Install Oracle Business Intelligence infrastructure on a Windows machine where you will run the Oracle Business Intelligence Applications installer. Upgrade your Informatica PowerCenter license to Version 8.1.1 SP4 before deploying Oracle Business Intelligence Applications 7.9.5. Determine code page and data movement requirements.
Data movement is supported in the following source database to data warehouse configuration modes:

Unicode to Unicode Code page (multi- or single-byte) to Unicode Unicode Code page to Code page (where the code pages are the same)
Satisfy Mandatory Preinstallation Requirements For installing Oracle Business Intelligence Applications, you must have installed Oracle Business Intelligence infrastructure on a Windows machine where you will run the Oracle Business Intelligence Applications installer. The Oracle Business Intelligence Infrastructure instance must be a complete installation of Oracle Business Intelligence Enterprise Edition or Oracle Business Intelligence Standard Edition One. For running Oracle Business Intelligence Applications, you must have installed an Oracle Business Intelligence infrastructure. The Oracle Business Intelligence infrastructure required to run Oracle Business Intelligence Applications may be either the Oracle Business Intelligence Enterprise Edition or the Oracle Business Intelligence Standard Edition One. If you license Informatica PowerCenter with Oracle Business Intelligence Applications, you install Informatica PowerCenter Version 8.1.1 SP4 from the Oracle Business Intelligence Applications installation disk. If you license Informatica PowerCenter separately and you do not have Informatica PowerCenter Version 8.1.1 SP4, you must upgrade your Informatica PowerCenter license to Version 8.1.1 SP4 before deploying Oracle Business Intelligence Applications 7.9.5. The Oracle Business Analytics Warehouse can be deployed in various code page environments and supports global deployments. The slide lists the source database and data warehouse configuration data movement modes that are supported.
Complete Mandatory Preinstallation Tasks

Create databases Install database connectivity software Create ODBC database connections Install Java JDK Download Hibernate libraries
Complete Mandatory Preinstallation Tasks Before you install Oracle Business Intelligence Applications and Informatica PowerCenter, use your target database tool to create database instances to hold the following: the DAC metadata repository, the Informatica repository, the PowerCenter domain configuration, and the OBAW. Make sure that the OBAW instance is granted the SSE_ROLE. Install and configure the appropriate database native connectivity client software on the machines that will host the Informatica PowerCenter Services and DAC Server, and DAC client. The machines that will host these components require connectivity to the OBAW (target) database, transactional (source) databases, and the DAC and Informatica repository databases. The DAC client uses an ODBC connection to create and alter tables in the OBAW. Create an ODBC connection to the OBAW database on the machine that hosts the DAC client. The DAC client and DAC Server require Java JDK. Install Java JDK on the machines that will host the DAC client and DAC Server. On Windows, you must install JDK with no spaces in the directory path. To run the DAC client or DAC Server, you need to have libraries from an open source software product called Hibernate. Hibernate libraries are not installed as part of Oracle Business Intelligence Applications 7.9.x., but have to be downloaded from the Hibernate Web site.
Install Oracle BI Applications Software

The Oracle Business Intelligence Applications installer runs on Windows and requires the Oracle Business Intelligence infrastructure to be installed. Oracle Business Intelligence Applications files are installed in the existing Oracle Business Intelligence infrastructure directory (for example, <DRIVE>:\OracleBI\).
Install Oracle BI Applications Software The Oracle Business Intelligence Applications installer runs on Windows and requires the Oracle Business Intelligence infrastructure to be installed. When you run the Oracle Business Intelligence Applications Installation Wizard, the Oracle Business Intelligence Applications files are installed in the existing Oracle Business Intelligence infrastructure directory (for example, <DRIVE>:\OracleBI\). If you have a previous version of Oracle Business Intelligence Applications installed, you must uninstall this version before you run the installer for Oracle Business Intelligence Applications Version 7.9.5. If you do not uninstall the old version, some Version 7.9.5 directories will not be correctly installed. Be sure to make a backup of your RPD, presentation catalog, and DAC and dwrep directories before you uninstall the old version.
Install Informatica PowerCenter Software

Install Informatica PowerCenter Client Tools.
It must be installed on Windows. Oracle recommends that you co-locate the DAC client with the PowerCenter Client Tools.
Install Informatica PowerCenter Services.
Install Informatica PowerCenter Services Software Follow the installation wizards to install the Informatica PowerCenter software. Informatica PowerCenter Client Tools must be installed on Windows, and you must install the SP4 patch. Informatica PowerCenter Client Tools consists of Workflow Manager, which is used to customize mappings, workflows, and other objects in the Informatica repository; Repository Manager, which is used to restore and manage the Informatica repository; and Designer, which is used to configure and update mapplets, mappings, transformations, and other metadata. You will learn more about Informatica Client Tools in the lessons titled Working with Informatica Designer and Working with Informatica Workflow Manager. Informatica PowerCenter Services can be installed on Windows or Unix and must include the SP4 patch for Oracle BI Applications 7.9. Informatica PowerCenter 8.1.1 has significant architecture changes from previous versions. Before installing Oracle Business Intelligence Applications, Oracle recommends that you read the Informatica PowerCenter documentation to familiarize yourself with the new architecture, components and features. Informatica PowerCenter 8.1.1 SP 4 documentation is included on the Informatica PowerCenter DVD provided with Oracle Business Intelligence Applications. Oracle recommends that you install Informatica PowerCenter Client Tools on the same machine as the DAC client, and install Informatica PowerCenter Services on the same machine as the DAC Server.
It can be installed on UNIX or on Windows. Oracle recommends that you co-locate the PowerCenter Services with the DAC Server.
Restore the Oracle BI Prebuilt Repository

Copy the file Oracle_BI_DW_Base.rep from the OracleBI\dwrep\Informatica\Repository directory to the \InformaticaPowerCenter8.1.1\server\infa_sh ared\Backup directory.
Restore the Oracle BI Prebuilt Repository An Informatica repository file named Oracle_BI_DW_Base.rep is installed into the OracleBI\dwrep\Informatica\Repository directory during the Oracle Business Intelligence Applications installation. You use the Restore option in Informatica PowerCenter Administration Console to load this prebuilt Oracle_BI_DW_Base repository. To load the prebuilt Oracle_BI_DW_Base.rep repository into Informatica: 1. Copy the file Oracle_BI_DW_Base.rep from the OracleBI\dwrep\Informatica\Repository directory on the machine where the Oracle Business Intelligence Applications installer was run to the following folder on the machine where Informatica PowerCenter Services has been installed: on Windows, to the \Informatica PowerCenter8.1.1\server\infa_shared\Backup directory; on UNIX or Linux, to the $Informatica/PowerCenter8.1.1/server/infa_shared/Backup directory. 2. In the Informatica PowerCenter Administration Console, select the Repository Service that was created during the installation process (for example, Oracle_BI_DW_Base), and restore the contents. Detailed steps are provided in the practice for this lesson.
Use the Restore option in the Informatica PowerCenter Administration Console to load the prebuilt Oracle_BI_DW_Base repository.
Copy Source Files and Lookup Files

Copy source files and lookup files from the Oracle Business Intelligence Applications installation directory to the Informatica directory on the Informatica PowerCenter Services machine.
Copy Source Files and Lookup Files You need to copy source files and lookup files from the Oracle Business Intelligence Applications installation directory to the Informatica directory on the Informatica PowerCenter Services machine. To copy source files and lookup files on Windows: 1. Copy the source files in \OracleBI\dwrep\Informatica\SrcFiles to \Informatica PowerCenter8.1.1\server\infa_shared\SrcFiles on the Informatica PowerCenter Services machine. 2. Copy the lookup files in \OracleBI\dwrep\Informatica\LkpFiles to Informatica PowerCenter8.1.1\server\infa_shared\LkpFiles on the Informatica PowerCenter Services machine.
Set Code Page Validation

Configure code page validation for Informatica PowerCenter Integration Services.
Set Code Page Validation You must configure PowerCenter Integration Services for relaxed code page validation by doing the following: Navigate to \Informatica\PowerCenter8.1.1\client\bin, open powermart.ini, scroll to the end of the file, and change the value for the ValidateDataCodePages property from Yes to No. Alternatively, log in to the Informatica PowerCenter Administration Console, select the Integration Service, select Properties > Configuration Properties > Edit, and change the value for the ValidateDataCodePages property from Yes to No. The data code page is disabled here because the code page is identical for both the source and target databases. It is not necessary to validate the code page when data is moved between the compatible source and the target databases.
Set PowerCenter Integration Services Custom Properties

Log in to the PowerCenter Administration Console and create and set custom properties for PowerCenter Integration Services as needed.
Set PowerCenter Integration Services Custom Properties Log in to the PowerCenter Administration Console and create and set custom properties as needed. For each custom property, add a new custom property with an appropriate value. Examples: Create a custom property named ServerPort with a value of an available port number to configure Informatica PowerCenter Services to listen on that port number. The DAC communicates with the PowerCenter Integration Services service using this port. Create a custom property named SiebelUnicodeDB and set OLTP (biapps@orcl) and OLAP (obaw@orcl) values for SiebelUnicodeDB if your data movement is from Unicode to Unicode.
Install the DAC Client

The DAC client is installed by the Oracle Business Intelligence Applications installer. Runs only on a Windows platform Should be installed on the same machine that runs Informatica PowerCenter Client tools
Install the DAC Client The DAC client is installed by the Oracle Business Intelligence Applications installer. The DAC client only runs on a Windows platform. Oracle recommends that you run the DAC client on the Windows machine that runs the Informatica PowerCenter Client tools.
Copy Hibernate Libraries

Copy Hibernate libraries to the appropriate DAC directories.
Copy Hibernate Libraries To run the DAC client or DAC Server, you need to have libraries from an open source software product called Hibernate. Hibernate libraries are not installed as part of Oracle Business Intelligence Applications 7.9.5., but have to be downloaded from the Hibernate Web site. Oracle recommends that you download Hibernate Core Package Version 3.2.x GA or later. Newer versions of Hibernate Core Package 3.2 are now generally available (for example, Hibernate Core Package Version 3.2.5 GA). DAC is supported on the libraries of these versions also. You can download Hibernate Core Package from http://www.hibernate.org. For the purposes of this training, the Hibernate libraries have already been downloaded to your training environment. In the practice for this lesson, you copy the Hibernate libraries to the appropriate DAC directories as indicated in the table in this slide.
Install JDBC Drivers

Install JDBC drivers in the \OracleBI\DAC\lib directory for DAC database connectivity.
Install JDBC Drivers You must install the appropriate JDBC driver in the DAC\lib directory to enable DAC database connectivity. If the required JDBC drivers are not already installed, you need to install the JDBC driver on the machines where the DAC client is installed.
Verify DAC Connection Configuration

Open the DAC config.bat file in the \OracleBI\DAC directory and verify the connection configuration for the DAC repository.
JAVA_HOME variable points to the directory where the Java SDK is installed. DAC_HOME variable points to the directory where DAC is installed.
Verify DAC Connection Configuration The connection information in the DAC config.bat file is configured during Oracle BI Applications installation. To verify or change the connection information, open the DAC config.bat file in the \OracleBI\DAC directory. Verify that the JAVA_HOME variable points to the directory where Java SDK is installed. In this example, it is set to JAVA_HOME= C:\jdk1.5.0_11. Make sure there are no spaces in the path reference. Verify that the DAC_HOME variable points to the directory where DAC is installed. In this example, it is set to DAC_HOME= C:\OracleBI\DAC.
Enable DAC Client Communication with Informatica

The DAC client uses the Informatica PMREP and PMCMD command-line programs to communicate with the Informatica PowerCenter.
The DAC client uses PMREP to synchronize DAC tasks with Informatica workflows and to keep the DAC task source and target tables information up-to-date.
Enable DAC Client Communication with Informatica The PMREP program is installed in the Informatica PowerCenter Client and the Informatica PowerCenter Services bin directories. Because of the recommendation to co-locate the DAC client with the PowerCenter Client, the PMREP program is available on the machine for the DAC client to use. The PMCMD program is installed in the PowerCenter Services bin directories. In this training environment, PowerCenter Services has been installed on the same machine as the DAC client and PowerCenter Client 8.1.1 SP4. Therefore, all that is needed is to copy the pmcmd.exe program from the C:\Informatica\PowerCenter8.1.1\server\bin directory to C:\Informatica\PowerCenter8.1.1\client\bin directory. In order for the DAC client to be able to use the PMREP and PMCMD programs, you need to create a system variable that defines the path of the Informatica domain file domains.infa. Although it is not shown in the slide, the path should include the name of the file. You also need to add the directory path to Informatica PowerCenter binaries to the path environment variable (not shown here).
In order for the DAC client to be able to use the PMREP and PMCMD programs, create a system variable that defines the path of the Informatica domain file.
PMCMD Command
The Informatica PMCMD command is used by the DAC server to initiate workflows in the Informatica repository. Syntax:
Calls PMCMD User name variable Password variable
Port number
Repository folder
Workflow name
Indicates workflow
Nowait option
PMCMD Command This slide details the use and syntax of the PMCMD command-line utility, which is used by the DAC server to submit ETL workflows on the Informatica server for execution.
[PATHvariable]\PMCMD"start%INFA_USER%INFA_PASSWORD 4001 Oracle_BI_DW_Base:SDE_AssetFact 0 0
Create a DAC Connection

Create a DAC connection, which is a stored set of login details that enable you to log in to the DAC client and connect to the DAC Repository.
Create a DAC Connection Before you can connect to the DAC client, you need to create a DAC connection. A DAC connection is a stored set of login details that enable you to log in to the DAC client and connect to the DAC repository. To create a DAC connection, start the DAC client and select Configure > Create Connection in the DAC client Login screen. Provide the appropriate connection details in the Configuring dialog box, as shown in the screenshot, and then test the connection.
Create the DAC Repository Schema

When you log in to DAC and connect to a DAC repository for the first time, the DAC detects that the DAC repository tables do not exist in the database and you are asked whether you want to create a repository.
Create the DAC Repository Schema When you log in to DAC and connect to a DAC repository for the first time, the DAC detects that the DAC schema does not yet contain repository tables and you are asked whether you want to create a repository. Enter the tablespace name (optional) and click Yes. The DAC creates the repository tables and the DAC client opens. This assumes that a user/schema and tablespace have already been created in the database.
Import DAC Metadata

In the DAC client, select Tools > DAC Repository Management > Import to import the DAC metadata for selected source systems into the DAC repository schema.
Confirm import.
Check log file.
Import DAC Metadata After you create the DAC repository schema, you use the DAC client to import the DAC metadata. Select Tools > DAC Repository Management > Import to import DAC metadata for selected source systems into the DAC repository schema. Verify that the Logical check box and the System check box are selected (this is the default). Logical imports all information contained in the DAC Design view and the execution plan information for the DAC Execute view. System imports all information contained in the DAC Setup view, except passwords for servers and database connections. Run Time (not selected here) imports ETL Run History and the last refresh date information. This option is not necessary when you first import DAC metadata because no ETL has been run yet. In the Applications List table, use the check boxes in the Selected column to specify the source system applications (Siebel 8.0 and Oracle 11.5.10 in this example) for which you want to import the ETL metadata. Be sure to select Universal (selected by default). To avoid possible ETL errors in other applications (for example, missing tasks), you must import the Universal application. The import process may take a long time, depending on the selected source systems. When the process is complete, the DAC displays a status box containing a success or failure message. If the process fails, use the \DAC\log\import.log file to diagnose the errors.
Select desired source systems.
Create the Data Warehouse Tables

Select Tools > ETL Management > Configure in the DAC client to create tables in the OBAW database.
1. Set source and target database platforms. 3. Enter the details of the database where you want to create the data warehouse tables.
2. Select Create Data Warehouse Tables.
4. Check log file.
Create the Data Warehouse Tables You use the DAC client to create tables in the Oracle Business Analytics Warehouse database. The DAC client uses an ODBC connection to the Oracle Business Analytics Warehouse database for this procedure. You must create the ODBC connection and a schema to hold the OBAW tables before you create the OBAW tables using the DAC. To create the OBAW tables, select Tools > ETL Management > Configure, select the target and source database platforms, select Create Data Warehouse Tables, and enter data warehouse details in the Data Warehouse Configuration Wizard. If you leave the Container field blank, the DAC creates a container by default for all of the source business applications that you selected when you imported the seed data into the DAC metadata repository earlier.
Configure Connection Between DAC Server and DAC Repository

In the DAC client, select Tools > DAC Server Management > DAC Server Setup to configure the connection between the DAC Server and the DAC repository.
machine_name
Configure Connection Between DAC Server and DAC Repository You must configure the connection between the DAC Server and the DAC repository. In Windows, you can use the DAC client to configure a DAC Server that runs in the same \DAC folder. If the DAC Server is co-located with a configured DAC client in the same \DAC folder, you can set the connection between the DAC Server and DAC repository using the DAC client. In the DAC client, select Tools > DAC Server Management > DAC Server Setup. The DAC repository that you connect to using the DAC client is the one that will store the DAC Server repository connection information that you specify in this procedure. In the Repository Connection Information tab, enter the appropriate information. In this example, because the DAC Server is running on the same machine as the DAC client, you can click Populate from preconfigured client connection to populate the fields with connection details from the DAC client. Click Test Connection to make sure that the DAC repository connection works.
Set DAC System Properties

Set DAC system properties to ensure proper integration between the DAC client, the DAC Server, and Informatica.
Set DAC System Properties You need to set DAC system properties to ensure proper integration between the DAC client, the DAC Server, and Informatica. You set DAC system properties in the DAC System Properties tab in the Setup view in the DAC client. For example, you need to set the: Location of the Informatica parameter files Name of the main Informatica repository Name of the DAC repository Name of the DAC Server host and so on.
Register the Informatica Services in the DAC

In the DAC client > Setup view > Informatica Servers tab, register the Informatica Integration Services service and the Informatica Repository Service.
Register the Informatica Services in the DAC In the DAC client, display the Setup view, and then display the Informatica Servers tab. Register the Informatica Integration Services service by modifying the record with Name = Oracle_BI_DW_Server. Accept all defaults except for Server Hostname and Password. Test the connection (Informatica Service and DAC Server must be running). You should receive the message Connection to Oracle_BI_DW_Server successfully established! Register the Informatica Repository Service, by modifying the record with Name = Informatica_REP_Server. Accept all defaults except for Server Hostname and Password. Test the connection. You should receive the message Connection to Informatica_Rep_Server successfully established! Note: The passwords are not verified; make sure they are correct.
Set Physical Data Sources in the DAC

Set the transactional and data warehouse physical data sources in the DAC client.
Set Physical Data Sources in the DAC In the DAC client, display the Setup view and the Physical Data Sources tab. The Physical Data Sources tab displays a precreated record for the data warehouse with the name DataWarehouse, and one or more records for the OLTP sources. The records that are created by DAC for the OLTP sources depend on the business application source systems you selected when importing the DAC metadata. Edit the DataWarehouse and OLTP sources by providing the instance name, table owner and password, the database host, port number, and default index space. Test the connections and verify that you receive the messages that the connections are successfully established.
Configure Relational Connections in Informatica Workflow Manager

In Informatica Workflow Manager, create a connection for each transactional database and a connection for the OBAW database.
Configure Relational Connections in Informatica Workflow Manager In the Informatica Workflow Manager, select Connections > Relational to display the Relational Connection Browser. You need to create a connection for each transactional (OLTP) database, and a connection for the Oracle Business Analytics Warehouse (OBAW) database. Click New to add a new connection, and then enter the details for the connection object. You must specify the DataWarehouse exactly as it appears in the Physical Data Sources tab in the DAC Setup view.
Oracle BI Applications Topology
Oracle BI Applications Topology Oracle Business Intelligence Applications and Informatica PowerCenter can be deployed flexibly across a wide range of topologies on different platforms and combinations of platforms. The figure in this slide shows a typical deployment topology. Machine A is a machine that has Oracle Business Intelligence Enterprise Edition or Oracle Business Intelligence Standard Edition One installed, on which you run the Oracle Business Intelligence Applications installer to install the Oracle Business Intelligence Applications files. Note: The instance of the Oracle Business Intelligence Enterprise Edition or Oracle Business Intelligence Standard Edition One does not need to be the functional version of the Oracle Business Intelligence Enterprise Edition that you will use to deploy dashboards in your live system. This instance is only required to enable the Oracle Business Intelligence Applications installer to install the Oracle Business Intelligence Applications files on a machine. After the Oracle Business Intelligence Applications files have been installed on Machine A, the DAC client is deployed to Machine B, and the DAC Server is deployed to Machine C. In addition, the following files are copied from the installation machine (Machine A) to the Business Intelligence Deployment Tier (Machine Group F) as follows:
Oracle BI Applications Topology (continued) The OracleBI\Server\Repository\EnterpriseBusinessAnalytics.rpd file is copied from Machine A to the machine that runs the BI Server in Machine Group F. The OracleBIData\Web\Catalog\EnterpriseBusinessAnalytics\*.* files are copied from Machine A to the machine that runs the BI Presentation Services Catalog in Machine Group F. Machine B is a machine that runs the DAC client and the Informatica PowerCenter Client Tools. Machine C is a machine that runs the DAC Server and the Informatica PowerCenter Services. Machine D is a machine that hosts the transactional (OLTP) database. Machine E is a machine that hosts the Oracle Business Analytics Warehouse database. Machine Group F is a group of machines that runs the Oracle Business Intelligence Enterprise Edition components. For example, one machine might run the BI Server and BI Applications RPD, and another machine might run the BI Presentation Services and the Oracle Business Analytics Warehouse. You can also run Oracle Business Intelligence Applications on a single machine installation of Oracle Business Intelligence Standard Edition One.
Summary
In this lesson, you should have learned how to install and configure Oracle Business Intelligence Applications and related components.
Practice 4-1 Overview: Configuring the Training Environment

This practice covers postinstallation tasks to configure the training environment before you populate and customize the Oracle Business Analytics Warehouse.
Practice 4-1 Overview: Configuring the Training Environment The Oracle Business Intelligence platform and Oracle BI Applications have already been installed in your training environment. This includes the Informatica PowerCenter, the Data Warehouse Application Console (DAC), two database schemas (DAC and INFA) that were created during the installation process, and one database schema (BIAPPS) that is included as part of the training environment: DAC: Contains DAC repository tables INFA: Contains Informatica repository tables BIAPPS: Contains Oracle E-Business Suite source data In this practice, you perform the additional, postinstallation configuration of the DAC and Informatica in your environment. Performing these tasks is a convenient debugging technique, as most configuration issues arise from the steps performed in this practice.
Understanding the ETL Process

Objectives
After completing this lesson, you should be able to: Explain the extract, transform, and load (ETL) process used to load the Oracle Business Analytics Warehouse (OBAW) Describe the differences between a full load and an incremental load of the OBAW Identify the applications and mechanisms used to support the ETL process
ETL Process: Overview

Data is loaded from the transactional database into the OBAW by the ETL process.
Run using the DAC client
Running an ETL initiates:

Tasks run by the DAC server to prepare internal tables A series of Informatica mappings and transformations executed by the Informatica server as requested by the DAC server
The Informatica server accesses metadata in the Informatica repository to define how the data moves between the transactional database and the OBAW.
ETL Process: Overview

At a high level, the ETL process is completed in three steps. The DAC server executes as many steps in parallel as possible.
Reads the data necessary for analysis from transactional databases Loads the rearranged data into the fact and dimension tables in OBAW
Transform Extract
Load
Cleans the data and rearranges as required for the star schema
ETL Process: Overview The main point to note here is that ETL is a parallel process. The graphics and the callouts in the slide define the ETL process.
ETL Process Steps

Step 1: Extract and load staging tables.
Extracts and consolidates data from the transactional system and writes to the OBAW staging tables
Step 2: Transform data.

Transforms data in staging tables in preparation for load Computes calculated fields
Step 3: Load dimension and fact tables.

Generates and maintains warehouse primary keys Loads hierarchy tables Loads dimension and fact tables
ETL Process Steps You can identify the tables used during the phases in the data warehouse by the suffix of their names (for example, _F for fact, _D for dimension, and so on). Note that transformation is performed on the data warehouse to save impact on the transactional database during ETL.
Data Extraction and Load Process: Extract

Uses source-specific and Universal Adaptors Exposes simplified business entities from complex source systems Converts source-specific data to a universal staging table format
Staging tables
SQL
SQL
ABAP
SQL
SQL
Power Power Connect Connect
Extract
Extract
Siebel OLTP
Oracle
Other
PeopleSoft SAP
Data Extraction and Load Process: Extract Extract Extract mappings encapsulate the complexity of the source and expose a simplified view of the business entities. Adaptor Types Packaged source-specific adaptors include Siebel, Oracle, PeopleSoft, and SAP. Universal Adaptors are used for legacy data sources or sources where the extraction logic is not prepackaged. They can also be used for some supplementary data.
App Layer
App Layer
Universal Adaptors
Are used for sources with no prepackaged business adaptor Transform and load data from universal sources through a flat file interface
Require flat files or tables that meet a defined standard format
Data Extraction and Load Process: Load

Handles: Slowly changing dimensions Key lookup resolution or surrogate key generation Insert and update strategies Currency conversion Data consolidation
Oracle Data Warehouse
Load
Load
Staging tables
Data Extraction and Load Process: Load During load, data is converted into standard codes.
ETL Mappings
The various ETL processes are carried out by the following two types of mappings: Source Dependent Extract (SDE) mappings load the staging tables from the transactional system source. Source Independent Load (SIL) mappings transform and load data from the staging tables into the OBAW base tables:
Dimension tables Fact tables Minidimension tables Hierarchy tables Aggregate tables
Full and Incremental ETL

Full ETL
Initially, a full load is performed to extract all the required data and load all tables in the Oracle Business Analytics Warehouse.
Incremental ETL
Subsequently, the data warehouse is updated incrementally. It loads only data that has changed since the most recent ETL was processed.
DAC Tasks
Are stored in the DAC repository Can be of four types:
Informatica: Calls Informatica workflow used to process ETL External Program: Calls an operable program on the operating system where the DAC server is running SQL File: Calls a SQL script in .xml or .sql format Stored Procedure: Calls a stored procedure defined on the DAC repositorys defined databases
Task Informatica workflow for incremental load Informatica workflow for full load Logical DAC folder points to Informatica folder
Example: DAC Informatica SDE task for Revenue fact
DAC logical target connection
DAC logical source connection
DAC Tasks DAC tasks are discrete entities in the definition of a warehouse application. Each task run as part of an ETL performs a step in the ETL process, and can be of four types. A majority of the OBAWs DAC tasks are Informatica tasks, which, as shown in the slide, call Informatica workflows in the Informatica repository and run against the Informatica server.
DAC Task Phases

The DAC server prioritizes ETL tasks by phases as follows (from high to low priority): General:
Load internal tables with the required data.
Extract Dimension:
Extract Fact:
Use SDE mappings to extract data from source transactional tables and load fact staging tables.
Load Dimension:
Use SIL Informatica mappings to load data from dimension staging tables into dimension tables.
DAC Task Phases The task phase, which determines priority during ETL at run time, needs to be defined for every DAC task. The list on these slides includes important seed task phases. To view other task phases or to add new ones, in the DAC client, select Tools > Seed Data > Task Phases. It is recommended that you use existing packaged task phases. Although it is possible to define and assign custom phases and associated priorities, this can have important repercussions on task precedence when building execution plans.
Use SDE Informatica mappings to extract data from source transactional tables and load dimension staging tables.
DAC Task Phases

Load Fact:
Use SIL mappings to load data from fact staging tables into fact tables.
Dimension Hierarchy:
Use SIL mappings to load dimension hierarchy tables. Use SIL mappings to load aggregate tables.
Post Load:
Use post-load processing (PLP) mappings to update and load tables, including hierarchy and aggregate tables.
Aggregate:
Internal Tables
Are located in the OBAW Assist in the load process and contain metadata for the data warehouse including parameters used in the ETL process Examples:
Internal Tables The internal tables store some static values, for example, language and currency, which are not updated incrementally. General tables end with a suffix of _G.
W_ETL_RUN_S stores a record per ETL run. W_EXCH_RATE_G stores exchange rates. W_COSTLST_G stores costlist data. W_DUAL_G is used to generate calculated values. W_LST_OF_VAL_G stores a list of values used in the ETL process.
Change Capture
Change capture logic is included in the SQL of the SDE mapping. The LAST_UPDATE_DATE column is compared to the $$LAST_EXTRACT_DATE parameter to detect changed records. Records are loaded if LAST_UPDATE_DATE is greater than the value for the $$LAST_EXTRACT_DATE parameter. The $$LAST_EXTRACT_DATE parameter value is passed from the DAC during ETL run time.
Change Capture Change capture logic is included in the SQL WHERE clause of source qualifier transformation of the SDE Informatica mapping. (You learn more about source qualifier transformations in the lesson titled Working with Informatica Designer.) The LAST_UPDATE_DATE column in Oracle source databases is used in incremental loads to identify changed records. LAST_UPDATE_DATE is compared to the DAC parameter $$LAST_EXTRACT_DATE to determine which records have been updated since the last ETL run. Records are loaded if LAST_UPDATE_DATE is greater than the value for the $$LAST_EXTRACT_DATE parameter. The value for the $$LAST_EXTRACT_DATE parameter is passed from the DAC during ETL run time. The TO_DATE function is used to convert the value to the proper format.
Restart Mechanisms
Restart mechanisms are built into all mappings. Rows that have been loaded or updated in the same ETL run are not reprocessed.
Unspecified Mappings
During a full load, the SDE mappings include logic to insert unspecified values. All fact rows from source transactional system tables that do not have a matching row in their dimension tables are defaulted to the unspecified value.
Executing ETL
In the DAC client:
Run the ETL execution plan.
The DAC server runs tasks based on the ETL phase and task precedence.
Most ETL tasks call Informatica workflows. Workflows are run in parallel on Informatica servers
SDE workflows load staging tables.
SIL workflows load fact and dimension tables.
ETL Process: Summary

SDE routines extract data from sources and load data into OBAW staging tables. SIL routines transform data and load data into OBAW fact and dimension tables.
Source Dependent Extract Source 1
Source 1 Full & refresh extraction

Source Dependent Extract Source 2 Source Dependent Extract Source 3
OBAW staging tables
Source 2
Source Independent Loading
OBAW
Source 3
Source Dependent Extraction

Summary
In this lesson, you should have learned how to: Explain the extract, transform, and load (ETL) process used to load the Oracle Business Analytics Warehouse (OBAW) Describe the differences between a full load and an incremental load of the OBAW Identify the applications and mechanisms used to support the ETL process
Practice 5-1: Exploring Oracle BI ETL Metadata

This practice covers exploring the prebuilt Oracle Business Intelligence ETL metadata to gain a high-level understanding of the key elements, processes, and naming conventions.
Practice 5-1: Exploring Oracle BI ETL Metadata The goal of this practice is to explore some of the prebuilt Oracle Business Intelligence ETL metadata to gain a high-level understanding of some of the key elements, processes, and naming conventions. In the practice for the lesson titled Installing Oracle BI Applications, you configured the software components required to run ETL for the Oracle Business Analytics Warehouse. Before loading and customizing the data warehouse, you explore some of the prebuilt metadata used to perform ETL. This exploration will allow you to relate the fundamental steps of the Oracle Business Analytics Warehouse ETL process to prebuilt metadata in the Oracle Informatica Repository and the DAC repository.
Working with Informatica Designer

Objectives
After completing this lesson, you should be able to: Identify the Informatica repository objects used to configure the Oracle Business Analytics Warehouse (OBAW) Navigate the set of tools in Informatica Designer used to configure Informatica repository objects.
Informatica Designer
Consists of a set of tools that you use to: Create, modify, and maintain mappings that specify how to move and transform data between sources and targets Create, modify, and maintain the source definitions, target definitions, mapplets, and transformations used to build mappings
Informatica Designer The Informatica Designer is a set of tools used to create, modify, and maintain mappings that move data between sources and targets. The components of mappings include source definitions, target definitions, mapplets, and transformations, each of which is presented in more detail in the subsequent slides. The primary goal of this lesson is to become familiar with the Informatica Designer and its tools, which are used to create ETL mappings and their components.
Informatica Designer User Interface

Navigator Connects to multiple repositories and folders
Workspace Is used to view or edit sources, targets, mapplets, mappings, and transformations
Status Bar Displays status of performed operations
Output Provides task details, such as saving work, or validating a mapping
Informatica Designer User Interface This slide introduces the Informatica Designer user interface. Refer to the callouts in the slide for details about the different user interface components.
Key Terms
Folder Source definition Target definition Mapping Transformation Mapplet Port
Key Terms This slide introduces the key Informatica Designer terms covered in this lesson. Each is presented in detail in the slides that follow.
Folder
Organizes and stores Informatica repository metadata Prebuilt SDE and SILOS folders should not be modified.
Folders may be overwritten during upgrades.
Custom folders Oracle SDE folder
Create and use custom folders for new or modified Informatica repository objects.
Customizations are preserved during upgrades.
SILOS folder
Siebel SDE folder
Folder Informatica repository folders provide a way to organize and store all metadata in the repository. Prebuilt SDE and SILOS folders ship with the Oracle Business Analytics Warehouse (OBAW) and contain prebuilt Informatica repository objects. The SDE folders are organized by their respective source applications and versions. For example, the folder SDE_ORA11510_Adaptor contains the Informatica SDE repository objects for Oracle 11.5.10; the folder SDE_SBL_80_Adaptor contains the Informatica SDE repository objects for Siebel 8.0, and so on. If you want to make changes to the Oracle Business Analytics Warehouse, you must create a custom folder and make the changes in it. Do not change objects in any of the shipped folders unless explicitly directed by Oracle. The shipped folders and the objects within them may be overwritten in future upgrades. The deployed repository does not include any custom folders; you must create your own. You should create a custom folder for each SDE folder you have deployed that will have customizations. These folders hold the extract mappings to various sources. You should also create a separate custom folder for the customizations you want to make to the SILOS folder. Do not store customized extract and load mappings in the same folder.
Folder (continued) The easiest way to modify an object is to copy an existing object from the shipped folder into the corresponding custom folder and to reuse existing business components, source and target definitions, transformations, mapplets, and mappings. You use another Informatica tool, Repository Manager, to create custom folders. You learn how to create custom folders in the practices for this lesson.
Source Definition
Repository object containing a detailed description of database objects or files that provide source data
Source definitions
Source Definition Source definitions provide detailed descriptions of tables or files that provide source data in mappings and mapplets. To extract data from a source, you must first define sources in the repository. The main purpose of this slide is to identify where the sources are located in the Designer user interface. An example of how source definitions are used in mappings and mapplets is provided later in this lesson.
Target Definition
Repository object containing a detailed description of database objects or files that contain target data
Target Definition Target definitions provide detailed descriptions of objects or files that contain target data in mappings. Target definitions typically represent data warehouse tables. When you create a mapping, you must add a target definition to it. Typically, each mapping is designed to load one target table. This slide identifies where the targets are located in the Designer UI. An example of how target definitions are used in mappings is provided in another slide later in this module.
Target definitions
Mapping
Repository object representing the data flow between sources and targets used to extract, transform, and load data
Mappings
Mapping A mapping is a set of source and target definitions linked by transformation objects that define the rules for data transformation. Mappings represent the data flow between sources and targets. When the Integration Service runs a session, it uses the instructions configured in the mapping to read, transform, and write data. Every mapping must have the following components: Source definition: Describes the characteristics of a source table or file Transformation: Modifies data before writing it to targets. Use different transformation objects to perform different functions. Target definition: Defines the target table or file Links: Connect sources, targets, and transformations so that the Integration Service can move the data as it transforms it Source definitions, target definitions, transformations, and links are described in more detail in subsequent slides. A mapping can also contain one or more mapplets. A mapplet is a set of transformations that you build in the Mapplet Designer and can use in multiple mappings. When you add an object to a mapping, you configure the properties according to the way you want the Integration Service to transform the data. You also connect the mapping objects according to the way you want the Integration Service to move the data. You connect the objects through ports.
Transformation
Repository object that generates, modifies, or passes data
Transformation Transformations are used in mappings to generate, modify, or pass data. Transformations in a mapping represent the operations that the Integration Service performs on the data. Data passes through transformation ports that you link in a mapping or mapplet. Transformations can be active or passive. An active transformation can change the number of rows that pass through it, such as a Filter transformation that removes rows that do not meet the filter condition. A passive transformation does not change the number of rows that pass through it, such as an Expression transformation that performs a calculation on data and passes all rows through the transformation. Transformations can be connected to the data flow, or they can be unconnected. An unconnected transformation is not connected to other transformations in the mapping. An unconnected transformation is called within another transformation and returns a value to that transformation.
Transformations
Transformation Type
Performs a distinct function in transforming data Examples:
Transformation Type
Source qualifier Expression Aggregator Filter Update strategy Lookup Joiner
Function
Brings data into the mapping process from one or more related tables in the same data source
Performs aggregate calculations Adds a conditional filter Allows inserts, updates, deletes, and rejects Looks up values and passes to other objects Allows joins between tables in different data sources
Transformation Type Different transformation types are used in mappings. Transformations can be used, for example, to aggregate or cleanse data during ETL. This is not a comprehensive list, but the major transformation types are listed. A comprehensive list can be found in the Informatica documentation.
Performs simple calculations
Mapplet
Repository object that contains a set of transformations whose logic can be reused in multiple mappings
Mapplets
Mapplet A mapplet is a reusable object that you create in the Mapplet Designer. It contains a set of transformations and enables you to reuse that transformation logic in multiple mappings. Examples of mapplet logic include logic to obtain currency conversion rates or logic to obtain the ETL_PROC_WID, which is the unique identifier for an ETL run. When you use a mapplet in a mapping, you use an instance of the mapplet. Like a reusable transformation, any change made to the mapplet is inherited by all instances of the mapplet.
Port
Represents a column of data Is used to connect sources, transformations, and targets within a mapping or mapplet
Ports Double-click to open the Edit Transformations window.
Ports
Port Every source definition, target definition, mapplet, and transformation contains a collection of ports, each representing a column of data. The screenshot shows the ports for an expression transformation in the SDE_ORA_GLRevenueFact mapping. After you add and configure source definitions, target definitions, and transformation objects, including mapplets, in a mapping, complete the mapping by connecting the mapping objects through the ports. To connect ports, drag a port from one mapping object to the corresponding port in another mapping object. The Designer validates the connection and creates the connection only when the connection meets the validation requirements.
Port Type
Defines how data is moved in a mapping Examples:
Port Type
Input Output Input/Output Variable Receives data Passes data
Function
Receives data and passes it unchanged Stores values across rows
Port Type The port type determines how data is moved in a mapping. Input ports receive data. Output ports pass data. Input/Output ports receive data and pass it unchanged. Variable ports are used to store values across rows. Expressions with variables can be applied to variable ports to perform procedural calculations on data from the previous rows. Sources provide data, so they contain only output ports. Targets receive data, so they contain only input ports. Transformations and mapplets contain a mix of input, output, input/output, and variable ports, depending on the transformation and its application. See the Informatica documentation for more information and examples.
Informatica Designer Tools

Source Analyzer
Use to import, create, and modify source definitions.
Target Designer
Use to import, create, and modify target definitions. Use to create reusable transformations.
Select Tools from the Designer menu bar.
Mapplet Designer
Use to create and modify mapplets.
Mapping Designer
Use to create and modify mappings. *Not used in this course
Informatica Designer Tools This slide identifies the Informatica Designer tools that you use throughout the course to configure source definitions, target definitions, mappings, mapplets, and transformations. You learn how to use these tools in the practices in this course. For reference, the Transformation Developer is listed, but it is not used in this course.
Transformation Developer*
Source Analyzer
Used to import, create, or modify source definitions
Source Analyzer Before creating a mapping, sources must be defined in the repository. Use the Source Analyzer to import or create source definitions for flat file, XML, COBOL, Application, and relational sources for mappings. Source definitions include properties such as column names and data types. You can create source definitions for file and relational sources in the following ways: Import definition. Create a source definition based on a target definition. Manually create a source definition. Copy an existing source. If you want to use existing sources for custom mappings, they must be copied from the shipped SDE and SILOS folders to a custom folder.
Example: Importing a Source Definition

2. Select Import from Database. 1. Select folder.
3. Select ODBC data source. 4. Provide ODBC credentials.
5. Select tables for import and click OK. 6. Source definition is displayed in Source Analyzer.
Example: Importing Source Definition Sources needed to build mappings can be imported from data sources. Connections to external data sources are made via Open Database Connectivity (ODBC) data sources. The callouts in the slide show the steps for importing a source from a database.
Target Designer
Used to import, create, and modify target definitions
Target Designer Before creating a mapping, targets must be defined in the repository. Use the Target Designer to import, create, and maintain target definitions for mappings. Target definitions include properties such as column names and data types. Create target definitions for file and relational sources in the following ways: Import definition. Create a target definition based on a source definition. Manually create a target definition. Copy an existing target. If you want to use existing targets for custom mappings, they must be copied from the shipped SDE and SILOS folders to a custom folder. The steps for importing target definitions are identical to importing source definitions and are not repeated here.
Mapping Designer
Used to create and modify mappings
Mapplet
Drag mappings and objects into the workspace.
Modify mappings in the workspace.
Mapping Designer The Mapping Designer is used to create, modify, and validate mappings. Drag source, target, transformation, mapplet, and mapping repository objects from the Navigator to the Mapping Designer workspace to build or modify mappings. When building mappings, you can copy existing mappings or create new mappings. To copy a mapping, select it in its respective folder and select Edit > Copy. Then select the Mappings folder in the custom folder you created and select Edit > Paste. The Informatica prompts you to confirm the copy. To create a new mapping, select Mappings > Create.
Transformation
Target
Mapplet Designer
Used to create and modify mapplets
Source qualifier Source
Output transformation
Modify mapplets in the workspace.
Mapplet Designer Use the Mapplet Designer to create, copy, and modify, if necessary, mapplets. You can reuse existing mapplets in the prebuilt ETL mappings to add their processing in your custom mappings.
Linking Components
Drag the ports to create links between components.
Links
Linking Components Create links between source definitions, mapplets, transformations, and target definitions by dragging ports between the desired components. A blue line indicates a link. To delete a link, click the blue line and select Edit > Delete, or press Delete.
Validating Mappings
Select Mappings > Validate to validate a mapping.
Validation message appears in the Output window.
Validating Mappings Mappings must be configured correctly and then validated so that the Informatica server can read and execute the entire mapping without any errors. Mappings are marked invalid (with a red X) when errors are detected that prevents the Informatica server from executing the mapping successfully. To determine whether a mapping is valid, the Informatica Designer checks the following: The required ports are connected. All port connections are valid. All expressions parse successfully and are valid. The independent object definition matches the instance of the object definition in the mapping. Mappings are validated automatically when you save the repository. You can also validate mappings manually by selecting Mappings > Validate. Validation results appear in the Output window. If a mapping is invalid, review the validation message in the Output window to determine the reason. Follow the same procedures to validate mapplets.
Copying Existing Objects

Existing objects can be used as a starting point to build new objects in custom folders.
Mapping copied from the SDE_ORA11510_Adaptor folder to the CUSTOM_SDE folder.
Copying Existing Objects You can use existing objects from the shipped SDE and SILOS folders as a starting point to create new objects in custom folders. To copy an object, first open the custom folder. Copy the existing object and paste into the custom folder. Alternatively, drag the desired object from the existing folder into the custom folder. Informatica prompts you to confirm the copy. When you copy an object, all objects contained within that object are also copied. For example, when you copy a mapping, all sources, targets, mapplets, and transformations associated with the mapping are copied as well. Informatica provides a dialog box that enables you to determine which versions of objects to copy and which to discard.
Saving the Repository

Select Repository > Save to save changes to the Informatica repository.
Saving the Repository Be sure to save your work as you build and modify repository objects.
Summary
In this lesson, you should have learned how to: Identify the Informatica repository objects used to configure the Oracle Business Analytics Warehouse Navigate the set of tools in the Informatica Designer used to configure Informatica repository objects.
Practice 6-1: Working with Informatica Designer

This practice covers the following topics: Navigating Informatica Designer and its set of tools Building an SDE mapping
Practice 6-1: Working with the Informatica Designer The primary goal of this practice is to become familiar with the Informatica Designer and its tools. To accomplish this, you create a Source Dependent Extract (SDE) mapping that extracts data from a source table and moves the data into a fact staging table. Thus the secondary goal of this practice is to become familiar with some ETL mapping components and the steps to create them. In this set of practices, you use custom tables provided specifically for this training. These tables have very small data sets, so you can focus less on the data being moved by ETL and more on Informatica Designer tools and the steps for building mappings. In the practices for the lesson titled Working with Informatica Workflow Manager, you use the Informatica Workflow Manager to run the mapping and verify the results. Later in this course, in the lessons titled Adding a New Dimension in OBAW and Integrating Security for Oracle Business Intelligence Applications, you build custom SDE and SIL mappings and use the DAC to run the mappings and verify the results.
Working with Informatica Workflow Manager

Objectives
After completing this lesson, you should be able to: Navigate Informatica Workflow Manager Run workflows and sessions using the Informatica Workflow Manager Monitor workflows using the Informatica Workflow Monitor
Objectives In the lesson titled Working with Informatica Designer, you learned the steps to build mappings using the Informatica Designer tools. In this lesson, you learn how to use the Informatica Workflow Manager to add those mappings to sessions, and then run and monitor the sessions to load data.
Informatica Workflow Manager

Is an Informatica client tool used to build workflows to execute mappings
Navigator: View, select, and run workflows.
Output: View messages from the Informatica Integration Service.
Informatica Workflow Manager This slide explains the purpose of the Informatica Workflow Manager. In the Workflow Manager, you define a set of instructions to execute tasks, such as sessions. This set of instructions is called a workflow. When you create a workflow in the Workflow Designer, you add tasks to the workflow. The Session task is based on a mapping you build in the Designer. You then connect tasks with links to specify the order of execution for the tasks you created. When the workflow starts, the Integration Service retrieves the metadata from the repository to execute the tasks in the workflow. You can monitor the workflow status in the Workflow Monitor. You used Workflow Manager to register Informatica servers in the lesson titled Installing Oracle BI Applications. This lesson focuses on the steps needed to create, run, and monitor sessions and workflows.
Designer: Create and run workflows.
Workflow
Is a set of instructions that tells the Informatica Integration Service how to execute tasks Contains a session and any other tasks needed to execute a session
Workflow A workflow is a set of instructions that tells the Integration Service how to run tasks such as sessions. A workflow is made up of tasks. The most common types of tasks used in the Oracle Business Analytics Warehouse (OBAW) are Start and Session tasks. The Start task represents the beginning of the workflow. The Session task is used to execute the mapping. The workflows are called by the Data Warehouse Administration Console (DAC) server during extract, transform, and load (ETL) based on how their respective DAC tasks are prioritized for execution.
Session
Is a set of instructions that tells the Informatica Integration Service how and when to move data from sources to targets Is configured in the Workflow Manager by creating a session task Is executed as a task within a workflow
Session A session is the mechanism by which mappings move data from sources to targets. Mappings are added to sessions. When the Informatica server runs a session, it uses the instructions configured in the mapping to read, transform, and write data.
Creating and Running Workflows

1. Connect to the repository. 2. Open Workflow Designer. 3. Create a workflow. 4. Add a session to the workflow. 5. Link workflow tasks. 6. Edit session properties. 7. Validate the workflow. 8. Start the workflow. 9. Monitor the workflow. 10. Check log files.
Creating and Running Workflows These are the high-level steps for creating and running workflows. Each step is presented in detail in the slides that follow.
1. Connect to the Repository

Open Workflow Manager and connect to the repository.
Double-click the repository.
Enter username and password and click Connect.
1. Connect to the Repository To open Workflow Manager: If Informatica Designer is open, select Tools > Workflow Manager; otherwise select Start > Programs > Informatica PowerCenter 8.1.1 > Client > PowerCenter Workflow Manager. After the Workflow Manager is open, connect to the repository as you would in other Informatica tools: double-click the repository, enter the username and password, and click Connect.
2. Open Workflow Designer

Open the appropriate custom folder and Select Tools > Workflow Designer to open the Workflow Designer workspace.
Open folder.
2. Open Workflow Designer Open the appropriate custom folder and select Tools > Workflow Designer to open the Workflow Designer workspace.
Select Workflow Designer.
3. Create a Workflow
Select Workflows > Create to create a new workflow.
Name the workflow and click OK.
4. Add a Session to the Workflow

Select Tasks > Create to add a session to a workflow.
Select Session type. Name the task.
Select a mapping to associate with the session.
4. Add a Session to the Workflow To add a session to a workflow, perform the following steps: 1. Select Tasks > Create. 2. Select the Session type from the list. 3. Name the session. 4. Associate a mapping with the session.
5. Link Workflow Tasks

Select Tasks > Link Task to link workflow tasks.
Click the Start icon and then the session task to create the link.
5. Link Workflow Tasks To link tasks, select Tasks > Link Task, and then click the Start task and then the session task.
6. Edit Session Properties

Double-click the session in the Workflow Designer workspace to open the Edit Tasks dialog window.
6. Edit Session Properties Session properties include source and target database connections, transformation source, bulk load options, session file names, and the option to truncate the target table.
Use the Edit Tasks dialog box to edit session properties.
7. Validate the Workflow

Select Workflows > Validate to validate the workflow.
8. Start the Workflow

Right-click the workflow and select Start Workflow.
Select Start Workflow.
8. Start the Workflow After session properties are set and the workflow is validated, you can start the workflow or session from the appropriate folder in the Repository Navigator. Start workflows by rightclicking the workflow and then selecting Start Workflow. Alternatively, you can right-click a task in the Workflow Designer workspace and select Start Workflow From Task.
Right-click workflow in Navigator.
9. Monitor the Workflow

Use the Workflow Monitor to monitor workflows.
Workflow
Start time
Completion time
Status
9. Monitor the Workflow When you start a workflow, the Informatica Workflow Monitor opens and provides information about the workflow run, including the start time, completion time, and status.
10. Check Log File

For the workflow log, right-click workflow in the Workflow Monitor and select Get Workflow Log. For the task log, right-click task in the Workflow Monitor and select Get Task Log.
10. Check Log File Use log files to verify the success of a session or to troubleshoot sessions that fail. If the workflow returns a status of Failed, right-click the workflow object in the Workflow Monitor, select Get Workflow Log and try to troubleshoot. If the session task returns a status of Failed, right-click the session task object in Workflow Monitor, select Get Task Log and try to troubleshoot. Troubleshooting may require changes to the workflow in the Workflow Manager or changes to the mapping in the Designer. Log files include information about: Allocation of system shared memory Execution of presession commands Session initialization Creation of SQL commands for reader and writer threads Start and end times for target loading Errors encountered during session Execution of postsession commands Load summary of reader, writer, and Data Transformation Manager (DTM) statistics
Summary
In this lesson, you should have learned how to: Navigate in the Informatica Workflow Manager Run workflows and sessions using the Informatica Workflow Manager Monitor workflows using the Informatica Workflow Monitor
Practice 7-1: Creating and Running an Informatica Workflow

This practice explains how to use the Informatica Workflow Manager to create and run a workflow for an SDE mapping.
Practice 7-1: Creating and Running an Informatica Workflow In the practice for the lesson titled Working with Informatica Designer, you created a Source Dependent Extract (SDE) mapping that extracts data from a source table and moves the data into a fact staging table. Now you use the Informatica Workflow Manager to create a workflow to run the mapping. Please note that the DAC is used to run ETL mappings in production environments; whereas Informatica client tools are used for testing. Again, as in the practice for the lesson titled Working with Informatica Designer, you use custom tables provided specifically for this training.
Exploring SDE and SIL Mappings

Objectives
After completing this lesson, you should be able to: Describe the differences between Source Dependent Extract (SDE) and Source Independent Load (SIL) mappings Identify typical objects and their mechanics in SDE and SIL mappings
Anatomy of a Typical SDE Mapping

SDE mappings select from source transactional tables and load warehouse staging tables.
Business component mapplet Expression transformation Source adapter mapplet Target definition
Anatomy of a Typical SDE Mapping A typical SDE mapping generally consists of source tables or a business component, an expression transformation, and a staging table. Most SDE adapter folders use the concept of business component mapplets. These are extract mapplets that may contain relational, application, or flat file sources. The Siebel adaptor folders do not use business component mapplets; the sources are exposed directly in the mapping. The source objects of SDE mappings are transactional tables, whose data is retrieved, processed by mapping transformations, and loaded into an OBAW staging table, which is the typical target object of an SDE mapping. This slide provides an overview of the function and major components of a typical SDE mapping in an Oracle adaptor folder (for example, SDE_ORA11510_Adaptor). This mapping, SDE_ORA_GLRevenueFact, extracts revenue data from tables in an Oracle E-Business Suite source system and loads the data into the W_GL_REVN_FS fact staging table in the Oracle Business Analytics Warehouse. Note that there are four components in the mapping and the data flow is from left to right. Each of these components is discussed in detail in the slides that follow. Please note that individual mappings may differ substantially from the examples provided on this and the following slides, which examine a typical mapping, SDE_ORA_GLRevenueFact. The main goal is to illustrate the typical objects and data flow in an SDE mapping.
Business Component Mapplet

Extracts data from tables in the source system
Source definitions
Source qualifier
Business Component Mapplet This mapplet, mplt_BC_ORA_GLRevenueFact, extracts revenue data from tables in the Oracle E-Business Suite source system. Notice that there are three component types in the mapplet and the data flow is from left to right. The three component types are source definition, source qualifier, and mapplet output transformation. Recall that source definitions represent tables or files that provide source data. Source definitions are imported into the Informatica repository via the Source Analyzer. The screenshot shows only a partial view of the source definitions for this mapplet. When you add a relational or a flat file source definition to a mapplet or mapping, you need to connect it to a source qualifier transformation. The source qualifier transformation represents the rows that the Informatica Integration Service reads when it runs a session. In this example, all four source definitions connect to a single source qualifier. The source qualifier is discussed in more detail in the next slide. In this example, the MAPO_GL_REVENUE_EXTRACT mapplet output transformation is the target of this mapplet and receives data from the SQ_GL_REVENUE_EXTRACT source qualifier. The MAPO_GL_REVENUE_EXTRACT mapplet output transformation passes output from the mapplet to the next transformation in the mapping (Exp_W_GL_REVN_FS_Integration_Id expression in the example for this lesson).
Source Qualifier Transformation

Represents the rows that the Informatica Integration Service reads when it runs a session Contains the SQL statement used to retrieve data
Source Qualifier Transformation When you add a relational or a flat file source definition to a mapplet or mapping, you need to connect it to a source qualifier transformation. The source qualifier transformation represents the row set retrieved from source objects before undergoing subsequent transformations. It is often used to perform necessary data manipulation, which can include joining source objects, filtering rows, specifying custom joins such as an outer join and an inner join, and data cleansing. The SQL Query transformation attribute contains the SQL statement that is used to retrieve the data. To view or modify the SQL statement, double-click the source qualifier transformation to open the Edit Transformations dialog box, click the Properties tab, and then click the SQL Query values down-arrow icon. The source qualifier SQL also contains the $$LAST_EXTRACT_DATE parameter (not shown here). Recall that this parameter is used to identify records that have changed since the last ETL run and that the value for this parameter is passed from the DAC during run time.
Expression Transformation
Is used to calculate values in a single row before writing to the target
Expression Transformation An expression transformation is used to calculate values in a single row before writing to the target. Expression transformations perform necessary processing on data retrieved by the source qualifier. Notice that port types in an expression transformation vary by port. Though most of the ports are input/output ports that receive data and pass it unchanged, there are also input ports, variable ports, which are used to store values across rows, and output ports with expressions. For example, notice the value in the Expression field for DATASOURCE_NUM_ID port. Recall that DATASOURCE_NUM_ID is the unique identifier of the source system from which data is extracted. DATASOURCE_NUM_ID forms part of the unique key in the data warehouse and is referenced in all SDE mappings. Here DATASOURCE_NUM_ID is an output port that gets its value from the $$DATASOURCE_NUM_ID parameter, whose value is passed by the DAC during run time. Recall that variables and parameters can be declared for mappings and mapplets using the Declare Parameters and Variables dialog box. Notice that other ports are also transformed by expressions, such as TENANT_ID, which is calculated using an IIF conditional expression. You build expressions using the Expression Editor, which is accessed by clicking the down arrow in the Expression field for a port.
Source Adapter Mapplet

Converts source-specific data elements into standard formats and then stores them in a staging table.
Lookup transformations
Input transformation
Expression transformation
Source Adapter Mapplet The Source Adapter mapplet converts source-specific data elements into standard formats and then stores them in a staging table. The Source Independent Load (SIL) mapping then uses an Analytic Data Interface (ADI) mapplet to pick up these records, which are already transformed into a standard format. Note that there are five components in the mapplet and the data flow is from left to right. The components are: two unconnected lookup procedures, a mapplet input transformation, an expression transformation, and a mapplet output transformation. LKP_LOC_CURRENCY and LKP_CUSTLOC_CUST_LOC_ID are unconnected lookup transformations. An unconnected lookup transformation is a stand-alone transformation that is not linked to other transformations in a mapping or mapplet. A lookup transformation is called in an expression using the :LKP reference qualifier. The input transformation in this mapplet receives the output of the expression transformation in the SDE_ORA_GLRevenueFact mapping and passes the data to the expression transformation in this mapplet. The expression transformation performs any necessary processing on the data and then passes it to the output transformation. Notice that all ports in the output transformation have the EXT_ prefix. These ports exactly match the input ports of an Analytic Data Interface (ADI) mapplet in the corresponding SIL mapping. You explore this mapplet in more detail in the practice for this lesson.
Target Definition
Represents the target table object
Required columns are loaded into the staging table.
Target Definition The target definition represents the target table object in the mapping. For an SDE mapping, this is a staging table in the OBAW. In this example, the target definition is the fact staging table W_GL_REVN_FS. The EXT_*output ports of the mplt_SA_ORA_GLRevenueFact mapplet are used to populate the ports in the W_GL_REVN_FS target definition. This table is one of the source definitions in the corresponding SIL mapping, SIL_GLRevenueFact. Recall that target definitions are defined using the Target Analyzer in Informatica Designer. The required staging table columns, DATASOURCE_NUM_ID and INTEGRATION_ID, are loaded into the staging table. INTEGRATION_ID stores the primary key or the unique identifier of a record in the source table and DATASOURCE_NUM_ID stores the data source from which the data is extracted. These required columns are used by the SIL mapping to generate the surrogate key for the OBAW.
Anatomy of a Typical SIL Mapping

SIL mappings select data from OBAW tables, perform transformations, and load data into OBAW tables.
Source qualifier Mapplet
Source definitions Mapplet Lookup Expression Target Mapplet Update strategy
Anatomy of a Typical SIL Mapping SIL mappings select data from OBAW staging and dimension tables, perform transformations, and load data into OBAW tables. SIL mappings differ from SDE mappings with regard to source and target tables. SIL mappings are source independent in that they do not select data from a transactional source, but rather from the warehouse staging and dimension tables. The targets of SDE mappings are OBAW staging tables; whereas the targets of SIL mappings are the final OBAW tables. Also, SIL mappings are typically more complex than SDE mappings, because the data undergoes more transformation before being passed to the target. This slide provides an overview of major components of a typical SIL mapping. An SIL mapping has many of the same transformation objects as an SDE mapping: source definition, source qualifier, mapplet, lookup procedure, expression, and target definition. In addition, an SIL mapping contains the following transformation objects: filter and update strategy. In the remainder of this lesson, you explore the general flow of an SIL mapping and the objects that are unique to an SIL mapping. Please note that individual mappings may differ substantially from the examples provided on this and the following slides, which examine the SIL_GLRevenueFact mapping. The main goal is to illustrate the typical objects and data flow in an SIL mapping.
Expression
Filter
Mapplet
SIL Source Definitions

SIL source definitions include dimension tables loaded by dimension SIL mappings and staging tables loaded by SDE mappings.
Dimension table
Dimension table
Staging table
Dimension table
SIL Source Definitions Source definitions for SIL mappings are all located in the OBAW. They include dimension tables, which are populated by dimension SIL mappings, and staging tables, which are populated by SDE mappings. In this example, one of the source definitions is the W_GL_REVN_FS fact staging table, which is populated by the SDE_ORA_GLRevenueFact mapping discussed earlier in this lesson. The screenshot shows only a partial view of the source definitions for this mapping.
SIL Source Qualifier

Performs the same basic function as the source qualifier in the SDE mapping
SIL Source Qualifier This source qualifier transformation performs the same basic function as the source qualifier in the SDE mapping. The source qualifier transformation represents the row set retrieved from the source objects before undergoing subsequent transformations. The Sql Query transformation attribute, accessed on the Properties tab, contains the SQL statement that is used to retrieve the data from the sources.
MPLT_GET_ETL_PROC_WID Mapplet
This is a reusable mapplet that looks up and retrieves ETL_PROC_WID from the W_PARAM_G table in the OBAW.
MPLT_GET_ETL_PROC_WID Mapplet This is a reusable mapplet that looks up and retrieves the ETL_PROC_WID from the W_PARAM_G table in the OBAW. ETL_PROC_WID stores the ID of the ETL process information, which uniquely identifies each ETL run. This ID is also displayed as the Process ID on the Current Run / Run History screen in the DAC. The value for ETL_PROC_WID is passed by the DAC during run time to the $$ETL_PROC_WID parameter in the MPLT_GET_ETL_PROC_WID mapplet.
Lkp_W_GL_REVN_F Lookup Procedure

This cached lookup transformation is responsible for looking up the required DATASOURCE_NUM_ID and INTEGRATION_ID columns in the target table.
Lkp_W_GL_REVN_F Lookup Procedure This is a connected lookup transformation. It is physically linked to other transformations in the mapping flow to receive inputs and provide outputs. This is in contrast to an unconnected lookup transformation, which is a stand-alone transformation that is not linked to other transformations in a mapping or mapplet. You saw an example of an unconnected lookup transformation in the source adapter mapplet discussed earlier in this lesson. This cached lookup transformation is responsible for looking up the required DATASOURCE_NUM_ID and INTEGRATION_ID columns in the target table, W_GL_REVN_F in this example. Together, these two columns are the primary key that uniquely identifies rows in the target table. These columns are compared against the corresponding staging area columns to detect new records or identify changed records. Rows that have the same INTEGRATION_ID and DATASOURCE_NUM_ID will be updated in the target table. The rest of the rows will be inserted. The SQL statement of this lookup transformation is overridden with a join with the staging area table, W_GL_REVN_FS, to minimize the number of records to be cached by this lookup.
Exp_W_GL_REVN_F_Update_Flg Expression
Evaluates the value of the Update Flag port, UPDATE_FLG, which is used to take actions such as insert and delete in the update strategy transformation, which is located downstream in this mapping
Update flag logic
Exp_W_GL_REVN_F_Update_Flg Expression This expression transformation evaluates the value of the Update Flag port, UPDATE_FLG, which is used to take actions such as insert and delete in the update strategy transformation, which is located downstream in this mapping. The possible values for the UPDATE_FLG port are: I (insert new record), B (insert new record and mark for soft delete), U (update existing record), D (update existing record and mark for soft delete), and X (reject). The update flag is evaluated using the following logic: Basic Checks: If the current ETL Process Identifier is the same as the target records ETL Process Identifier, it is already loaded and, therefore, no processing is required (result X for Reject) - STOP. If the stage reject flag = Y, then no processing (result X for Reject) - STOP. Checks for new records (where targets ETL Process Identifier is NULL): If the stage delete flag = Y, then insert the record and mark it for a soft-delete (result B for insert with a soft-delete) - STOP. If the stage delete flag <> Y, insert into target (result I for Insert) - STOP. Checks for existing records (where targets ETL Process Identifier is NOT NULL): If INSERT_ONLY_FLG = Y, then no processing (result X for Reject) - STOP.
Exp_W_GL_REVN_F_Update_Flg Expression (continued) If the stage delete flag = Y and the target delete flag = Y, then no processing (result X for Reject) - STOP. If the stage delete flag = Y and the target delete flag <> Y, then update target and mark for a soft-delete (result D for Updates with soft-delete) - STOP. If the stage delete flag <> Y, update the target if there is a difference in the comparison columns (result U for Update) - STOP. If there is no difference in the comparison columns, then no processing (result X for Reject) - STOP.
Fil_W_GL_REVN_F Filter
Uses an IIF formula to filter out records that have an UPDATE_FLG value of 'X' and are, therefore, rejected
Fil_W_GL_REVN_F Filter A filter transformation filters out rows based on one or more conditions. The filter transformation allows only those rows that meet the filter condition. The rows that do not meet the filter criteria are not processed. In this example, the filter transformation uses an IIF formula to filter out records that have an UPDATE_FLG value of X and are, therefore, rejected.
mplt_Curcy_Conversion_Rates Mapplet
This mapplet is responsible for getting the correct exchange rates for a given date, where a currency conversion to any of the three possible global currencies is involved.
mplt_Curcy_Conversion_Rates Mapplet This mapplet is responsible for getting the correct exchange rates for a given date, where a currency conversion to any of the three possible global currencies is involved. Currency conversions are required because your business might have transactions involving multiple currencies. The OBAW stores amounts in the document currency (the currency of the transaction), local currency (the currency in which accounting entries are recorded), and global currencies. Out of the box, Oracle Business Intelligence Applications provides three global currencies, which are the common currencies used by the OBAW. For every monetary amount extracted from the source, the load mapping loads the document currency and local currency amounts into the target table. It also loads the exchange rates required to convert the document amount into each of the three global currencies. Thus, in the target table, there are two amount columns and three exchange rate columns. You will learn more about configuring global currencies in the lesson titled Configuring Analytical Applications.
EXP_Custom Expression
This expression transformation is used when you need to customize the mapping by adding columns to an existing fact or dimension table.
EXP_Custom Expression This expression transformation is used when you need to customize the mapping by adding columns to an existing fact or dimension table. To see additional columns in the data warehouse, the columns must first be passed through the ETL process. Both the prebuilt ETL mappings and OBAW tables are extensible. Oracle BI Applications provides a methodology to extend the prebuilt ETL mappings to include additional columns and load the data into existing OBAW tables. This EXP_Custom expression transformation is part of that methodology. It has a single placeholder column, X_CUSTOM, which marks a safe path through the mapping. All extension logic should follow the same route through the mapping as X_CUSTOM. You can add additional transformations to the mapping, but they should follow the same route through the mapping as X_CUSTOM. This process of customizing and extending the ETL mappings and the OBAW is covered in depth in the lessons titled Customizing Oracle Business Analytics Warehouse, Adding Columns to an Existing Dimension Table, and Adding a New Dimension in OBAW.
MPLT_LKP_W_CUSTOMER_FIN_PROFL_D Mapplet
This mapplet does a lookup to resolve the CUSTOMER_FIN_PROFL_WID column, which is the key to the customer accounts dimension in W_GL_REVN_F.
MPLT_LKP_W_CUSTOMER_FIN_PROFL_D Mapplet This mapplet does a lookup to resolve the CUSTOMER_FIN_PROFL_WID column, which is the key to the customer accounts dimension in W_GL_REVN_F. First, CUSTOMER_PROFL_ID1 is used to resolve the CUSTOMER_FIN_PROFL_WID column. If it fails, CUSTOMER_PROFL_ID2 is used for the lookup. If both fail, NULL is returned.
mplt_SIL_GLRevenueFact Mapplet
This mapplet is responsible for transforming specific types of columns in the target table W_GL_REVN_F.
mplt_SIL_GLRevenueFact Mapplet This mapplet is responsible for transforming specific types of columns in the target table W_GL_REVN_F. Jobs done in this mapplet include code-name pair resolution, dimension surrogate key resolution, currency conversion (if required), date to date_wid conversion, stamping of system columns such as W_INSERT_DT, W_UPDATE_DT, and so on. Please note that the mapplet is too complex to display in a slide. You explore the mapplet in the practice for this lesson.
Upd_W_GL_REVN_F_Ins_Upd Update Strategy

This transformation is used to decide whether incoming rows should be inserted or updated in the target table based on the value of the UPDATE_FLG port.
Upd_W_GL_REVN_F_Ins_Upd Update Strategy This transformation is used to decide whether incoming rows should be inserted or updated in g table based on the value of the UPDATE_FLG p port. Recall that the value of this port p the target was set for each row in the Exp_W_GL_REVN_F_Update_Flg expression transformation. The logic is as follows: If UPDATE_FLG for a row is set to I (insert new record) or B (insert new record and mark for soft delete), the record is flagged for insertion. If UPDATE_FLG for a row is set to D (update existing record and mark for soft delete) or U (update existing record), the record is flagged for update. All other records are flagged for rejection.
W_GL_REVN_F Target Definition

This target definition represents the fact table that stores all the revenue transactions for the Oracle BI Financial Analytics application in the OBAW.
W_GL_REVN_F Target Definition This fact table stores all the revenue transactions for the Oracle BI Financial Analytics application in the OBAW. All the transaction amounts are stored in the document and local currency, and the table also maintains three global currency exchange rates. The ACCT_DOC_TYPE_WID port in this table is the foreign key to the W_XACT_TYPE_D table. It distinguishes the transaction type of the record. The DOC_STATUS_WID port is the foreign key to the W_STATUS_D table. It is used to determine the status of the record, whether it is open, cleared, posted, or unposted.
Unspecified Mappings
Each SIL dimension mapping has a corresponding unspecified mapping that loads the dimension with one Unspecified row, which allows facts to have a join to the dimension even when the foreign key is not populated (or invalid) in the source table.
Workflow Mapping
Unspecified row in W_ORG_D
Unspecified Mappings Each SIL dimension mapping has a corresponding unspecified mapping, which allows facts to have a join to the dimension even when the foreign key is not populated (or invalid) in the source table. All fact rows from source transactional tables that do not have a matching row in the respective dimension tables default to the unspecified value. Informatica workflows designed for full loads include two sessions: one that calls the SIL_<Dimension> mapping and one that calls the SIL _<Dimension>_Unspecified mapping. Recall that fact tables contain metrics and dimension tables contain attributes. Therefore, nulls and unknown values are acceptable in dimensions but must be set with a standard unspecified value in the fact table. During load, each dimension is loaded with one unspecified row, to which the unspecified session then relates the data in the fact table. In the fact mappings, an expression transformation evaluates each value. Null or unknown foreign key values are set to the unspecified value of 0 on all ROW_WID columns. Default unspecified values are obtained from W_LST_OF_VAL_G.
Summary
In this lesson, you should have learned how to: Describe the differences between Source Dependent Extract (SDE) and Source Independent Load (SIL) mappings Identify typical objects and their mechanics in SDE and SIL mappings
Practice 8-1 Overview: Exploring a Prebuilt SDE Mapping

This practice covers exploring a prebuilt Source Dependent Extract (SDE) mapping in the Oracle Informatica repository.
Practice 8-1 Overview: Exploring a Prebuilt SDE Mapping The main goal of this practice is to explore the anatomy of a typical, prebuilt SDE mapping in the Informatica repository. Extract mappings consist of a source table or business component, an expression transformation, and a staging table. Business components are packaged as mapplets, which reside in source-specific folders within the repository. Business components are used to extract data from the source system. An understanding of the anatomy of prebuilt mappings will assist you in the configuration and customization of ETL mappings. This practice explores the function and components of a typical SDE mapping. Note that individual mappings may differ substantially from the examples provided here.
Practice 8-2 Overview: Exploring a Prebuilt SIL Mapping

This practice covers exploring a prebuilt Source Independent Load (SIL) mapping in the Oracle Informatica repository.
Practice 8-2 Overview: Exploring a Prebuilt SIL Mapping The main goal of this practice is to explore the anatomy of a typical, prebuilt SIL mapping in the Informatica repository. SIL mappings select data from Oracle Business Analytics Warehouse (OBAW) staging tables, perform transformations, and load data into OBAW tables. SIL mappings differ from SDE mappings regarding source and target tables. SIL mappings are source independent in that they do not select data from the transactional source, but rather from the warehouse staging tables. The targets of SDE mappings are OBAW staging tables; whereas the targets of SIL mappings are the final OBAW tables. Also, SIL mappings are typically more complex than SDE mappings, because the data undergoes more transformation before being passed to the target. An understanding of the anatomy of prebuilt SIL mappings will assist you in the configuration and customization of ETL mappings. This practice explores the function and components of a typical SIL mapping. Note that individual mappings may differ substantially from the examples provided here.
Working with the Data Warehouse Administration Console

Objectives
After completing this lesson, you should be able to: Use the tools and views of the Data Warehouse Administration Console (DAC) Describe DAC objects, how they relate to each other, and their roles in the Oracle Business Analytics Warehouse (OBAW) extract, transform, and load (ETL) process
Data Warehouse Administration Console

Centralized console for schema management as well as configuration, administration, loading, and monitoring of the Oracle Business Analytics Warehouse Comprises three components:
DAC client
Is a command and control interface for the data warehouse Executes the instructions from the DAC client and manages OBAW processes Stores the metadata that represents the data warehouse processes
DAC server
DAC repository
Data Warehouse Administration Console The Data Warehouse Administration Console (DAC) is a centralized console for schema management as well as configuration, administration, loading, and monitoring of the Oracle Business Analytics Warehouse. It comprises three components: DAC client: Allows for schema management and configuration, administration, and monitoring of data warehouse processes. A command and control interface for the data warehouse that enables you to design subject areas and build execution plans. DAC server: Executes the instructions from the DAC client. The DAC server manages data warehouse processes, including loading of the ETL and scheduling execution plans. It dynamically adjusts its actions based on information in the DAC repository. Depending on your business needs, you may incrementally refresh the Oracle Business Analytics Warehouse once a day, once a week, once a month, or on another similar schedule. DAC repository: Stores the metadata (semantics of the Oracle Business Analytics Warehouse) that represents the data warehouse processes
DAC Application-Specific Capabilities

DAC provides application capabilities at a layer of abstraction above the ETL execution platform: Dynamic generation of subject areas and execution plans Dynamic settings for parallelism and load balancing Intelligent task queue engine based on user-defined and computed scores Automatic awareness of full or incremental mode Index management for ETL and query performance Embedded high performance Siebel OLTP change capture techniques Ability to restart at any point of failure Phase-based analysis tools for isolating ETL bottlenecks
Application-Specific Capabilities The DAC provides a framework for the entire life cycle of data warehouse implementations. It enables you to create, configure, execute, and monitor modular data warehouse applications in a parallel, high-performing environment. The DAC complements the Informatica ETL platform. It provides application-specific capabilities that are not prebuilt into ETL platforms. For example, ETL platforms are not aware of the semantics of the subject areas being populated in the data warehouse nor the method in which they are populated. The DAC provides the application capabilities listed in this slide at a layer of abstraction above the ETL execution platform.
DAC Features
DAC features enable you to do the following: Minimize installation, setup, and configuration time Manage metadata-driven dependencies and relationships Provide reporting and monitoring to isolate bottlenecks Utilize performance execution techniques
DAC Features Minimize installation, setup, and configuration time. - Create a physical data model in the data warehouse. - Set language, currency, and other settings. - Design subject areas and build execution plans. Manage metadata driven dependencies and relationships. - Generate custom ETL execution plans. - Automate change capture for the Siebel transactional database. - Capture deleted records. - Assist in index management. - Perform dry runs and test runs of execution plans. Provide reporting and monitoring to isolate bottlenecks. - Perform error monitoring and email alerting. - Perform structured ETL analysis and reporting. Use performance execution techniques. - Automate full and incremental mode optimization rules. - Set the level of Informatica session concurrency. - Load balance across multiple Informatica servers. - Restart from point of failure. - Queue execution tasks for performance.
Source System Containers

Source system containers hold repository objects that correspond to a specific source system.
For example: Oracle 11.5.10; Siebel 8.0; Peoplesoft 9.0
Make a copy to make changes.
Source System Containers Source system containers hold repository objects that correspond to a specific source system. The DACs import feature enables you to import source systemspecific DAC metadata into the DAC repository. For example, you can import DAC metadata for an Oracle 11.5.10 source or a Siebel 8.0 source, or for both sources. You can use the preconfigured source system containers to create your own source system container. You cannot modify objects in the preconfigured source system containers. You must make a copy of a preconfigured container to make any changes to it. The source system container appears in the Owner field of DAC objects.
The DACs import feature enables you to import source systemspecific DAC metadata into the DAC repository. Preconfigured source system containers cannot be modified.
DAC Repository Objects

All DAC repository objects are associated with a source system container.
Subject area
Logical grouping of tables related to a particular subject or application context
Table
Task
A unit of work for loading one or more tables A data transformation plan defined on subject areas that need to be transformed at certain frequencies of time Specifies when and how often an execution plan runs
Execution plan
Schedule
DAC Repository Objects All DAC repository objects are associated with a source system container. The DAC repository stores application objects in a hierarchical framework that defines a data warehouse application. The DAC enables you to view the repository application objects based on the source system container you specify. The source system container holds the metadata that corresponds to the source system with which you are working. The slide shows a list of some of the key repository objects in a data warehouse application: Subject area: A logical grouping of tables related to a particular subject or application context. It also includes the tasks that are associated with the tables, as well as the tasks required to load the tables. Subject areas are assigned to execution plans, which can be scheduled for full or incremental loads. Tables: Physical database tables defined in the database schema. They can be transactional database tables or data warehouse tables. Table types can be fact, dimension, hierarchy, aggregate, and so on, as well as flat files that can be sources or targets. Task: A unit of work for loading one or more tables. A task comprises the following: source and target tables, phase, execution type, truncate properties, and commands for full or incremental loads. When you assemble a subject area, the DAC assigns tasks to it. Tasks that are assigned to the subject area by the DAC are indicated by the Autogenerated flag in the Tasks subtab of the Subject Areas tab.
Physical database table defined in the database schema
DAC Repository Objects (continued) Execution plan: A data transformation plan defined on subject areas that need to be transformed at certain frequencies of time. An execution plan is defined based on business requirements for when the data warehouse needs to be loaded. An execution plan comprises the following: ordered tasks, indexes, tags, parameters, source system folders, and phases. Schedule: A schedule specifies when and how often an execution plan runs. An execution plan can be scheduled for different frequencies or recurrences by defining multiple schedules.
DAC Repository Object Hierarchy
Source System Container Execution plans Schedules
Tables
Tasks
DAC Repository Object Hierarchy This slide provides a visual overview of the hierarchy of DAC repository objects.
Subject areas
DAC Repository Object Hierarchy with Examples

Oracle 11.5.10
Source System Container

Complete Oracle 11.5.10
Execution plans
Monthly
Schedules
W_GL_REVN_F
Tables
Tasks
SDE_ORA_GLRevenueFact
DAC Repository Object Hierarchy with Examples This slide provides a visual overview of the hierarchy of DAC repository objects with specific examples for each object. Note that in the DAC, each object depicted contains multiple objects. That is, each source system container contains multiple execution plans; each execution plan contains multiple subject areas, and so on.
Financials - Revenue
Subject areas
DAC Client User Interface

Menu bar View buttons Top pane tabs DAC Server Monitor icon: Orange: Running Red: Not running Green: Executing ETL
Top pane toolbar Editable list Navigation tree
Bottom pane child tabs
Editable form
DAC Client User Interface The screenshot shows the main DAC window with the Execute view selected. The DAC client user interface provides the ability to configure, administer, load, and monitor the Oracle Business Analytics Warehouse from one central location using typical Windows functionality. For example, the File menu contains options to close the DAC client and to create, copy, or delete source system containers. The Views menu allows you to navigate to the various tabs in the top pane window. The Tools menu provides access to functionality related to the DAC and Informatica repositories. The toolbars provide commands for creating, saving, deleting, and querying records. Commands are also available in right-click menus depending on the tab that is active. Top pane tabs provide access to definitions of each of the DAC objects. The bottom pane allows editing of selected objects in the top pane. This slide provides a high-level overview of the user interface. Each of the views and their major tabs and functionality are covered later in this lesson.
DAC Client Tools Menu

The Tools menu provides access to functionality related to the DAC and Informatica repositories:
Export DAC metadata. Import DAC metadata. Generate a DAC repository report. Purge completed runs from the run history. Run analyze table commands for DAC repository tables. Specify which databases will be associated with newly created indexes. Drop DAC repository tables. Configure DAC server connections and server email settings. Create and drop data warehouse tables. Clear the refresh dates for all source and target tables.
DAC Client Tools Menu The Tools menu in the DAC client provides access to functionality related to the DAC and Informatica repositories. A partial list of the functionality is provided here. For more information, refer to the Oracle Business Intelligence Data Warehouse Administration Console Guide. Export the DAC metadata, in XML format, based on the source system container, to back up the metadata or to reproduce the environment elsewhere. Import the DAC metadata for the source system containers you specify. Generate a DAC repository report. Purge completed runs from the run history. Run analyze table commands for all the DAC repository tables. Specify which databases will be associated with newly created indexes. Drop all the DAC repository tables. Configure the DAC server connections and server email settings. Create and drop data warehouse tables. Clear the refresh dates for all source and target tables.
DAC Views
There are three DAC views, each with a different set of functionality.
Design Setup Execute
Views menu
View buttons
DAC Views There are three DAC views, each with a different set of functionality: Design Setup Execute Each view is discussed in detail in the slides that follow. You can access DAC views through the Views menu or via the DAC View buttons, which are located directly under the menu bar. You can also double-click an object in the navigation tree to default to the view and tab necessary for viewing and editing that object.
DAC views are accessed through the Views menu or the buttons located directly under the menu bar.
Design View: Subject Areas Tab

Provides access to functionality related to creating and managing subject areas and related objects specific to a selected source system container
Source system container
Navigation tree
List of subject areas for selected container
Design View: Subject Areas Tab The Design view provides access to functionality related to creating and managing subject areas and related objects specific to a selected source system container. When the Design view is active, the Source System Container drop-down list appears to the right of the view buttons. It allows you to select the source system container that holds the repository objects that correspond to a specific source system. In this example, the Oracle 11.5.10 source system container is selected. The navigation tree displays all the metadata corresponding to the selected source system container. You cannot change the metadata for preconfigured containers. This is why some buttons are grayed out: New, Reference, Save, Undo, Delete, and Assemble. If you want to customize the metadata in a preconfigured container, you must first make a copy of the container. You learn how to create a custom container and the associated metadata in the lesson titled Customizing DAC Metadata and Running an Execution Plan. Notice that the tree root nodes in the navigation tree correspond to the tabs in the top pane of the DAC window on the right: Subject Areas, Tables, Indices, and so on. In the example in the slide, the Subject Areas tab is selected and all the subject areas for the selected container are displayed in the list.
Design View: Tables Tab

Lists the physical database tables defined in the database schemas that are associated with the selected source system container
Design View: Tables Tab The Tables tab lists the physical database tables defined in the database schema that are associated with the selected source system container. It enables you to view and edit existing tables and to create new ones. Warehouse indicates whether the table is a warehouse table. If this option is not selected, the schema creation process will not include this table.
Design View: Source System Parameters Tab

Lists all the source system parameters associated with the selected source system container
Design View: Source System Parameters Tab The Source Systems Parameters tab lists all the source system parameters associated with the selected source system container. It enables you to edit existing parameters and to configure new ones for custom containers. For example, notice the $$DATASOURCE_NUM_ID parameter, which you worked with in earlier practices. It is used to populate DATASOURCE_NUM_ID in Informatica mappings during run time.
Design View: Source System Folders Tab

Lists the Informatica folders associated with the selected source system container
Design View: Source System Folders The Source System Folders tab lists the Informatica folders associated with the selected source system container. It enables you to view existing folders and to create new ones. Logical Folder is the name of the logical Informatica folder. This name is used in the task definition (in the Tasks tab) so that task definitions do not have to be cloned. Physical Folder is the name of the physical Informatica folder. The physical Informatica folder corresponds to the actual folder in the Informatica repository. This name is used in the Ordered Tasks subtab of the Execution Plans tab.
Design View: Tasks Tab

Lists all the tasks associated with the selected source system container
Incremental load command
Full load command Primary target Primary source
Source system folder Task phase
Execution type
Design View: Tasks Tab The Tasks tab lists all the tasks associated with the selected source system container. A task is a unit of work for loading one or more tables. A task comprises the following: source and target tables, phase, execution type, truncate properties, and commands for full or incremental loads. When you assemble a subject area, the DAC assigns tasks to it. Tasks that are assigned to the subject area by the DAC are indicated by the Autogenerated flag in the Tasks subtab of the Subject Areas tab. A table can be loaded in full mode or incremental mode. Full mode refers to data loaded for the first time or data that is truncated and then loaded. Incremental mode refers to new or changed data being added to the existing data. The load commands for this task are SDE_ORA_GLRevenueFact and SDE_ORA_GLRevenueFact_Full. These commands correspond to the Informatica workflows that execute the tasks for the Informatica mapping SDE_ORA_GLRevenueFact. If there is no refresh date for the source table during extract, the full command is issued to the Informatica server; otherwise, the incremental load is issued. The folder name, Extract, is the logical name of the source system folder that points to the physical folder SDE_ORA11510_Adaptor in the Informatica repository (Oracle_BI_DW_Base). The Primary Source and Primary Target properties are the logical database connections for the primary source database and primary target database, respectively.
Task
Design View: Tasks Tab (continued) Task phase information is primarily used for dependency generation. The DAC server uses the task phase to prioritize tasks and to generate a summary of the time taken for each of the phases. The Informatica execution type identifies that this task is invoked on Informatica PowerCenter Services using PMCMD.
Design View: Source Tables Subtab

Lists the tables from which the selected task extracts data
Task
Source tables
Type
Data source
Design View: Source Tables Subtab The Source Tables subtab lists the tables from which the selected task extracts data. Possible values for table type are the following: Primary: Indicates the table is a primary source of data Auxiliary: Indicates the table is a secondary source of data Lookup: Indicates the table is a lookup table The data source field lists the data source for the table. When a data source is not specified, the default is the tasks primary source.
Design View: Target Tables Subtab

Lists the tables into which the selected task loads data
Target table
Data source
Truncate options
Design View: Target Tables Subtab The Target Tables subtab lists the tables into which the selected task loads data. Truncate Always Indicates that the target tables will be truncated regardless of whether a full or incremental load is occurring. Any indexes registered for this table are dropped before the command is executed and are re-created after the command completes successfully. When indexes are dropped and created, the table is analyzed so that the index statistics are up-to-date. Truncate for Full Load Indicates that the target tables will be truncated only when a full load is occurring. Any indexes registered for this table are dropped before the command is executed and are re-created after the command completes successfully. When indexes are dropped and created, the table is analyzed so that the index statistics are up-to-date. When the Truncate Always option is selected, this option is unnecessary.
Task
Design View: Phase Dependency Subtab

Allows you to change the task execution order
Design View: Phase Dependency Subtab The DAC server uses the ETL phase property to prioritize tasks. By changing the phase property of a task, you change the tasks execution order. On this subtab, you can manage three properties: Action: The action to be taken in relation to the phase dependency. Possible values are: Wait: Indicates that the selected task will wait to be executed until the tasks of a specified phase have been executed Block: Indicates that the selected task will block all tasks of the specified phase from being executed until it has been executed Grain: Applicable only for blocks. Enables you to specify whether the action you choose affects all tasks of a specified phase or related tasks. Possible values are: All: Indicates that the action will affect all tasks Related: Indicates that the action will affect only related tasks. You can view a tasks related tasks by navigating to the Execution Plans tab > All Dependencies subtab and viewing the specified tasks predecessor tasks. Phase: The ETL phase that will apply to the Action and Grain properties
Task
Setup View
Provides access to functionality related to setting up DAC system properties, Informatica servers, database connections, and email notification
Setup View The Setup View provides access to functionality related to setting up DAC system properties, Informatica servers, database connections, and email notification.
Setup View: DAC System Properties Tab

Used to set DAC system properties to ensure proper integration between the DAC client, the DAC Server, and Informatica
Setup View: DAC System Properties Tab You need to set DAC system properties to ensure proper integration between the DAC client, the DAC Server, and Informatica. You already worked with some of these properties when you configured the DAC in Practice 4-1: Configuring the Training Environment. Recall that you used the DAC Systems Properties tab to set values for the Main Informatica Repository, Repository Name, DAC Server Host, and InformaticaParameterFileLocation. For a complete description of all DAC system properties, refer to the Oracle Business Intelligence Data Warehouse Administration Console Guide.
Setup View: Informatica Servers Tab

Enables you to register one or more Informatica servers and one Informatica Repository server, and to specify how many workflows can be executed in parallel on each server
Machine Name
Setup View: Informatica Servers Tab The Informatica Servers tab enables you to register one or more Informatica servers and one Informatica Repository server and to specify how many workflows can be executed in parallel on each server. The DAC server load balances across the servers. You already worked with this tab when you configured the DAC in Practice 4-1: Configuring the Training Environment. Recall that you used the DAC Informatica Servers tab to register the Informatica Integration Services service and the Informatica Repository Service by modifying the server host name and password.
Setup View: Physical Data Sources Tab

Provides access to the connection properties for the physical data sources
Machine Name
Setup View: Physical Data Sources Tab The Physical Data Sources tab provides access to the connection properties for the physical data sources. In this tab, you can view and edit existing physical data source connections and create new ones. You already worked with some of this tab when you configured the DAC in Practice 4-1: Configuring the Training Environment. Recall that you used the DAC Physical Data Sources tab to set properties for the transactional and data warehouse physical data sources shown here.
Setup View: Refresh Dates

Refresh dates refer to the date of the last ETL process. They are used by DAC to determine whether to run a full or incremental load.
Setup View: Refresh Dates Refresh dates refer to the date of the last ETL process (the last time data was extracted from tables in a given database or loaded into tables in a given database). The DAC uses the refresh dates to determine whether to run the incremental load commands or to run full load commands and whether to truncate the target tables. Refresh dates are tracked only for tables that are either a primary source or a primary target on tasks in a completed run of an execution plan. The DAC runs the full load command for tasks on which a table is a primary source or target if the refresh date against the table is null. When there are multiple primary sources, the earliest of the refresh dates will trigger a full load or an incremental load. If any one of the primary source tables has no refresh date, then the DAC will run the full load command. The slide shows the refresh dates for the data warehouse tables. You can clear the refresh dates for all source and target tables by selecting ETL Management > Reset Data Warehouse. This action forces a full load to occur on the next ETL execution.
Setup View: Email Recipients Tab

Enables you to set up a list of email addresses that will be notified about the status of the ETL process
Setup View: Email Recipients Tab This tab enables you to set up a list of email addresses that will be notified about the status of the ETL process. Properties you can set on this tab include: Name: The logical name of the user to be notified Email Address: The email address where the notification is sent Notification Level: The notification levels are as follows: - 10: Notifies the recipient of the success or failure of each task - 5: Notifies the recipient of the success or failure of the entire ETL process - 1: Notifies the recipient that ETL completed successfully
Execute View
Provides access to functionality that enables you to run, schedule, and monitor execution plans
Execute View The Execute View provides access to functionality that enables you to run, schedule, and monitor execution plans.
Execute View: Execution Plans Tab

Enables you to view, edit, create, build, and run execution plans
Run
Build
Execution plan
Subject areas associated with execution plan
Execute View: Execution Plans Tab The Execution Plans tab enables you to view and edit existing execution plans and to create new ones. You can use the child tabs to view DAC objects associated with an execution plan, such as subject areas, parameters, ordered tasks, and so on. The slide shows the Complete Oracle 11.5.10 execution plan and a partial list of the associated subject areas. The Build button builds the execution plan by assembling subject areas, tasks, task phases, indices, tags, parameters, and source system folders. The Run Now button submits a request to the DAC server to execute the execution plan.
Execute View: Parameters Subtab

Lists the parameters of the selected execution plan for database connections and Informatica folders
Execute View: Parameters Subtab The Parameters subtab lists the parameters of the selected execution plan for database connections and Informatica folders. At run time, the DAC Server compiles a file for each Informatica DAC task that contains Informatica Server parameters and writes it to the \ \Informatica\PowerCenter8.1.1\server\infa_shared\SessLogs directory. This file includes generic as well as task-level parameters set at the task object level, and the execution plan-level parameters that specify connection details for the transactional database sourced by the execution plan as well as the warehouse it targets. The tasks parameter file, after it is generated, is referenced in the PMCMD command issued for the task during the execution of an execution plan. You click Generate to generate the parameters for an execution plan. Execution plan parameters include the Informatica repository folders related to the container that the execution plan belongs to, as well as data source connections. You need to only update the pertinent connection parameters. The parameter names are generated as they will appear in the parameter file generated at run time. The connection details specified in the execution plan parameters must match physical data sources specified in the Setup view, which, in turn, must match the source and target relational connections configured in the Informatica repository. You learn more about generating execution plan parameters in the lesson titled Customizing DAC Metadata and Running an Execution Plan.
Execute View: Prune Days

Ensures that the rows older than values in LAST_REFRESH_DATE are not missed
Prune days
Execute View: Prune Days The Prune Days setting ensures that the rows older than values in LAST_REFRESH_DATE are not missed. This parameter improves the change capture process by overlapping the extraction date window by the number of days set in this parameter. You can set this parameter based on your experience with processes, such as remote sync, that potentially can cause records to be missed. The DAC subtracts the number of prune days from the LAST_REFRESH_DATE of a given source and supplies this as the value for the $$LAST_EXTRACT_DATE parameter.
Execute View: Current Run Tab

Displays a list of queued, running, and failed current ETL processes
Current ETL run
Running tasks
Execute View: Current Run Tab The Current Run tab displays a list of queued, running, and failed current ETL processes in the top window. This list includes comprehensive information about each process, including run status, start and end timestamps, duration, ETL process ID, and so on. After an ETL process completes, it is accessible from the Run History tab, which is discussed in the next slide. The Current Run tab includes the following subtabs: The Audit Trail (RO) subtab is a read-only tab that provides the history of the selected run. The Summary (RO) subtab provides a summary (based on dynamic SQL) of the selected ETL run. The Tasks subtab displays run-time instances of the tasks. As the execution proceeds, the tasks are executed based on the dependency rules and some prioritization. As tasks complete, the tasks that depend on the completed tasks are notified and after their dependencies are completed, they become eligible to run. If a task fails, the administrator can address the failure and then requeue the task or mark it as completed. The slide shows the running tasks for the Custom Revenue ETL run. The Task Details subtab opens in Query mode. It enables you to query for tasks associated with the selected ETL run in order to view execution details.
Execute View: Run History Tab

Displays information about completed ETL processes
Completed tasks
Execute View: Run History Tab The Run History tab displays information about completed ETL processes. The information displayed in the top and bottom windows is the same as that in the Current Run tab.
ETL run
ETL process ID
Execute View: Scheduler Tab

Enables you to schedule ETL processes to be executed either once at a later time or periodically
Next trigger
Name of scheduled task
Execution plan
Recurrence
Execute View: Scheduler Tab The Scheduler tab enables you to schedule ETL processes to be executed either once at a later time or periodically. When you schedule an ETL or make changes to a schedule, the DAC server picks up the information from the DAC client. The DAC server polls the DAC repository for changes periodically at a frequency set in the DAC system properties. The top window of the Scheduler tab lists ETL runs that have been scheduled. The bottom window enables you to schedule an ETL run. Properties of a scheduled ETL run include: Execution Plan: The name of the scheduled execution plan Last Schedule Status: The last run status of the scheduled ETL process. Possible values are Running, Completed, or Stopped. Next Trigger: The time the scheduled ETL run will next be executed Status Description: A description of the last ETL run. Possible values are Running, Completed, or the reason the process stopped. Recurrence: The time frequency that the schedule will be executed
Resetting the Data Warehouse

Clears the refresh dates for all source and target tables forcing a full load to occur on the next ETL execution Select Tools > ETL Management > Reset Data Warehouse. Confirm that you want to perform a full truncate and load.
Resetting the OBAW Resetting the OBAW clears the refresh dates for all source and target tables, forcing a full load of the OBAW on the next ETL execution. The process requires that you type a generated string to confirm your intention to reset the OBAW because this will truncate all tables and run a full load of the warehouse, which is a time-intensive process.
Object Ownership in the DAC

Original object font: Black by default, regular style Clone object font: Blue color, regular style Reference object font: Green color, italic style
Original Clone Reference
Object Ownership in the DAC The source system container in which an object originates is the owner container. The tabs in the DAC Design view display the owner of the various repository objects. You can reuse an object among different source system containers by referencing the object. A reference works like a symbolic link or shortcut. You can use the referenced object just as you would an original object, but the objects ownership remains unchanged. You can reference an object from its owner container, and you can also reference an object that has already been referenced by another source system container. If you modify a referenced object, the modified object becomes a clone and the ownership changes to the source system container in which you performed the modification. When you make changes to an original object that has been referenced by other containers, any updates to the original object are immediately reflected in the referenced object. If you delete the original object, all referenced objects are also deleted. Changes to an original objects child objects are not automatically reflected in the referenced objects child objects. Use the rightclick command and select Ownership, and then select Push to References to push the changes to the referenced objects child objects. And, conversely, you can import into a referenced object the changes made to an original object; this function is referred to as a re-reference.
Summary
In this lesson, you should have learned how to: Use the tools and views of the Data Warehouse Administration Console (DAC) Describe DAC objects, how they relate to each other, and their roles in the Oracle Business Analytics Warehouse (OBAW) extract, transform, and load (ETL) process
Practice 9-1: Exploring the DAC

This practice covers exploring the DAC.
Practice 9-1: Exploring the DAC In this practice, you explore the Oracle BI Data Warehouse Administration Console (DAC) to become familiar with its functionality, objects, and properties.
Configuring Analytical Applications

Objectives
After completing this lesson, you should be able to: Perform preload configuration steps that apply to Oracle Business Intelligence Applications deployed with any source system Configure general ledger account hierarchies using the flexfield value set definitions for general ledger accounting Map Oracle general ledger natural accounts to group account numbers Create a new metric in the repository after adding a new group account number
Configuration Required Before a Full Load

1. 2. 3. 4. 5. Set the Initial Extract Date Set the global currencies Set the exchange rate types Set fiscal calendars View and modify DATASOURCE_NUM_ID
Configuration Required Before a Full Load This slide lists the configuration steps required before a full data load. Note that steps 15 apply to Oracle Business Intelligence Applications deployed with any source system. Step 6 is required if you are deploying Oracle Financial Analytics, Oracle Procurement and Spend Analytics, or Oracle Supply Chain and Order Management Analytics. Steps 7 and 8 are required if you are deploying Oracle EBS source systems. Each topic is covered in detail in the slides that follow.
6. Set general ledger account hierarchies using flexfield value set definitions 7. Map Oracle GL natural accounts to group account numbers 8. Create a new metric based on a new group account number
Initial Extract Date

Identifies the date from which you want to extract data from a source Is required when you extract data for a full load Reduces the volume of data in the initial load by acting as a filter on the creation date of OLTP data Is set in the Source System Parameters tab in the Design view of the DAC client
Initial Extract Date The Initial Extract Date parameter identifies the date from which you want to begin extracting data from a source. For example, your records go back to January 1996, but you only want to extract records from January 2001. The initial extract date is required when you extract data for a full load. It reduces the volume of data in the initial load. The specified initial extract date will be used as a filter on the creation date of OLTP data in the selected full extract mapping. The Initial Extract Date parameter is set in the Source System Parameters tab in the DAC client. The default date is January 1, 1970. When you set the Initial Extract Date parameter in the DAC client, make sure that you set it to the beginning of an accounting period, and not a date in the middle of an accounting period. For example, if you decide to extract data from June 2005, and the June 2005 accounting period starts from 5th June, set the date to 5th June, 2005.
Global Currencies
Are used to convert local and document currencies into the common currencies used by the data warehouse Are useful for creating enterprise-wide reports where users must view data in multiple currencies Are set in the Source System Parameters tab in the Design view of the DAC client
Global Currencies Out of the box, Oracle Business Intelligence Applications provides three global currencies, which are the common currencies used by the Data Warehouse. For example, if your organization is a multinational enterprise that has its headquarters in the United States, you probably want to choose US dollars (USD) as one of the three global currencies. If you also conduct business in Canada and the United Kingdom, you would choose Canadian dollars (CAD) and United Kingdom pounds (GBP) as the other two global currencies. Note that you must spell the currencies as they are spelled in your OLTP source system. The global currency is useful when creating enterprise-wide reports. For example, a user might want to view enterprise-wide data in other currencies. For every monetary amount extracted from the source, the load mapping loads the document amount (the currency of the transaction) and local amounts (the currency in which accounting entries are recorded) into the target table. It also loads the exchange rates required to convert the document amount into each of the three global currencies. In the target table, there will be two amount columns and three exchange rate columns. You set values for the global currencies in the Source System Parameters tab in the Design view of the DAC client.
Exchange Rate Types

Are required when OBI Applications converts:
Transaction records amount from document currency to global currencies Transaction records amount from document currency to local currency
Exchange Rate Types When Oracle Business Intelligence Applications converts your transaction records amount from document currency to global currencies, it also requires the exchange rate types to perform the conversion. For each of the global currencies, Oracle Business Intelligence Applications also enables you to specify the exchange rate type to use to perform the conversion. Oracle Business Intelligence Applications also provides three global exchange rate types for you to configure. Oracle Business Intelligence Applications also converts your transaction records amount from document currency to local currency. Local currencies are the base currencies in which your accounting entries and accounting reports are recorded. To perform this conversion, Oracle BI Applications also enables you to configure the rate type that you want to use when converting the document currency to the local currency. You set values for the exchange rate types in the Source Systems Parameters tab in the Design view of the DAC client. There are three global exchange rate types ($$GLOBALx_RATE_TYPE), one for each global currency and one exchange rate type for document currency to local currency conversion ($$DEFAULT_LOC_RATE_TYPE). Note that you must spell the exchange rate type values as they are spelled in your OLTP source system.
Are set in the Source System Parameters tab in the Design view of the DAC client
Fiscal Calendars
May be provided in terms of fiscal weeks or fiscal months Are configured by modifying either:
The fiscal month start date in the file fiscal_month.csv, and then activating the task SIL_DayDimension_FiscalMonth_Extract in the DAC The fiscal week start date in the file fiscal_week.csv, and then activating the task SIL_DayDimension_FiscalWeek_Extract in the DAC
Set Start Date in .csv file. Activate task in DAC.
Fiscal Calendars Installed out of the box, Oracle Business Intelligence Applications supports one fiscal calendar. Fiscal data is first loaded in the W_DAY_D table and then the SIL mappings read data from W_DAY_D and load data into the aggregate fiscal time dimension tables such as Fiscal Week, Fiscal Month, Fiscal Quarter, and Fiscal Year. You may choose to provide fiscal calendar information in terms of the fiscal weeks of your organization or in terms of the fiscal months of your organization. In either case, the SIL mappings are designed to derive the Fiscal Week from the start date and end date of a fiscal month by grouping into periods of seven days each. To configure fiscal calendars, you must modify the appropriate .csv file and activate the corresponding task in the DAC. For example, to set up fiscal calendars by fiscal month, you would open fiscal_month.csv file in the \Informatica\PowerCenter8.1.1\server\infa_shared\SrcFiles directory and set the start date of the fiscal month in the YYYYMMDD format. You would then activate the SIL_DayDimension_FiscalMonth_Extract task in the DAC (Inactive check box is not selected).
DATASOURCE_NUM_ID
DATASOURCE_NUM_ID is a system column in the data warehouse that uniquely identifies a data source category and indicates which source systems the data comes from. DATASOURCE_NUM_ID values are predefined for data sources supported by Oracle Business Intelligence.
You can view and modify DATASOURCE_NUM_ID values in the Physical Data Sources tab in the Setup view in the DAC client.
DATASOURCE_NUM_ID DATASOURCE_NUM_ID is a system column in the data warehouse that uniquely identifies a data source category and indicates which source systems the data comes from. For example, the value 1 indicates one of the Siebel data sources, and the value 4 indicates an Oracle 11.5.10. data source. This value is passed as a parameter to the Informatica workflows. If you are using multiple sources, each data source has a unique number. Typically, all source dependent extracts will use this parameter to populate the DATASOURCE_NUM_ID column, and the source independent workflows will carry these values to the final dimension and fact tables. Oracle Business Intelligence is installed with a number of predefined data source templates that you can edit to specify OLTP and OLAP data sources. If you are editing a data source template for a data source type, Oracle recommends that you do not change the value that is set out of the box. If you are specifying a data source without using a predefined template, you must use the correct value for that data source category. For example, if you specify an Oracle EBS R12 data source, you must specify the DATASOURCE_NUM_ID value 9. You can view and modify DATASOURCE_NUM_ID values in the Physical Data Sources tab in the Setup view in the DAC client.
For example, the data source ORA_11_5_10 is associated with the DATASOURCE_NUM_ID value = 4.
Setting General Ledger Account Hierarchies Using Flexfield Value Sets Definitions
Use file_glacct_segment_config_ora.csv to ensure that when segment information is extracted into the warehouse table W_GL_ ACCOUNT_D, segments with the same nature from different chart of accounts are stored in the same column in W_GL_ACCOUNT_D.
file_glacct_segment_config_ora.csv
W_GL_ACCOUNT_D
General Ledger Account Hierarchies Using Flexfield Value Sets Definitions There are two ways to set up hierarchies in Oracle Financial Analytics: using the flexfield value set definitions for general ledger accounting or using the Financial Statement Generator (FSG) report definition. Whichever method you choose to set up general ledger account hierarchies, you store the hierarchy information in the W_HIERARCHY_D table. This slide shows the steps for setting up general ledger account hierarchies using the flexfield value set definitions for general ledger accounting . For more information about using the Financial Statement Generator (FSG) report definition, refer to the Oracle Business Intelligence Applications Fusion Edition Installation and Configuration Guide. Before you run the ETL process for general ledger accounts, you need to specify the segments that you want to analyze. To specify the segments that you want to analyze, you use the file_glacct_segment_config_ora.csv ETL configuration file. The objective of this configuration file is to make sure that when segment information is extracted into the warehouse table W_GL_ ACCOUNT_D, segments with the same nature from a different chart of accounts are stored in the same column in W_GL_ACCOUNT_D. Therefore, in this file, you need to specify the segments of the same nature in the same column.
General Ledger Account Hierarchies Using Flexfield Value Sets Definitions (continued) In the example in the slide, in file_glacct_segment_config_ora.csv, assume that SEG1 stores Department information, SEG2 stores Account information, and SEG3 stores Company information. When ETL is run, all SEG1 segments (Department) from all chart of accounts will be stored in the ACCOUNT_SEG1* columns; all SEG2 segments (Account) from all chart of accounts will be stored in the ACCOUNT_SEG2* columns; all SEG3 segments (Company) from all chart of accounts will be stored in the ACCOUNT_SEG3* columns; and so on in W_GL_ACCOUNT_D. As expected, in the example in the slide, segments with value set ID 1002471 are stored in ACCOUNT_SEG1* columns, and segments with value set ID 1002472 are stored in ACCOUNT_SEG2* columns.
Mapping Oracle GL Natural Accounts to Group Account Numbers

Use file_group_acct_codes_ora.csv to provide the logic for assigning GL natural accounts to group account numbers. Each row maps all accounts within the specified account number range for a given chart of account ID to a group account number, which is stored in W_ACCOUNT_D.
file_group_acct_codes_ora.csv
W_ACCOUNT_D
Mapping Oracle GL Natural Accounts to Group Account Numbers Oracle EBS General Ledger (GL) does not contain business attributes that represent real world entities such as supplier, customer, employee, and so on. This information resides in the subledgers, for example, supplier dimension in accounts payables (AP) and customer dimension in account receivables (AR). In Oracle GL, the transactions are tracked at an account level and used more for bookkeeping purposes. Therefore, to facilitate reporting on the GL transactions in a data warehouse environment, OBIEE Financial Analytics applications use the group account number to categorize the accounting entries. It is critical that general ledger account numbers are mapped to the group account numbers (or domain values) because the group account number is used during data extraction as well as front-end reporting. Use the file_group_acct_codes.ora.csv file to provide the logic for assigning GL natural accounts to group account numbers. In this example, all accounts within the account number range from 4110 to 4110 that have a chart of accounts ID equal to 101 are assigned to the Revenue group account number. Group account number (GROUP_ACCOUNT_NUM) is stored in W_ACCOUNT_D and denotes the nature of the general ledger accounts (for example, REVENUE, payroll account). The file_group_acct_names.csv file (not shown here) provides a list of group account numbers that you can use. For example, AP equals ACCOUNTS PAYABLES, AR equals ACCOUNTS RECEIVABLE, REVENUE equals SALES REVENUE, and so on.
Creating a New Metric Based on a New Group Account Number

1. 2. 3. 4. Create a new group account number. Duplicate an existing measure. Rename measure and modify filter. Add measure to Presentation layer.
Creating a New Metric Based on a New Group Account Number When you add a new group account number in file_group_acct_codes_ora.csv, it does not show up in your reports. You need to create a new metric that maps to the new group account number in the Oracle BI repository. The steps are listed here. Each step is covered in detail in the slides that follow.
Create a New Group Account Number

Create a new group account number in file_group_acct_codes_ora.csv.
Create a New Group Account Number The first step is to create a new group account number in file_group_acct_codes_ora.csv.
Duplicate an Existing Measure

Duplicate an existing measure in the Business Model and Mapping layer of the Oracle BI repository that has a filter for an existing group account number.
Duplicate an Existing Measure Duplicate an existing measure in the Business Model and Mapping layer of the Oracle BI repository that has a filter for an existing group account number, in this example, the Prepaid Expenses logical column filters for those GL accounts that belong to the group account number PPAID EXP. Thus, the measure Prepaid Expenses is the total amount coming from accounts that have a group account number equal to PPAID EXP.
Rename the Measure and Modify the Filter

Rename the duplicated measure and modify the filter by substituting the new group account number.
Rename the Measure and Modify the Filter Rename the duplicated measure and modify the filter by substituting the new group account number. In this example, replace PPAID EXP with TEST in the filter. The metric TEST is now the total amount coming from accounts that have a group account number equal to TEST.
Add the Measure to the Presentation Layer

Add the new measure to the Presentation layer to make it available for reporting in Oracle BI Answers and dashboards.
Add the Measure to the Presentation Layer Add the new measure to the Presentation layer to make it available for reporting in Oracle BI Answers and dashboards.
Summary
In this lesson, you should have learned how to: Perform preload configuration steps that apply to Oracle Business Intelligence Applications deployed with any source system Configure general ledger account hierarchies using general ledger accounting flexfield value set definitions Map Oracle general ledger natural accounts to group account numbers Create a new metric in the repository after adding a new group account number
Practice 10-1 Overview: Configuring Common Areas and Dimensions Before Running a Full Load The goal of this practice is to perform preload configuration steps that apply to Oracle Business Intelligence Applications deployed with any source system. This practice contains configuration steps for Oracle Business Intelligence that you need to follow for any applications you deploy (for example, Oracle Financial Analytics, Oracle Human Resources). This includes steps required before a full data load and steps for controlling your data set.
Practice 10-1 Overview: Configuring Common Areas and Dimensions Before Running a Full Load This practice covers the following topics: Creating a copy of a preconfigured source system container Configuring the initial extract date Configuring global currencies Configuring exchange rate types Configuring fiscal calendars Configuring DATASOURCE_NUM_ID
Practice 10-2 Overview: Configuring General Ledger Account Hierarchies

This practice covers the following topics: Exploring general ledger account hierarchies in W_HIERARCHY_D Exploring the file_glacct_segment_config_ora.csv file
Practice 10-2 Overview: Configuring General Ledger Account Hierarchies The goal of this practice is to configure general ledger account hierarchies using flexfield value set definitions for general ledger accounting.
Exploring the hierarchy information in the physical layer of the preconfigured repository
Practice 10-3 Overview: Mapping Oracle GL Natural Accounts to Group Account Numbers This practice covers the following topics: Exploring W_GL_ACCOUNT_D Exploring the file_group_acct_names_ora.csv file Exploring the data model reference to identify domain values Exploring the file_group_acct_codes_ora.csv file Exploring the file_grpact_fstmt.csv file
Practice 10-3 Overview: Mapping Oracle GL Natural Accounts to Group Account Numbers The goal of this practice is to map Oracle general ledger natural accounts to group account numbers. It is critical that general ledger account numbers are mapped to the group account numbers (or domain values) because the metrics in the general ledger reporting layer use these values. You can categorize your Oracle general ledger accounts into specific group account numbers. The group account number is used during data extraction as well as front-end reporting.
Practice 10-4 Overview: Creating a New Metric Based on a New Group Account Number This practice covers the following topics: Exploring how measures are mapped to group account numbers in the OBI repository Creating a new group account number in file_group_acct_codes_ora.csv
Practice 10-4 Overview: Creating a New Metric Based on a New Group Account Number The goal of this practice is to create a new metric in the prebuilt repository after adding a new group account number. When you add a new group account number in file_group_acct_codes_ora.csv, it does not automatically show up in your reports. You need to create a new metric in the Oracle BI repository that maps to the new group account number.
Creating a new measure in the repository
Customizing DAC Metadata and Running an Execution Plan

Objectives
After completing this lesson, you should be able to: Create custom metadata objects in the DAC Run an execution plan and monitor the results
Customizing DAC Metadata and Running an Execution Plan

Creating or copying a source system container Creating a subject area Assembling a subject area Creating an execution plan Generating execution plan parameters Building an execution plan Verifying that DAC Server is started Running an execution plan Monitoring an execution plan Viewing Run History for an execution plan Viewing predefined reports Verifying data
Customizing DAC Metadata This slide lists the steps to customize DAC metadata, and then run and monitor an execution plan. Each step is covered in detail in the slides that follow.
Creating or Copying a Source System Container

You cannot change the metadata for preconfigured containers. If you want to customize the metadata in a preconfigured container, you must first make a copy of the container. You can also create a new, empty container. In the DAC client, select File > New Source System Container.
ID and Name fields are alphanumeric.
Create empty container or copy existing container.
To copy, select existing container from list.
Creating or Copying a Preconfigured Source System Container The metadata for a source system is held in a container. You cannot change the metadata for preconfigured containers. If you want to customize the metadata in a preconfigured container, you must first make a copy of the container. The DAC keeps track of all customizations in the copied container, so that at any time you can find the newly created objects and modified objects, as well as the original objects. You can also create a new, empty container if you want to build your own container with customized metadata. The example in the slide shows how to create a copy of a preconfigured container. The ID and Name fields are alphanumeric. The Name can contain spaces but the ID cannot. When making a copy of an existing container, select the existing container from the list.
Creating a Subject Area

1. In the Design view, select the Subject Areas tab and click New. 2. Assign a fact table.
Custom container
Use Add/Remove to assign fact tables to a subject area.
Creating a Subject Area When you create a new subject area, you assign one or more fact tables to the subject area. The DAC then determines which dimension and other related tables are required as well as the tasks and their order of execution.
Assembling a Subject Area

The DAC assembles a subject area by determining what dimensions and other related tables are required and what tasks are needed to load these tables.
Tasks added by assembly process
Autogenerated identifies tasks added by the DAC.
Assembling a Subject Area Select a subject area or list of subject areas and click Assemble. The DAC assembles a subject area by determining what dimensions and other related tables are required and what tasks are needed to load these tables. After the assembly of a subject area is completed, verify that the expected tasks are visible in the Tasks subtab. The screenshot shows only a partial view. All tasks generated by the assembly of the subject area are marked as Autogenerated, which identifies tasks that are added by the DAC. You can inactivate a task from participating in the subject area by selecting the Inactive check box (not shown here). When the Inactive check box is selected, the task remains inactive even if you reassemble the subject area. You can also remove a task from the subject area by using the Add/Remove command, but when you remove a task it is only removed from the subject area until you reassemble the subject area.
Creating an Execution Plan

1. In the Execute view, select the Execution Plans tab and click New. 2. Associate one or more subject areas with the execution plan.
Use Add/Remove to assign subject areas to an execution plan.
Creating an Execution Plan When you create a new execution pan, you assign one or more subject areas to the execution plan. The DAC compiles and sets precedence for the tasks required to load the subject areas included in the plan. Please note that in this example the execution plan and subject area are both named Custom Revenue.
Generating Execution Plan Parameters

Select the Parameters child tab for the execution plan and click Generate to generate a list of seed parameters, which then must be updated.
Execution plan parameter values must match physical data sources specified in the Setup view.
Generating Execution Plan Parameters At run time, the DAC Server compiles a file for each Informatica DAC task that contains Informatica Server parameters and writes it to the \Informatica\PowerCenter8.1.1\server\infa_shared\SessLogs directory. This file includes generic as well as task-level parameters set at the task object level, and the execution planlevel parameters that specify connection details for the transactional database sourced by the execution plan as well as the warehouse it targets. The tasks parameter file, after generation, is referenced in the PMCMD command issued for the task during execution of an execution plan. To generate execution plan parameters, select the Parameters child tab for the execution plan and click Generate. A list of seed parameters, which are to be updated, is generated. Execution plan parameters include the Informatica repository folders related to the container that the execution plan belongs to, as well as data source connections. You need to only update the pertinent connection parameters. The parameter names are generated as they will appear in the parameter file generated at run time. The connection details specified in the execution plan parameters must match physical data sources specified in the Setup view, which, in turn, must match the source and target relational connections configured in the Informatica repository. If you need to verify that the values are correct, you can navigate to the Setup view and check the names of the Source and Warehouse type connections.
Building an Execution Plan

When you build an execution plan, the DAC compiles and sets precedence for the tasks required to load the subject areas included in the plan.
Depth indicates execution precedence at run time.
The Ordered Tasks subtab displays a list of all tasks belonging to the subject areas included in the execution plan.
Building an Execution Plan Select an execution plan or list of execution plans and click Build. The DAC compiles and sets precedence for the tasks required to load the subject areas included in the plan. After the execution plan is built, the Ordered Tasks subtab displays a list of all the tasks that prepare, extract, and load the tables belonging to the subject areas included in the execution plan. Notice that each task is assigned a task depth, indicating its execution precedence at run time. Tasks that have no dependencies have a depth of 0. Tasks that depend on other tasks having a depth of 0 have a depth of 1, and so on.
Verifying DAC Server Is Started

Verify that the DAC Server Monitor icon in the upper-right corner of the DAC client resembles an orange electrical plug in a socket, which means that the client is connected to the server and the server is idle.
Verify that the DAC Server Monitor icon resembles an orange electrical plug in a socket.
Verifying DAC Server Is Started Before running an execution plan, verify that the DAC Server Monitor icon in the upper-right corner of the DAC client resembles an orange electrical plug in a socket, which means that the client is connected to the server and the server is idle. When you move the cursor over the orange icon, you should be able to see the message DAC Server is idle. When the DAC client cannot establish a connection to the DAC server, the Server Monitor icon resembles a red electrical plug. If the client is connected to a server that is running an ETL process, the icon resembles a green electrical plug with a lightning sign superimposed on it. If the DAC Server is not started, select Start > Programs > Oracle Business Intelligence > Oracle DAC > Start DAC Server and verify that the DAC Server Monitor icon resembles an orange electrical plug in a socket before continuing.
Running an Execution Plan

To run an execution plan, select the execution plan and click Run Now.
Click Yes to confirm that you want to start the execution plan.
Running an Execution Plan To run an execution plan, perform the following steps: 1. Select Execute in the DAC toolbar. 2. In the Execution Plans tab, select the execution plan. 3. Click the Run Now button in the Top Pane toolbar. 4. In the Starting ETL dialog box, click Yes to confirm that you want to start the execution plan. 5. Click OK to acknowledge that the request has been successfully submitted to the Informatica Server.
Monitoring an Execution Plan

The Current Run tab displays a list of queued, running, and failed current ETL processes in the top window.
Click Auto Refresh to set automatic refresh frequency.
Select the Tasks subtab to view task status within the execution plan.
Monitoring an Execution Plan Use the Current Run tab to monitor queued, running, and failed ETL processes. Information provided on this tab includes the following: Execution Plan Name: Execution plan whose run-time instance is this record Run Status: Status of the run: queued, runnable, running, paused, failed, stopped, completed Start Timestamp and End Timestamp: Start and end time of the ETL process Duration: Total duration of the ETL process Process ID: ID for this ETL process Total Number of Tasks: Total number of tasks for this run Number of Failed Tasks: Total number of tasks that have failed and that have stopped Number of Successful Tasks: Number of tasks whose status is Completed Number of Tasks Still in Queue: Number of tasks whose prerequisite tasks have not completed, and the number of tasks whose prerequisite tasks are completed and are waiting for resources The Tasks subtab displays run-time instances of the tasks. The Task Details subtab opens in Query mode. It enables you to query for tasks associated with the selected ETL run in order to view execution details.
Viewing Run History for an Execution Plan

The Run History tab displays information about completed ETL processes. The information displayed in the top and bottom windows is the same as that in the Current Run tab.
Viewing Run History for an Execution Plan The Run History tab displays information about completed ETL processes. The information displayed in the top and bottom windows is the same as that in the Current Run tab. When the execution plan completes, you should verify that Run Status = Completed, Status Description = Finished, and Number of Failed Tasks = 0. If the execution plan fails: When an execution plan is executed, if a task fails, the status of the tasks that are dependent on the failed task is changed to Stopped. While tasks are still running, the execution plans status is Running. When all the tasks have been run, and if one or more tasks have failed, the execution plans status is changed to Failed. You can check the tasks that have failed in the Current Run tab of the Execute view, fix the problems, and then requeue the failed tasks by changing the status to Queued. You can then restart the ETL. All the tasks will then be rerun. You can also manually run a task, change its status to Completed, and then restart the ETL. Tasks with a Completed status are skipped. If you need assistance, ask your instructor.
Viewing Predefined Reports
Viewing Predefined Reports The Current Run and Run History tabs in the Execute view provide predefined reports that enable you to monitor and analyze execution plan processes in order to isolate bottlenecks and enhance performance. The following options are available: Get log file Analyze Run Get chart Get phase chart Get graph The slide shows the Get log file option.
Default location for log files
Verifying Data
Query the data warehouse to verify that tables contain the expected data.
Summary
In this lesson, you should have learned how to: Create custom metadata objects in the DAC Run an execution plan and monitor the results
Practice 11-1 Overview: Customizing DAC Metadata

This practice covers the following topics: Creating custom metadata objects in the DAC Running an execution plan and monitoring the results
Practice 11-1 Overview: Customizing DAC Metadata The goal of this practice is to customize the DAC by creating a new subject area and execution plan, and then running and monitoring the execution plan. Oracle Business Intelligence Applications provides preconfigured subject areas and execution plans. You can change these preconfigured objects or create new objects to correspond to your particular business requirements. After examining your business requirements, you determine that the only subject area you want to analyze is Financials Revenue. Please note that a preconfigured Financials Revenue subject area already exists. But for training purposes, you create and run a custom subject area and execution plan limited to the Financials - Revenue fact table.
Customizing Oracle Business Analytics Warehouse

Objectives
After completing this lesson, you should be able to: Identify and describe customization types and scenarios associated with the Oracle Business Analytics Warehouse (OBAW) Apply the OBAW customization best practices
Customization
Is the process by which the Oracle Business Analytics Warehouse tables and columns, and custom extract, transform, and load (ETL) mapping templates are modified to accommodate new data for analysis
Customization Customization is the process by which the Oracle Business Analytics Warehouse tables and columns, and custom ETL mapping templates are modified to accommodate new data for analysis. The OBAW ships with a collection of star schema tables and columns that may not completely accommodate the analysis needs of a business. To accommodate new data, the OBAW tables and columns, Informatica mappings and workflows, and the DAC metadata must be modified.
Customization Scenarios
Are categorized across data sources and modification types
DW modifications Additional columns Data sources Packaged application Nonpackaged data TYPE I Additional rows Configure filter TYPE III Additional tables TYPE II
TYPE I
TYPE II
Customization Scenarios In customizing the Oracle Business Analytics Warehouse, various scenarios are available based on the type of data source: Packaged applications (for example, Siebel or Oracle) use prepackaged adaptors. Nonpackaged data sources use the universal adaptor. The graphic in this slide shows the categories of supported customization scenarios, based on the data source: Type I: In a Type I customization, you add additional columns (that are already mapped) from a source system and load the data into existing data warehouse tables. Type II: In a Type II customization, you use prepackaged adaptors to add new fact or dimension tables to the data warehouse, regardless of whether they are already mapped. Type II customizations normally require that you build new SDE and SIL mappings. Type III: In a Type III customization, you use the universal adaptor to create new mappings. There is no real significance to the type names. It is just a way to organize the information. Type I and Type II customizations are covered in detail in this lesson and in the lessons titled Adding Columns to an Existing Dimension Table and Adding a New Dimension in OBAW. For more information about Type III customizations, refer to the Oracle Business Intelligence Applications Installation and Configuration Guide.
Upgrade Considerations
Follow the recommended customization methodology to minimize the effort required to reapply customization after an upgrade.
Upgrade Considerations One of the most difficult aspects about working with customizations is handling the customizations at the time of an upgrade. Informatica does not provide a diff-merge capability that would detect changes introduced by customers and add them into upgraded mappings. Therefore, customizations must be reapplied manually to upgraded mappings. Oracle Business Intelligence Applications attempts to minimize the amount of effort required to reapply customizations after an upgrade. As long as the customization methodology is followed, the effort at upgrade time should be minimal and, in many cases, there may be no manual effort required at all. This customization methodology is presented throughout this lesson.
Type I Customization: Adding Columns to Existing Tables

Type I customizations involve extracting additional columns from source systems that are already mapped (for example, Siebel or Oracle) and loading the data into existing data warehouse tables.
Type I Customization: Adding Columns to Existing Tables Type I customizations involve extracting additional columns from source systems that are already mapped (for example, Siebel or Oracle) and loading the data into existing data warehouse tables. For Type I customizations, data can also come from nonpackaged sources, but this assumes that the sources have already been mapped with a universal adaptor and only need to be extended to capture additional columns.
Type I Customization: Extending Mappings

Existing mappings and tables are extensible. Sample placeholders demonstrate how to pass and store additional data. Oracle BI Applications provides a methodology to extend preconfigured mappings to include additional columns and load the data into existing tables.
Copy and modify existing logic or columns.
Type I Customization: Extending Mappings To see additional columns in the data warehouse, the columns must first be passed through the ETL process. The existing mappings and tables are extensible. Sample placeholders demonstrate how to pass and store additional data. Oracle BI Applications provides a methodology to extend preconfigured mappings to include these additional columns and load the data into existing tables. Oracle BI Applications recognizes two types of customization: extension and modification. The supported extension logic enables you to add to existing objects. For example, you can extract additional columns from a source, pass them through existing mappings, and populate new columns added to an existing table. As a general rule, you should not modify existing logic or columns in the shipped folders. You should copy existing logic to custom folders and then modify it. You should not change existing calculations to use different columns, and you should not remap existing columns to be loaded from different sources.
Type I Customization: Safe Path

Most mappings have a single placeholder column, named X_CUSTOM, that marks a safe path through the mapping.
Preconfigured source Extension
Preconfigured logic Extension
Preconfigured target Extension
Customizations run parallel to existing logic.
Type I Customization: Safe Path Most mappings have a single placeholder column named X_CUSTOM, which marks a safe path through the mapping. All extension logic should follow the same route through the mapping as X_CUSTOM. You can add additional transformations to the mapping, but they should follow the same route through the mapping as X_CUSTOM. The graphic in the slide shows the preconfigured logic shaded in gray. You should not modify anything contained within these objects. You should add customizations to the existing mapping, which allows them to run parallel to the existing logic.
Type I Customization: Extension Categories

Exposed objects: Sources, targets, nonreusable transformations
Can be changed in the form of extensions (additive) Must be copied to custom folders before being modified
Encapsulated objects: Mapplets, resusable transformations

Should not be changed
Custom objects: Objects not shipped by Oracle

Can be added to a mapping
Type I Customization: Extension Categories Because some objects need to be modified to allow for extensions, Oracle BI Applications breaks down extensions into three categories: Exposed objects: These objects allow changes, but the changes must be in the form of extensions (additive). These objects should be copied to custom folders before being modified. These objects are included in the mapping when shipped and are usually sources, targets, and nonreusable transformations. Encapsulated objects: These objects cannot be extended. They attempt to hide as much of the shipped transformation logic as possible to prevent breaking the preconfigured logic. They should never be changed in any way unless directed by Oracle. These objects are included in the mapping when shipped and are usually mapplets and reusable transformations. Custom objects: You add custom objects to a mapping. (They are not shipped by Oracle.) Custom objects can be sources, transformations (reusable and nonreusable), or mapplets. Reusable transformations and mapplets that are shipped are considered encapsulated objects, but when you add such objects to an existing mapping, they are considered custom objects to that particular mapping. For example, if you want to add another amount to a fact table and that amount needs to be converted from its original currency to the data warehouse currency, you would normally add the existing Currency Exchange mapplet to the mapping to convert this new amount. In this case, the mapplet is considered a custom object to this particular mapping; however, it is also encapsulated, so the internal logic must not be changed.
Type I Customization: Impact of Customization on Upgrade

If you extend a mapping and the mapping: Does not change during the upgrade, all extensions are retained Experiences changes to the encapsulated logic, all extensions are retained Experiences changes to the exposed objects, extensions to these objects are lost but the underlying extension logic is retained
Extensions to exposed objects must be manually reapplied.
Type I Customization: Points to Remember

Never customize encapsulated objects unless directed by Oracle. Extend exposed objects but never modify them otherwise. Never change custom objects during an upgrade. Minimize the number of changes to exposed objects by using custom objects. Evaluate options and determine the best approach for your environment.
The custom object approach is the preferred approach if ETL time is acceptable.
Type I Customization: Points to Remember Encapsulated objects must never be customized unless directed by Oracle. Encapsulated objects are usually mapplets and reusable transformations. Exposed objects can be extended but must never be otherwise modified. Exposed objects may be completely replaced at upgrade. Custom objects are never changed during an upgrade. To minimize the work required for upgrading, try to minimize the number of changes to exposed objects by using custom objects. For example, rather than adding a table to the source qualifier to bring in a column from a related table, add a lookup to that table in the mapping. In customizing objects, you must evaluate the options and determine the best approach for your environment. If you find the custom object approach allows the ETL to run in an acceptable amount of time, then this is the preferred approach. If the custom object causes the ETL process to take too long, you may want to consider incorporating the extension into an exposed object.
Type I Customization: Typical Steps to Extend Mappings

1. Copy the appropriate mappings to a custom Informatica folder. 2. Extend the source and target tables by making changes to the tables in the database. 3. Extend the Source Dependent Extract (SDE) and Source Independent Load (SIL) mappings by bringing in the additional columns. 4. Copy the appropriate workflows to the custom Informatica folder. 5. Modify workflows and sessions as needed. 6. Update the Data Warehouse Administration Console (DAC) with the necessary changes.
Type I Customization: Typical Steps to Extend Mappings The most common scenario for extending the data warehouse is to extract existing columns from a source and pass them through to an existing data warehouse table (either fact or dimension). This type of change requires extending an SIL mapping. If the data is coming from a packaged source, then you will also need to extend an appropriate SDE adaptor mapping. If the data is coming from a nonpackaged source, then you must use a universal adaptor mapping. (You must create a universal adaptor mapping if an appropriate one does not already exist.) The steps listed in this slide are covered in more detail in the lesson titled Adding Columns to an Existing Dimension Table.
Type II Customization: Adding Additional Tables

Use prepackaged adaptors to add new fact or dimension tables to the data warehouse, regardless of whether they are already mapped. Build new SDE and SIL mappings.
Type II Customization: Adding Additional Tables In a Type II customization, you use prepackaged adaptors to add new fact or dimension tables to the data warehouse, regardless of whether they are already mapped. Type II customizations normally require that you build new SDE and SIL mappings.
Type II Customizations: Considerations

Use required system columns. Register tables and indices in the DAC. Register new tasks for Informatica workflows, assemble subject areas, and build execution plans in the DAC. Use the naming convention: WC_TABLENAME_<table type>.
Type II Customizations: Considerations If you are creating a new dimension or fact table, use the required system columns that are part of each of the data warehouse tables to maintain consistency and the ability to reference existing table structures. When you create a new table, you need to register the tables and indices in the DAC. You also have to register in the DAC the new tasks for the new Informatica workflows and then reassemble the appropriate subject area and rebuild the appropriate execution plan. When you create a new extension table, use the same naming convention as used in the Oracle Business Analytics Warehouse by adding the prefix WC to the table name, for example, WC_TABLENAME_DS. This will simplify future upgrades to the Oracle Business Analytics Warehouse.
Type II Customization: Required Columns

Staging tables:
INTEGRATION_ID, DATASOURCE_NUM_ID
Fact, dimension, and extension tables:

INTEGRATION_ID, DATASOURCE_NUM_ID, ROW_WID, ETL_PROC_WID
INTEGRATION_ID DATASOURCE_NUM_ID ROW_WID
Stores the primary key or unique identifier of a record as in the source table Stores the data source from which the data is extractedfor example, Oracle 11.5.10 = 4 Is the sequence number generated during the ETL process; unique identifier for the tables Stores the ID of the ETL process information in W_ETL_RUN_S in the data warehouse
ETL_PROC_WID
Type II Customization: Required Columns The Oracle Business Analytics Warehouse tables contain system fields that are populated and should not be modified by the user. For main and extension staging tables, use the required system columns INTEGRATION_ID and DATASOURCE_NUM_ID. For fact and dimension tables, use the required system columns INTEGRATION_ID, DATASOURCE_NUM_ID, ROW_WID, and ETL_PROC_WID. INTEGRATION_ID: Stores the primary key or the unique identifier of a record as in the source table DATASOURCE_NUM_ID: Stores the data source from which the data is extracted. For example, Oracle 11.5.10 is 4. For data from any external data source, assign a number greater than 1. ROW_WID: Is the unique SRMW row identifier. It is generated during the ETL process. To maintain integrity, this value should not be modified manually. ETL_PROC_WID: Stores the ID of the ETL process information. The details about the ETL process are stored in the W_ETL_RUN_S table on the data warehouse side. This is also the Process ID on the Current Run/Run History screen in the DAC.
Type II Customization: DATASOURCE_NUM_ID

Is part of the unique user key for all tables in the warehouse schema Permits rows to be loaded in the same warehouse tables from different sources, provided that the column is given a different value for each source Reserves values for predefined data sources
Type II Customization: DATASOURCE_NUM_ID All the tables in the Oracle Business Analytics Warehouse schema have DATASOURCE_NUM_ID as part of their unique user key. Although the transactional application normally ensures that a primary key is unique, it is possible that a primary key is duplicated between transactional systems. To avoid problems when loading this data into the data warehouse, uniqueness is ensured by including the DATASOURCE_NUM_ID as part of the user key. This means that the rows can be loaded in the same data warehouse tables from different sources if this column is given a different value for each data source. The DATASOURCE_NUM_ID is maintained by the DAC. Make sure that each source system has a unique value assigned to it. It is possible to have multiple instances of the same source system (for example, a U.S.-based and a European-based Oracle transactional database both loading into the same data warehouse). The two different transactional database systems should be assigned different DATASOURCE_NUM_ID values in the DAC. The DAC is predefined with one entry for ORA_11_5_10 and the DATASOURCE_NUM_ID is assigned the value of 4. If you are going to extract from additional Oracle transactional database systems and load the data into the same data warehouse, a different DATASOURCE_NUM_ID must be assigned to each Oracle transactional database system.
Type II Customization: Custom Folders

Create custom SDE and SIL folders in the Informatica and make changes in them.
Do not store customized SDE and SIL mappings in the same folder.
Do not change objects in shipped folders.
Type II Customization: Custom Folders If you want to make changes to the Oracle Business Analytics Warehouse, you must create a custom folder and make the changes in it. Do not change objects in any of the shipped folders unless explicitly directed by Oracle. This is because shipped folders and the objects within them may be overwritten in future upgrades. The shipped repository does not include any custom folders; you must create your own. You should create a custom folder for each SDE folder you have deployed that will have customizations. These folders hold the extract mappings to various sources. You should also create a separate custom folder for the customizations that you want to make to the SILOS folder. Do not store customized extract and load mappings in the same folder. The easiest way to modify an object is to copy an existing object from the shipped folder into the corresponding custom folder and to reuse existing business components, source and target definitions, transformations, mapplets, and mappings.
Copy existing objects from the shipped folders into the corresponding custom folders. Reuse existing business components, source and target definitions, transformations, mapplets, and mappings.
Type II Customization: Custom Workflows

Create custom workflows for all customized mappings. Each workflow should load only one table. The workflow name should match a session name that is used inside the workflow. Set the appropriate source and target connection values in the Informatica Designer. Register workflows in the DAC.
Type II Customization: Custom Workflows This slide highlights some of the high-level steps needed to create custom workflows. This topic is covered in more depth in the lesson titled Adding a New Dimension in the Oracle Business Analytics Warehouse.
Additional Customization Considerations

Table definitions in the Informatica Update strategy ETL process Truncation of target tables ETL_PROC_WID DATASOURCE_NUM_ID Indices creation Naming conventions The configuration of the DAC
Additional Customization Considerations As stated earlier, all custom work must be done in custom folders so that the custom work can be preserved during an Informatica repository upgrade. Doing work on the standard folder should be avoided whenever possible. An upgrade of the Informatica repository overrides any changes to the standard folder. The additional customization considerations listed in this slide are presented in detail in the slides that follow.
Table Definitions in Oracle Format

By default, table definitions are set to Oracle in the Informatica repository. Set SQL style to Oracle when importing new table definitions from external data sources regardless of the database type.
If SQL style is not set to Oracle, the mappings that use table definitions will be invalid.
Table Definitions in Oracle Format Make sure that the SQL style is set to Oracle while importing the table definitions from external data sources. Even if the actual data source is of another database type, such as DB2 or MSSQL, it does not affect the logic of how data gets loaded.
Used by the Informatica to interpret at run time what the data types are going to be, depending on the source and target specified in the session properties Does not affect behavior of mappings or logic of how data is loaded; database types get converted appropriately
Update Strategy
Design a custom process to detect new and modified records. The process should be designed to load only incremental data. If data is loaded without an incremental process, the previously loaded data will be updated again. Example logic in standard SIL mappings:
1. Mapping looks up destination tables based on INTEGRATION _ID and DATASOURCE_NUM_ID. 2. If the combination exists, ROW_WID is returned and the record is updated. 3. If the combination does not exist, lookup returns NULL and a record is inserted.
Update Strategy For loading new fact and dimension tables, design a custom process on the source side to detect the new and modified records. The SDE process should be designed to load only the changed data (new and modified). If the data is loaded without the incremental process, the data that was previously loaded will be updated again, which is a costly process. For example, the logic in the shipped SIL mappings looks up the destination tables based on INTEGRATION_ID and DATASOURCE_NUM_ID, and returns ROW_WID if the combination exists, in which case it updates the record. If the lookup returns null, it inserts the record instead. In some cases, the last update date stored in the target tables is also compared to the columns mentioned above to determine insert or update. Look at the similar mappings in the shipped folders for more details.
ETL Process
When using multiple sources for the data warehouse, you can decide to load from all of them at the same time, or at different time frequencies using different execution plans.
Truncating Target Tables

Truncating should be done through the DAC. A single DAC task has one placeholder for a full load, and one for an incremental load. Truncate target tables based on the following guidelines:
SDE Session Full ETL Incremental ETL Truncate Truncate
SIL Session Truncate Do not truncate
Truncating Target Tables Truncating should be done through the DAC. A single task has one placeholder for a full load, and one for an incremental load. For the SDE workflows, the commands for a full load and an incremental load are the same. They should have the Truncate Always flag selected in the DAC. For these kinds of tasks, the command for a full load and an incremental load are based on the same mapping. For SIL workflows, the command can be different for full and incremental loads. They should have the Truncate For Full Load option selected in the DAC. When a table gets truncated, the indices are dropped and created after the data is loaded. The workflow associated with the full load command can have the Bulk Load option turned on for an optimized version of the mapping that quickly inserts data. Note that if there are indices on the table, the bulk load may fail, so it is very important that the indices are registered in the DAC and that you drop all the indices on this table during a full load, if you use the Bulk Load option.
ETL_PROC_WID
Is a foreign key to the W_ETL_RUN_S table, which maintains the history of the ETL process To use the same ETL_PROC_WID, copy reusable lookup LKP_ETL_PROC_WID to the mapping; the input to lookup is a constant (hard coded to 1).
ETL_PROC_WID Use the same ETL_PROC_WID in the W_PARAM_G table in custom mappings. ETL_PROC_WID is a reference key to Run History in the DAC. To use the same ETL_PROC_WID, copy the reusable lookup (called LKP_ETL_PROC_WID) defined in the SILOS folder. The input to the lookup is a constant (hard coded to 1).
DATASOURCE_NUM_ID
Use a parameter to define this value in the mapping. The DAC will create a parameter file with the correct DATASOURCE_NUM_ID, which will be picked up by the parameter in the mapping.
DATASOURCE_NUM_ID Use a parameter to define this value in the mapping. The DAC will create a parameter file with the correct DATASOURCE_NUM_ID, which will be picked up by the parameter in the mapping. This enables you to make multiple copies of the same mapping when you have multiple instances of the same transactional database type. You do not have to do any additional hard coding other than to register the sources in the DAC.
Creating Indices
Staging tables typically do not require indices. Create indices on all columns that the ETL uses for dimensions and facts, for example:
ROW_WIDs of dimensions and facts INTEGRATION_ID DATASOURCE_NUM_ID Flags
Carefully consider on which columns to put filter conditions. Define indices to improve query performance.
Inspect standard repository objects for guidance.
Register new indices in the DAC.

The DAC server drops and re-creates indices during a full load.
Creating Indices Staging tables typically do not require any indices. Use care to determine whether indices are required on staging tables. Create indexes on all the columns that the ETL will use for dimensions and facts (for example, ROW_WIDs of Dimensions and Facts, INTEGRATION_ID and DATASRC_NUM_ID, and flags). Carefully consider the columns or combination of columns on which the filter conditions should exist, and define indices to improve query performance. Inspect the shipped objects for guidance. After the indices are decided upon, they should be registered in the DAC, either manually or by right-clicking the appropriate table and invoking the Import Indices command.
Naming Conventions
Name all the newly created tables with the prefix WC_.
This helps to visually isolate the new tables from the shipped tables.
Keep good documentation of the customizations done.

This helps when upgrading your data warehouse.
Naming Conventions Name all the newly created tables with the prefix WC_. This helps visually isolate the new tables from the shipped tables. Keep good documentation of the customizations done; this helps when upgrading your data warehouse.
Configuring DAC
Customization changes must be registered in the DAC: Table, column, and index definitions Workflows Custom folders
Configuring the DAC After making these changes to the mappings, you need to register the changes in the DAC. You need to include the table definition, with any additional columns or indices, and the required changes, so the tasks execute the modified sessions in the new custom folders. Details about registering changes to data warehouse objects in the DAC are discussed in the lessons titled Adding Columns to an Existing Dimension Table and Adding a New Dimension in OBAW.
Summary
In this lesson, you should have learned how to: Identify and describe customization types and scenarios associated with the Oracle Business Analytics Warehouse (OBAW) Apply the OBAW customization best practices
Adding Columns to an Existing Dimension Table

Objectives
After completing this lesson, you should be able to: Complete the steps in a Type I customization of the Oracle Business Analytics Warehouse (OBAW) Add a column to an existing dimension table in the OBAW and populate it with data
Type I Customization: Adding Columns to Existing Tables

In a Type I customization, you add additional columns (that are already mapped) from a source system and load the data into existing data warehouse tables.
Type I Customization: Adding Columns to Existing Tables A Type I customization is one of the three customization types that were initially presented in the lesson titled Customizing Oracle Business Analytics Warehouse. Customizations are categorized based on the data source (packaged or nonpackaged) and the desired OBAW modification (additional columns, tables, or rows). Type I customizations involve extracting additional columns from source systems that are already mapped and loading the data into existing data warehouse tables.
Type I Customization Scenario

Extracting data from a column in a table in a transactional database and loading it into a column in a dimension table in the OBAW Example:
Use the HZ_CUST_ACCOUNTS .ATTRIBUTE5 field in a transactional database to capture data related to ACCOUNT_LOG. Load the data into W_ORG_D.X_ACCOUNT_LOG in the data warehouse.
OLTP HZ_CUST_ACCOUNTS ATTRIBUTE5 OBAW W_ORG_DS X_ACCOUNT_LOG OBAW W_ORG_D X_ACCOUNT_LOG
Type I Customization Scenario This slide presents a scenario for a Type I customization where data is extracted from a table in a transactional database and loaded into a column in a dimension table in the Oracle Business Analytics Warehouse. This scenario is used throughout the lesson and practices.
Type I Customization Steps

1. Create custom Source Dependent Extract (SDE) and Source Independent Load (SIL) folders in the Informatica. 2. Copy SDE and SIL mappings and workflows to custom folders. 3. Build custom SDE and SIL mappings. 4. Edit custom workflows. 5. Use the Data Warehouse Administration Console (DAC) to add new column objects to the data warehouse. 6. Register custom folders in the DAC. 7. Modify existing DAC tasks to use custom mappings and workflows. 8. Create a custom subject area in the DAC. 9. Create and run a custom execution plan in the DAC.
Type I Customization Steps This slide lists the steps to perform a Type I customization. Each step is presented in detail in the slides that follow.
Step 1: Creating Custom SDE and SIL Folders in Informatica

Open the Informatica Repository Manager and select Folder > Create to create custom SDE and SIL folders.
Step 1: Creating Custom SDE and SIL Folders in Informatica If you want to make changes to the Oracle Business Analytics Warehouse, you must create a custom folder and make the changes in it. Do not change objects in any of the shipped folders unless explicitly directed by Oracle. This is because shipped folders and the objects within them may be overwritten in future upgrades. The shipped repository does not include any custom folders; you must create your own. You should create a custom folder for each SDE folder you have deployed that will have customizations. These folders hold the extract mappings to various sources. You should also create a separate custom folder for customizations that you want to make to the SILOS folder. Do not store customized extract and load mappings in the same folder. The easiest way to modify an object is to copy an existing object from the shipped folder into the corresponding custom folder and to reuse existing business components, source and target definitions, transformations, mapplets, and mappings.
Custom SDE and SIL folders
Step 2: Copying SDE and SIL Mappings and Workflows to Custom Folders
Copy shipped SDE and SIL mappings and workflows from existing folders to custom folders.
Copy mapping to custom folder.
Step 2: Copying SDE and SIL Mappings and Workflows to Custom Folders After you have identified the mappings that you want to use for the customization, copy the mappings and corresponding workflows to the appropriate custom folders.
Step 3: Building Custom SDE and SIL Mappings

Modify the copied mappings by following the safe path marked by the X_CUSTOM placeholder.
X_CUSTOM expression
New column New column
X_CUSTOM placeholder
Step 3: Building Custom SDE and SIL Mappings Most mappings have a single placeholder column named X_CUSTOM, which marks a safe path through the mapping. All extension logic should follow the same route through the mapping as X_CUSTOM. You can add additional transformations to the mapping, but they should follow the same route through the mapping as X_CUSTOM. As a best practice, rename the port in the X_CUSTOM expression to indicate both the table and column it comes from, HZ_CUST_ACCOUNTS_ATTRIBUTE5 in this example. If the mapping is changed and the related exposed objects are replaced, this will make it easier to reconnect, because the custom expression will not be replaced.
Step 4: Editing Workflows

Verify workflow session connection parameters. Rename log and parameter file for easier identification.
Rename Rename
Verify connection parameters.
Step 4: Editing Workflows Verify workflow session connection parameters. The variable names for the source and target correlate in the DAC-generated parameter file with execution plan parameters, which by default are set to $$DBConnection_OLTP for the transactional (source) connection and $$DBConnection_OLAP for the data warehouse (target) connection. Rename session log and parameter file names so that they are easier to identify.
Step 5: Using DAC to Add New Column Objects to Data Warehouse

Add columns to the dimension staging table and the dimension table in the DAC design view. Run Tools > ETL Management > Configure to create column objects for physical tables in the data warehouse.
Dimension staging table
Added column
Step 5: Using DAC to Add New Column Objects to Data Warehouse When you build the custom SDE and SIL mappings, you add the new column to the tables in the mappings. Then you must add this new column object to the data warehouse. There are two methods for adding a new object to the data warehouse. One method is to use the DACs Data Warehouse Configurator to create the physical columns for the tables in the data warehouse database. The other method is to add the column definitions directly in the data warehouse database, and then use the DACs Import from Database command to add the new columns in the DAC. This slide illustrates the first method. It is assumed that a custom container exists.
Step 6: Registering Custom Folders in DAC

Select Tools > Seed Data > Task Folders to create custom logical and physical task folders for the custom folders that you created in the Informatica repository.
Select Design > Source System Folders to register the new custom folders in the DAC.
Step 6: Registering Custom Folders in DAC You need to perform this step for all new workflows that you create in the Informatica and for all workflows that you modify. First, in the DAC toolbar, select the appropriate source system container from the list. Next, navigate to Tools > Seed Data > Task Folders and create custom logical and physical task folders for the custom folders that you created in the Informatica repository. Finally, navigate to Design > Source System Folders and register the custom folders in the DAC.
Step 7: Modifying Existing DAC Tasks to Use Custom Mappings and Workflows
Navigate to shipped tasks and change folder names to custom folder names, and then synchronize tasks. When the execution plan is run, tasks will use mappings and workflows in custom INFA folders.
Cloned task
Custom folder
Step 7: Modifying Existing DAC Tasks to Use Custom Mappings and Workflows After you register the custom folders in the DAC, you can either create new DAC tasks for the custom mappings and workflows, or modify existing DAC tasks to use the custom mappings and workflows. In the example in the slide, existing tasks are modified to point to the custom folders. When the execution plan is run, the tasks will use the mappings and workflows in the custom Informatica folders.
Step 8: Creating a Custom Subject Area in DAC

Use known techniques to create and assemble a custom subject area.
Custom subject area
Dimension table
Step 8: Creating a Custom Subject Area in DAC You can either create and assemble a new custom subject area or modify an existing custom subject area. In this example, a custom subject area is created and assembled based on the W_ORG_D dimension table.
Step 9: Creating and Running a Custom Execution Plan in DAC

Use known techniques to create, build, run, and monitor a custom execution plan in the DAC.
Custom execution plan
Customized tasks
Custom folders
Step 9: Creating and Running a Custom Execution Plan in DAC Use known techniques to create, build, run, and monitor a custom execution plan. In this example, the custom execution plan named Custom Organization Dimension includes two customized SDE and SIL tasks that point to the custom SDE and SIL folders, respectively.
Verifying Results
Use a SQL tool to verify results.
Verifying Results Use a SQL tool to verify results. This example verifies the results used in the scenario for this lesson and confirms that data was loaded into the X_ACCOUNT_LOG column in the W_ORG_D dimension table.
Summary
In this lesson, you should have learned how to: Complete the steps in a Type I customization of the Oracle Business Analytics Warehouse (OBAW) Add a column to an existing dimension table in the OBAW and populate it with data
Practice 13-1: Creating a Custom SDE Mapping

This practice covers creating an SDE mapping that can be used to move data from a column in a source system into the W_ORG_DS staging extension table in preparation for load into the W_ORG_D table in the data warehouse.
Practice 13-2: Creating a Custom SIL Mapping

This practice covers creating an SIL mapping that can be used to move data into the W_ORG_D table from the W_ORG_DS staging table.
Practice 13-3: Adding DAC Tasks and Running Customized ETL

This practice covers configuring the DAC to extract data from the source and load it into the custom column in the data warehouse.
Adding a New Dimension in OBAW

Objective
After completing this lesson, you should be able to perform the customization steps for adding a new dimension to the Oracle Business Analytics Warehouse.
Type II Customization: Adding Additional Tables

In a Type II customization, you use prepackaged adaptors to add new fact or dimension tables to the data warehouse, regardless of whether they are already mapped. Type II customizations typically require that you build new Source Dependent Extract (SDE) and Source Independent Load (SIL) mappings.
Type II Customization: Adding Additional Tables A Type II customization is one of the three customization types that were initially presented in the lesson titled Customizing Oracle Business Analytics Warehouse. Customizations are categorized based on data source (packaged or nonpackaged) and the desired OBAW modification (additional columns, tables, or rows).
Type II Customization Scenario

Add a new dimension table and dimension staging table to the OBAW. Extract and load data from a nonpackaged source. Example:
Build new WC_PARTNER_D and WC_PARTNER_DS tables in the data warehouse. Extract data from a spreadsheet.
CSV PARTNER DATA PARTNER_NAME PARTNER_LOC OBAW WC_PARTNER_DS PARTNER_NAME PARTNER_LOC OBAW WC_PARTNER_D PARTNER_NAME PARTNER_LOC
Type II Customization Scenario This slide presents a scenario for a Type II customization where data is extracted from a spreadsheet and ultimately loaded into columns in a new dimension table in the Oracle Business Analytics Warehouse. This scenario is used throughout the lesson and practices.
Type II Customization Steps

** New steps
Type II Customization Steps The steps for a Type II customization are fundamentally the same as those for a Type I customization. The new steps are identified in the list and are presented in the slides that follow. It is assumed that you are familiar with the remaining steps. They are covered in the practices, but not in the slides.
1. Run data definition language (DDL) script to create new tables.** 2. Register new tables in the Data Warehouse Administration Console (DAC) .** 3. Set table properties.** 4. Import table columns.** 5. Add a foreign key column to a fact table.** 6. Create custom SDE and SIL folders in the Informatica. 7. Build custom SDE and SIL mappings and workflows. 8. Register custom folders in the DAC. 9. Build DAC tasks to use custom mappings. 10. Create a custom subject area in the DAC. 11. Create and run a custom execution plan in the DAC.
Step 1: Creating and Running DDL for New Tables

Create a DDL for the new dimension based on the standard structure (with appropriate system columns). Create a staging table for this dimension.
Step 1: Creating and Running DDL for New Tables Create and run a DDL for the new dimension and dimension staging table based on the standard structure (with appropriate system columns). As discussed in the lesson titled Adding Columns to an Existing Dimension Table, there are two alternative process flows for adding a new object to the data warehouse. You can enter table and column definitions in the DAC, and then use the DACs Data Warehouse Configurator to create the table and columns in the data warehouse database. Alternatively, you can add the new table and column definitions directly in the data warehouse database, and then use the DACs Import from Database command to add the new table and columns in the DAC. This lesson and the associated practices illustrate the second method, although the recommended best practice is to enter the table and column definitions in the DAC, and then use the DACs Data Warehouse Configurator to create the table and columns in the data warehouse database.
Step 2: Registering New Tables in DAC

Register the new source table and its staging table in the DAC repository and associate it with the appropriate database connection. 1. Select Design > Tables. 2. Select Tables > Import from database > Import Database Tables. 3. Read and import new tables.
Select data source. Filter tables.
Mark for import.
Step 2: Registering New Tables in DAC Register the new source table and its staging table (if it does not already exist) in the DAC repository and associate it with the appropriate database connection.
Step 3: Setting Table Properties

Set the appropriate table type for each new table. Set the Warehouse flag.
Table type
Warehouse flag
Step 4: Importing Table Columns

1. Right-click and select Import From Database > Import Database Columns. 2. Import columns. 3. Verify that column properties are accurate.
Custom table
Imported columns
Step 4: Importing Table Columns Import the table columns for the new tables. After import, verify that the columns are visible in the DAC and that all column properties are accurate.
Step 5: Adding a Foreign Key Column to the Fact Table

1. Add new columns to the fact and fact staging tables. 2. For the fact table, set the foreign key table and column. 3. Select Tools > ETL Management > Configure to create new columns for fact tables in the data warehouse.
Fact table
Foreign key
Foreign key to table
Foreign key to column
Completing the Remaining Steps

1. 2. 3. 4. 5. 6. Create custom SDE and SIL folders in the Informatica. Build custom SDE and SIL mappings and workflows. Register custom folders in the DAC. Build DAC tasks to use custom mappings. Create a custom subject area in the DAC. Create and run a custom execution plan in the DAC.
Completing the Remaining Steps Use known techniques to complete the remaining steps. These steps were covered in the previous lessons.
Summary
In this lesson, you should have learned how to perform the customization steps for adding a new dimension to the Oracle Business Analytics Warehouse.
Practice 14-1: Adding a New Dimension in OBAW

This practice covers the following topics: Creating a new dimension table and a new dimension staging table in the data warehouse Importing tables into the DAC Setting table properties in the DAC Importing table columns into the DAC Adding foreign key columns to a fact table
Practice 14-1: Adding a New Dimension in OBAW In this practice, you run a DDL script to create a new dimension table and dimension staging table based on the standard structure (with appropriate system columns). You then register the new source table and its staging table in the DAC repository and associate it with the appropriate database connection.
Practice 14-2: Creating an SDE Mapping to Load the Dimension Staging Table
This practice covers the following topics: Creating a new SDE mapping to load the dimension staging table Modifying workflows and sessions
Practice 14-2: Creating an SDE Mapping to Load the Dimension Staging Table In this practice, you use Informatica tools to create a new SDE mapping to load the new dimension staging table and then modify the corresponding workflow and session.
Practice 14-3: Creating an SIL Mapping to Load the Dimension Table

This practice covers the following topics: Creating a new SIL mapping to load the dimension table Modifying workflows and sessions
Practice 14-3: Creating an SIL Mapping to Load the Dimension Table In the previous practice, you created an SDE mapping to load the new dimension staging table. In this practice, you use Informatica tools to create a new SIL mapping to load the new dimension table and then modify the corresponding workflow and session.
Practice 14-4: Creating an SDE Mapping to Load the Fact Staging Table
This practice covers the following topics: Creating a new SDE mapping to load the fact staging table Modifying workflows and sessions
Practice 14-4: Creating an SDE Mapping to Load the Fact Staging Table In this practice, you use Informatica tools to create a new SDE mapping to load the fact staging table and then modify the corresponding workflow and session.
Practice 14-5: Creating an SIL Mapping to Load the Fact Table

This practice covers the following topics: Creating a new SIL mapping to load the fact table Modifying workflows and sessions
Practice 14-5: Creating an SIL Mapping to Load the Fact Table In the previous practice, you created an SDE mapping to load the fact staging table. In this practice, you use Informatica tools to create a new SIL mapping to load the fact table.
Practice 14-6: Adding DAC Tasks and Running Customized ETL

This practice covers the following topics: Creating and synchronizing custom tasks in the DAC Creating a custom subject area Creating a custom execution plan Monitoring the ETL plan execution Verifying data
Practice 14-6: Adding DAC Tasks and Running Customized ETL In the previous practices, you built the sessions and workflows in the Informatica Workflow Manager to run the SDE and SIL mappings. Now you create DAC tasks and add them to custom subject areas and execution plans that can be used to run the ETL.
Integrating Security for Oracle Business Intelligence Applications

Objectives
After completing this lesson, you should be able to: Describe types of security in Oracle Business Intelligence Applications Synchronize Oracle BI Application user groups with EBS responsibilities Explain how BI Application authorization integrates with EBS responsibilities Describe a typical data security integration
Oracle BI Security Options

User security
It provides the ability to authenticate users through logon. In an integrated environment, users should be defined in EBS or LDAP.
Object security
Data security
It controls user access to data.
Oracle BI Security Options User authentication provides confirmation of the identity of a user based on the credentials provided. Object security controls the visibility of business logical objects defined in the metadata repository (for example, subject areas, Presentation tables, and so on) and Web objects defined in the Presentation Catalog (for example, dashboards, Answers requests, and so on) based on a users role, for example Financial Analyst. Data security controls the visibility of data (content rendered in subject areas, dashboards, and Answers) based on the users association with data in the transactional system. An example is Ledger-based security.
It secures access control on objects using the BI Server and Presentation Catalog user groups. In an integrated environment, groups should be synchronized with EBS Responsibilities.
Oracle BI Application Security

Oracle BI Applications aligns a users security profile with those in the source transactional applications. Users are created in the EBS database or LDAP. BI Applications security groups are synchronized with Oracle EBS Responsibilities.
1.
Covered in this lesson
Create security groups in the BI Applications repository and Presentation Catalog.
Match Responsibilities in the Oracle EBS application. Names match object security groups in BI Applications. You assign EBS users to the new groups.
2.
Create and assign new Responsibilities in Oracle EBS.

Oracle BI Application Security For integration between the Oracle BI Applications and Oracle EBS to work, you must synchronize the names of the Oracle BI security groups with the names of the EBS responsibilities. After the groups and responsibilities are correlated, BI Applications is integrated with EBS.
Two approaches:
Security Manager
Is a utility in the Oracle BI Administration Tool Displays all the security information for a repository Is used to implement BI Server security groups that control data and object security
Security Manager The Security Manager displays all the security information for a repository. You can use the Security Manager to configure users and groups, synchronize Lightweight Directory Access Protocol (LDAP) users and groups, set access privileges for objects such as tables and columns, set filters on information, and set up a managed query environment in which you have control over when users can access data.
Synchronizing BI Server Groups

Use Security Manager to create groups with the same names as EBS application responsibilities.
Groups
Users and groups can belong to a group.
Working with Groups Oracle BI Server allows you to create groups and then grant membership in them to users or other groups. You can think of a group as a set of security attributes. Oracle BI Server groups are similar to groups in Windows NT and Windows 2000, and to groups or roles in database management systems (DBMS). Like Windows NT and Windows 2000, and database groups or roles, Oracle BI Server groups can allow access to objects. Additionally, Oracle BI Server groups can explicitly deny particular security attributes to their members. Groups can simplify the administration of large numbers of users. You can grant or deny sets of privileges to a group and then assign membership in that group to individual users. Any subsequent modifications to that group affect all users who belong to it. Externally defined users can be granted group membership by use of the GROUP session variable, which is discussed later in this lesson.
Oracle BI Presentation Services Administration Page

It is used to manage Presentation Catalog groups and users and account (user and group) privileges. Members of an Oracle BI Server security group are automatically members of corresponding Presentation groups with the same name.
Synchronizing Presentation Catalog Groups

Create Presentation Catalog groups with the same names as BI Server security groups.
1
Edit group
Delete group
Managing Presentation Catalog Groups and Users Presentation Catalog groups are defined by the system or by an administrator. When a user is assigned to a group, the user becomes a member of that group. Presentation Catalog group membership is used to determine the permissions and privileges that are associated with a user, by either explicit assignment or inheritance. Presentation Catalog groups can also be thought of as roles for users because there is no ambiguity about which defaults, preferences, and so on to assign directly to a user. 1. Click Manage Presentation Catalog Groups and Users to create, edit, and delete groups and to add and remove users. 2. Click Create a new Catalog Group. - Authentication is performed by the Oracle BI Server. - Users with a valid server ID are created as Web Users when they log in. - System-defined Presentation Catalog Groups and Users cannot be removed. 3. Click Finished.
Authorization
Manages object security integration Retrieves user responsibilities from EBS applications, matches them with BI security groups
Performed by the Authorization initialization block Result stored in the GROUP session variable
Authorization When a session is started on the BI Application in an integrated EBS environment, the Authorization initialization block retrieves the users responsibilities from the EBS applications and matches the result with synchronized BI Server and Presentation Catalog security groups, storing the relevant groups in the GROUP session variable. These user groups then determine the appropriate repository and Web object security for the duration of the session.
Determines applicable BI object security during a user session
Data Security Integration

Is supported for different EBS security models, including: Covered in Ledger this lesson Operating Unit Inventory Organization Company Org Business Group Org Human Resources Org Human Resource Personnel Data Analyst Employee
Data Security Integration Data security integration with EBS is supported for a number of different security models in EBS. This lesson uses the Ledger security integration as an example to demonstrate some of the typical steps that are followed to maintain data security between EBS and Oracle BI Applications. For more information on other specific security models, refer to the Oracle Business Intelligence Applications Fusion Edition Installation and Configuration Guide.
Ledger Data Security in Oracle EBS

A ledger in EBS determines:
Currency Chart of accounts Accounting calendar Ledger processing options Subledger accounting method
The data access set assigned to a users responsibility controls what ledgers they can access. The Ledger-based security filters data based on the ledgers associated to the logged-in user.
Ledger Security in Oracle BI Applications

The Ledger integration is implemented using initialization blocks and variables, which retrieve and store information about integration and ledger security.
Ledger Security: USER System Variable

The USER system variable is set automatically when a user logs in to Oracle Business Intelligence Enterprise Edition.
Ledger Security: EBS Single Sign-On Integration Session Variable

The EBS Single Sign-on Integration session variable is initialized with one of two possible values, indicating SSO integration with EBS: Integrated Not Integrated
Initialized by the EBS Single Sign-on Integration initialization block
Ledger Security: EBS Security Context Initialization Block

The EBS Security Context initialization block populates two session variables. The OLTP_EBS_RESP_ID session variable is initialized with the responsibility of the user session in Oracle EBS. The OLTP_EBS_RESP_APPL_ID session variable is initialized with the responsibility of the user session in Oracle EBS. If there is no SSO integration, the variables are defaulted to random values and ignored.
Queries the EBS tables
Ledger Security: Ledgers Initialization Block

The Ledgers initialization block uses information from the session variables to retrieve the ledgers corresponding to the user. Accesses the FND_USER_RESP_GROUPS table in the EBS transactional database using the FND_PROFILE procedure Populates the LEDGER variable
Ledgers Initialization Block If you are running BI applications against Oracle EBS 11i, you need to modify the SQL for the initialization block. The repository file shipped with Oracle Business Intelligence Applications is configured to retrieve the ledger information from EBS Release 12. For more information, refer to the Oracle Business Intelligence Applications Fusion Edition Installation and Configuration Guide.
Summary
In this lesson, you should have learned how to: Describe the types of security in Oracle Business Intelligence Applications Synchronize the Oracle BI Application user groups with EBS responsibilities Explain how BI Application authorization integrates with EBS responsibilities Describe a typical data security integration
Managing OBAW Performance

Objectives
After completing this lesson, you should be able to: Describe strategies for increasing extract, transform, and load (ETL) and query performance Identify common performance bottlenecks Configure servers to optimize ETL and query performance
Maximizing the OBAW Performance

OBAW performance tuning is a balancing act involving hardware, transactional schema, and OBAW schema.
Indices can improve query performance but could slow down ETL.
OBAW schema
Indices, aggregates, subdimensions, denormalized tables
Adding database or ETL server hardware resources comes at a relatively large cost.
ETL and query performance
Hardware
Processors, memory, storage, network
Transactional schema
Normalized tables, indices
Maximizing the OBAW Performance This slide illustrates that performance tuning is a balancing act involving hardware, transactional schema, and the OBAW schema design. All three points of the performance triangle can be bottlenecks, and performance enhancement in one area can have an impact on the performance of another area. In this lesson, recommendations are for balancing the needs of query and extract, transform, and load (ETL) performance. However, real-world usage patterns and ETL scheduling may influence further testing and tuning. For example, creating indices on frequently queried tables can improve query performance, but there is a trade-off during ETL, when additional processing will be required to update the additional indices.
Common Performance Bottlenecks

Common performance bottlenecks involve ETL and queries.
Reads from transactional source
Writes to OBAW
OBAW queries
Transactional DB
Informatica server (ETL)
OBAW
Oracle BI server
DAC client
DAC server
Common Performance Bottlenecks This is a high-level overview of the three areas where bottlenecks occur. Bottlenecks can entail transactional or OBAW schema issues (for example, index usage) or hardware issues (for example, number of processors, degree of parallelism, or I/O subsystems).
Performance Overview
ETL and query performance enhancement can be broadly classified into four areas: Informatica server throughput
Informatica servers ability to process ETL routines
Database server throughput

Data access for extracts from and queries of transactional databases Processing of loads and queries
Hardware utilization and throughput

Optimize use of available CPUs. Optimize network I/Os.
Data volume
During ETL, number of rows updated and inserted since the last load During queries, amount of data retrieved
Performance Overview ETL and query performance enhancement can be broadly classified into four areas: Informatica server throughput, database server throughput, hardware utilization and throughput, and data volume. Only Informatica server and database server throughputs are discussed in depth in the subsequent slides. Hardware throughput and data volume considerations are beyond the scope of this course.
Informatica Server Throughput

Informatica server is the brain of the ETL process.
Manages how commands are grouped and issued to the database server Manages error handling, scheduling, and notification in the ETL process
Management of ETL processing enhances performance.
Minimize ETL to the required star schemas.
Adjust Informatica server parameters.
Informatica Server Throughput Informatica server throughput is affected by a number of issues. ETL configuration, as discussed in the lesson titled Configuring Oracle Business Analytics Warehouse, is the best way to maximize performance in this area. Recommendations for the Informatica server parameters are provided later in this lesson.
Configure the Full and Refresh ETL processes.
ETL Parallel Processing

Register one or more Informatica servers in the DAC:
Use the Informatica servers tab in the Setup view. Set Maximum Sessions to the number of tasks that can be run in parallel on the Informatica server.
Approximately one session per CPU
ETL Parallel Processing ETL parallel processing is another method for improving performance. In the DAC, you can register additional available Informatica servers, which will be load-balanced by the DAC server during ETL execution.
The DAC server load balances tasks across registered Informatica servers.
ETL Parallel Processing: Example

Example: Tasks that load dimension staging tables can be run in parallel.
The DAC server queues tasks with the Extract Dimension phase across available Informatica servers.
Approximately one session can be run per CPU.

A server with four CPUs can run approximately four tasks in parallel. A server with eight CPUs can run approximately eight tasks in parallel.
ETL Performance Troubleshooting

Determine the source or target bottleneck. ETL session diagnostics include:
Processor and memory utilization
Measured using operating system utilities
Throughput the amount of data extracted, transformed, and loaded
Check session logs:
Execution time for the whole session
Turn on performance monitoring for a session in Workflow Manager.

Performance counters can be used to determine bottlenecks. The result is available while the session runs.
Also placed in a <session>.perf file
ETL Performance Troubleshooting This slide identifies some diagnostics that you can use to troubleshoot ETL performance issues. These diagnostics can be obtained from the DAC server and task logs, as well as from the Informatica session logs.
Comparison by session of rows per second processed can identify problem sessions.
ETL Performance Leading Practices

Make sure that underlying systems are running optimally before tuning sessions: Multiprocessor (SMP) systems Memory Disks Network links OS memory management Native ODBC drivers Database server configuration
ETL Performance Leading Practices This and the following slides summarize areas to consider in performance tuning. Recall the performance triangle earlier in the module. The main point of this slide goes back to the performance triangle, where it is highlighted that hardware and I/O subsystems can have a dramatic effect on performance. The bulleted list here provides a checklist of the system components that can be optimized before making dramatic changes to the OBAW or the transactional schema and should be considered while assessing the ETL performance.
OBAW Database Server Throughput

The database server is the muscle of the ETL process.
It processes commands from the Informatica server to read, transform, and write data. Data storage is a critical performance variable.

Database configuration and schema management dramatically affect the performance of ETL and queries.
Create relevant indices. Drop and re-create indices. Partition large fact tables. Ensure that database server parameters are optimal. Enable bulk loading.
OBAW Database Server Throughput This slide lists the general concerns and guidelines for maximizing RDBMS performance for ETL and queries. Of particular significance are the recommendations for data storage. Partitioning large tables (facts are good candidates), enabling parallel processing, and the use of RAID can reduce I/O bottlenecks. Creating relevant indices can greatly improve query performance for certain tables and columns. However, the trade-off here is in the maintenance of the indices during large-scale updates and inserts required during ETL. Remember that indices are dropped and re-created during ETL by DAC. For recommendations on database server parameters, consult your RDBMS documentation. For Oracle parameters and guidelines, consult the Oracle Database 10g page on the Oracle Technology Network. For further training, take the Oracle Database 10g: Performance Tuning course.
Spread data across multiple disks. RAID (Redundant Array of Independent Disks) configuration can offer significant benefits.
OBAW Database: Indices

Update indices for faster access during ETL and queries. Create indices to speed up read (extract) operations.
Example:

Create indices on relevant image tables to speed up access. Note that this entails a performance trade-off.
Drop indices to speed up write (load) operations.

Add multicolumn indices to improve SQL performance.
OBAW Database: Indices This slide examines database server index management in greater detail. Dropping and recreating indices ensures that they are accurate and provide the most direct path to data during queries. Again, remember the ETL trade-off, which drives the recommendation to drop indices to speed up writes.
Transactional systems performance is degraded due to necessary index updates during inserts and updates on transactional data.
OBAW Database: Optimizer Statistics

Use a rule-based optimizer during the Full ETL process. Use a cost-based optimizer for querying.
A cost-based optimizer chooses an optimal execution plan based on historical costs.
Update database statistics to enhance query performance.
OBAW Database: Optimizer Statistics This slide presents guidelines for increasing the performance of the database optimizer during querying and ETL. The optimizer determines the best way to perform the required reads or writes based on a variety of statistics. Queries are best executed using the cost-based optimizer, which uses historical metadata about query execution to determine the best query plan. The optimizer uses database statistics to make decisions that impact query execution plans. When a table or index is created, dropped, or grows significantly (as during ETL execution), out-of-date database statistics can have an adverse affect on query performance. If you set the Analyze Tables DAC system property to True, the DAC server updates statistics.
Set the Analyze Tables DAC system property to True.
OBAW Database: Aggregate and Subdimension Tables

Add aggregate tables.
The query profile should drive aggregate table candidates.
Add additional subdimension tables.

Warehouse contains some dimension tables that combine many separate logical entities.
Improve query performance by directing queries to a logical and physical subset of the original dimension table.
Use usage dashboards generated by the Oracle BI server to determine queries that require aggregates or are slow running.
OBAW Database: Aggregate and Subdimension Tables This slide describes the possible benefits of adding new tables to the OBAW schema to improve query performance. Aggregate and subdimension tables can isolate frequently queried data, thereby increasing query performance.
For example, the Person dimension (W_PERSON_D) includes contacts, employees, and prospects.
Aggregate Tables: Examples

The base fact table W_REVF_F contains detailed revenue measures at the product level. The aggregate table W_PLREVN_OP_A summarizes revenue measures across product lines; a product line consists of multiple products.
Aggregate Tables: Examples This slide provides an example where query performance is increased through the addition of a Product Line Revenue Aggregate table.
Subdimension Tables: Examples

The Person dimension contains 2,000,000 rows, but only 5,000 employees. Significant query advantage can be achieved by:
Creating a subset employee table Mapping metadata to the employee table instead of W_PERSON_D for queries involving employees
The OBAW includes several subdimension tables.

With BI server metadata mapped to these tables, significant performance benefits accrue.
Subdimension Tables: Examples This slide provides an example where query performance is increased through the addition of an Employee subdimension.
Summary
In this lesson, you should have learned how to: Describe strategies for increasing ETL and query performance Identify common performance bottlenecks Configure servers to optimize ETL and query performance
Exploring the Date Dimension

Date Dimension
Is one of the most important dimensions in the Oracle Business Analytics Warehouse (OBAW) Represents the date and contains one row for each day Contains a wide range of date attributes Includes fiscal date values to support a broad range of fact analysis by the customers fiscal dates
For example, FSCL_MONTH, FSCL_QTR, and FSCL_YEAR
Is populated in advance with 30 years worth of data about the date
Oracle BI Applications 7.9: Implementation for Oracle EBS A - 2
W_DAY_D
Is the base date dimension table in the OBAW Is populated during the full ETL load.
It is not updated during the incremental ETL load.
The start and end dates correspond to 10 years worth of data.
Table name
Star Schema with Date Dimension: Example

The Start Date and End Date attributes of the Agreement Fact star schema are based on the date dimension in the OBAW.
Source System Parameters

Are used to build the date dimension table in the OBAW Define the start and end date range to populate the date dimension
Analysis Start Date: The default value is Jan 1, 1980. Analysis End Date: The default value is Dec 31, 2010.
Are customized for each container to load a custom set of date dimension values with a different start and end date range
Considerations
A full ETL load needs to be performed after the configuration.
The W_DAY_D table is not updated during the incremental ETL load.
Decreasing the analysis start or end dates can make the existing facts useless.
Considerations For more information about setting up the time dimension in the OBAW, refer to the Oracle Business Intelligence Applications Installation and Configuration Guide and the Oracle Business Intelligence Data Warehouse Console Administration Guide.
The data warehouse needs to be reset to perform the full ETL load. The new expanded start and end dates should be the superset of the previous date range in the OBAW.

BI Apps Training Student Guide

Enviado por

Dados do documento

Descrição original:

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

BI Apps Training Student Guide

Enviado por

Direitos autorais:

Formatos disponíveis

Oracle BI Applications 7.

9: Implementation for Oracle EBS

D55409GC11 Edition 1.1 February 2010 D65505

Oracle Internal & Oracle Academy Use Only

Technical Contr ibutor s and Reviewer s

Oracle Internal & Oracle Academy Use Only

Oracle Internal & Oracle Academy Use Only

Oracle Internal & Oracle Academy Use Only

Oracle Internal & Oracle Academy Use Only

Oracle Internal & Oracle Academy Use Only

Oracle Internal & Oracle Academy Use Only

Oracle Internal & Oracle Academy Use Only

Oracle Internal & Oracle Academy Use Only

Oracle Internal & Oracle Academy Use Only

Oracle Internal & Oracle Academy Use Only

Oracle Internal & Oracle Academy Use Only

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Oracle BI Applications 7.9: Implementation for Oracle EBS I - 2

Oracle Internal & Oracle Academy Use Only

Audience Prerequisites Goal Objectives Methodology Materials Agenda

Instructor and Class Participants

What is your prior experience?

How do you expect to benefit from this course?

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Oracle BI Applications 7.9: Implementation for Oracle EBS I - 3

Oracle Internal & Oracle Academy Use Only

Business intelligence Data warehouse design Database design

Training Site Information

Class duration and breaks

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Oracle BI Applications 7.9: Implementation for Oracle EBS I - 4

Oracle Internal & Oracle Academy Use Only

Meals and refreshments

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Oracle BI Applications 7.9: Implementation for Oracle EBS I - 5

Oracle Internal & Oracle Academy Use Only

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Oracle BI Applications 7.9: Implementation for Oracle EBS I - 6

Oracle Internal & Oracle Academy Use Only

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Oracle BI Applications 7.9: Implementation for Oracle EBS I - 7

Oracle Internal & Oracle Academy Use Only

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Oracle BI Applications 7.9: Implementation for Oracle EBS I - 8

Oracle Internal & Oracle Academy Use Only

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Oracle BI Applications 7.9: Implementation for Oracle EBS I - 9

Oracle Internal & Oracle Academy Use Only

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Oracle BI Applications 7.9: Implementation for Oracle EBS I - 10

Oracle Internal & Oracle Academy Use Only

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Oracle BI Applications 7.9: Implementation for Oracle EBS I - 11

Oracle Internal & Oracle Academy Use Only

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Oracle BI Applications 7.9: Implementation for Oracle EBS I - 12

Oracle Internal & Oracle Academy Use Only

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Oracle BI Applications 7.9: Implementation for Oracle EBS I - 13

Oracle Internal & Oracle Academy Use Only

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Oracle BI Applications 7.9: Implementation for Oracle EBS I - 14