Informatica Standards.pptx

© Peak Indicators Limited

Oracle BI ApplicationsTechnical Bootcamp

Extending BI Applications

© Peak Indicators Limited 2

Agenda


Agenda

Understand the different types of customisations

Estimate the impact of a customisation

Implementation Approach Roles


Customisations


Customisations

Is the process by which the Oracle Business Analytics Warehouse tables and columns, custom extract, transform and load (ETL) mapping templates, are modified to accommodate new data for analysis.


Customisations in General Supported source systems are pre-built applications too BI Apps setup is always required (installation during Day1) Transactional Application Modifications

User Interface Data Model Extensions New entities (business components) Different relationships between business components Modified visibility rules Different authorisation/authentication

BI Applications Modifications Different reporting requirements (dashboards, navigation, requests) New KPIs or reporting entities based on existing ones Different hierarchies Different visibility rules New facts and/or dimensions (unsupported functionality) Additional source systems or data warehouses Change data capture logic


Customisation Scenarios

Customisation scenarios are categorised across data sources and modification types.


Customisation Scenarios

Category 1. In a Category 1 customisation, you add additional columns from source

systems that have pre-packaged adapters and load the data into existing data warehouse tables.

Category 2. In a Category 2 customisation, you use prepackaged adapters to add

new fact or dimension tables to the data warehouse. Category 2 customizations normally require that you build new SDE and SIL mappings.

Category 3. In a Category 3 customisation, you use the Universal adapter to load

data from sources that do not have pre-packaged adapters.


Upgrade Considerations

Follow the recommended customisation methodology to minimise the effort required to reapply customisations after an upgrade.


Type I Customisation: Adding Columns to Existing Tables

Type I customisations 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 Customisation: 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 pre-

configured mappings to include additional columns and load the data into existing tables. Always copy OOTB mappings first into a custom folder and modify

existing logic or columns in the custom mappings.


Type I Customisation: Safe Path

Most mappings have a single placeholder column, named X_CUSTOM, that 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 shows the pre-configured logic in grey. You should not modify anything contained within these objects. You should add customisations to the existing mapping, which allows them to run parallel to the existing logic.


Type I Customisation: 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, reusable transformations Should not be changed.

Custom objects: Objects not shipped by Oracle Can be added to a mapping


Type I Customisation: Impact of Customisation 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 Customisation: Points to Remember

Encapsulated objects must never be customised unless directed by Oracle.

Exposed objects can be extended but must never be otherwise be modified.

Custom objects are never changed during an upgrade. Minimise the number of changes to exposed objects by using custom

objects. Evaluate options and determine the best approach for your

environment Custom object approach is the preferred approach if ETL time is

acceptable.


Type I Customisation: 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 Extraction (SDE) and the 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 II Customisation: Adding Additional Tables

Use pre-packaged adaptors to add new fact or dimension tables to the datawarehouse, regardless of whether they are already mapped.

Build new SDE and SIL mappings.


Type II Customisation: 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 Customisation: Required Columns

Staging tables: INTEGRATION_ID, DATASOURCE_NUM_ID

Fact, dimension and extension tables: INTEGRATION_ID, DATASOURCE_NUM_ID, ROW_WID, ETL_PROC_WID


Type II Customisation: 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 the value “1” for Siebel, this and other reserved values cannot be

used for other datasources


Type II Customisation: Custom Folders

Create custom SDE and SIL folders in Informatica and make changes in them. Do not store customised SDE and SIL mappings in the same folder.

Do not change objects in shipped folders. 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 Customisation: Custom Workflows

Create custom workflows for all customised 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 Informatica Designer. Register workflows in the DAC.


Additional Customisation Considerations

See next slides:. Table definitions in Informatica. Update Strategy ETL process Truncating target tables ETL_PROC_WID DATASOURCE_NUM_ID Creating Indices Naming Conventions Configuring the DAC


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

datasources regardless of database type. Used by Informatica to interpret at run time what the datatypes are going to be,

depending on the source and target specified in the session properties Does not affect behaviour of mappings or logic of how the data is loaded; database

types get converted appropriately If SQL style is not set to Oracle, mappings that use table definition will be

invalid.


Update Strategy

Design a custom process to detect new and modified records. Process should be designed to load only incremental data. If data is loaded without incremental process, 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 combination exists, ROW_WID is returned and record updated.3. In some cases e.g. eBS, the last update date stored in the the target tables is also

compared to the columns mentioned to determine insert or update.4. If combination does not exist, lookup returns NULL and a record is inserted.


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.

Integration of data from different sources and update frequency in SCD have impact on sequential or parallel loads


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 tables based on the following guidelines:

For SDE workflows, the commands for full and incremental load are the same. They should have the Truncate Always flag selected in the DAC.

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 is truncated, the indices are automatically dropped and created after the data is loaded.


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 the reusable lookup LKP_ETL_PROC_WID to

mapping; input to lookup is a constant (hard-coded to 1)

DATASOURCE_NUM_ID Use a parameter to define this value in the mapping.

The DAC will automatically create a parameter file with the correct DATASOURCE_NUM_ID, which will be picked up by the parameter in the mapping.


Creating Indicies

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.


Naming conventions

Name all the newly created tables with the prefix WC_. This helps isolate the new tables from the shipped tables

Keep good documentation of customisations. Helps when upgrading the warehouse

DWH Base Staging• Fact Table WC_XXX_F WC_XXX_FS• Dimension Table WC_XXX_D WC_XXX_DS• Dimension Hierarchy Table WC_XXX_DH WC_XXX_DHS• Aggregated Fact Table WC_XXX_A


Configuring DAC

Customisation changes must be registered in the DAC: Table, column and index definitions Workflows Custom folders


Implementation


General Considerations

Which BI Applications modules are being implemented? Is the customer coming with specific reporting/BI requirements? What are the source systems and does this include multiple

instances of one source system type? Are adaptors available for the relevant module and source system? Is the project to be phased in delivery of modules? What are the levels of UI and security integration between BI Apps

and source systems? Level of customisation of source systems? Is BI Apps being implemented at the same time as source systems? Implementation vs Upgrade?


Iterative Delivery approach

• Key requirement selected

• Install and populate “vanilla” BI Apps warehouse

• Gap Analysis, design and configuration

• Tailor and test BI Apps for first key requirement

• Deploy BI Apps to production

• Start work on next set of requirement

• 60-90 day release cycles

Definition

Requirements Modelling

Construction

Production


Typical Effort & Customization balance

Extension of DW Schema for extension columns, additional tables, external sources, aggregates, indices, etc.

Extension of ETL for extension columns, descriptive flexfields, additional tables, external sources, etc.

Additional derived metrics, custom drill paths, exposing extensions in physical, logical and presentation layer, etc.

Additional dashboards and reports, guided and conditional navigations, iBots, etc.

Level ofEffort

Degree of Customization

Easy

Moderate

Intermediate

Involved

Dashboards & Reports

OBIEE Metadata

DW Schema

ETL


Typical Customization


BI Application Extensions

Type 1 Simple Extensions Extension of existing facts or dimensions with new information

Type 2 New Facts or Bridge table New Facts or Bridge with existing dimensions

Type 3 Fact granularity change Add new Dimensions to an existing Fact

Type 4 New star schema New facts and some new dimensions integrated with existing dimensions

Type 5 Additional Source Systems Adding a second home-grown or non-supported source

Type 6 Security Modified data access control and security mechanism

Type 7 Hierarchy Changes Modified hierarchies because of dimension extensions

Type 8 Slowly Changing Dimension Changes More or less attributes

Type 9 Other than standard source tables part of CDC

1

2

3

4


BI Apps Implementation Steps

1. Vanilla implementationA. Tech and Func. Architecture / Install and basis configurationB. Global setup

Security / Mapping ETL / DAC Repository /OBI EE Repository / Dashboards

C. Per module : Standard configuration and load D. Per module : Data quality checkE. Per module : Integration testingF. Assistance to functional UATG. Assistance for transition to production

2. Tailoring

Knowledge Transfer

Project Managem

ent


1. Vanilla Implementation2. Tailoring

A. Gap analysis : global and per moduleB. Per module : data modelingC. Per module : ETL customization and load D. Per module : OBIEE customization and new dashboards E. Per module : Unit Testing and Data quality checkF. Per module : Integration testingG. Assistance to functional and technical UATH. Assistance for transition to production

BI Apps Implementation Steps

Knowledge Transfer

Project Managem

ent


Roll-out priorities 1. Procurement2. Accounts Payable3. GL + Accounts Receivable4. Custom development : Grants Management

BI Apps Example Rollout

Procurement

AP

GL + AR

Standard Custom

Standard Custom

Standard Custom

GM Custom


Profile of an OBI Apps Implementation TeamRole Responsibility Skill Sets

Project Manager

Responsible for the management of the project team and all client relations

Project Management with experience in OBI Apps deploymentClient and Vendor escalations

Technical / Solutions Architect

Applications DeploymentGap Analysis - TechnicalSolution and Technical design mitigating gap to OOB product

Depth and Breadth on technical knowledge of the products used.Knowledge on Functional Area and maybe industry

SME Functional Analyst

Requirements DefinitionGap Analysis – FunctionalReport & Dashboard DevelopmentTesting - FunctionalEnd user Training

SME on Functional area and industryKnowledge of ootb content for OBI Apps modulesDocumentation and Training

ETL Developer Back End Installation, configuration and development of custom ETL code

Informatica DevelopmentWorking Knowledge of OBI Apps

OBIEE Configurator

Metadata ConfigurationDashboard Configuration

OBI Metadata and Dashboard ConfiguratorKnowledge of OOB content for OBI Apps modules


Summary

This module provided an introduction to:

CustomisationsImplementation approachImplementation roles

© Peak Indicators Limited

Helping Your Business Intelligence Journey

Date post:	02-Jan-2016
Category:	Documents
Upload:	chanukya-reddy-mekala
View:	64 times
Download:	3 times

Informatica Standards.pptx

Documents