3sixty reporting - technical design v1.0.1

33
Technical Design - OBIEE Innoveer Solutions Version 1 Owner: Chenly Paz Last Updated: 04 October 2010

Upload: dineshreddy7190

Post on 29-Nov-2014

141 views

Category:

Documents


3 download

TRANSCRIPT

Page 1: 3Sixty Reporting - Technical Design v1.0.1

Technical Design - OBIEE

Innoveer Solutions

Version 1Owner: Chenly PazLast Updated: 06 October 2010

Page 2: 3Sixty Reporting - Technical Design v1.0.1

Copyright Notice

The Copyright in this work is vested in Innoveer Solutions Inc. and the document is issued in confidence for the express purpose for which it is supplied. It must not be reproduced, in whole or in part, or be used for any other purpose without prior written consent being obtained from Innoveer Solutions Inc., and then only on the condition that this notice be included in any such reproduction. No information as to the contents or subject matter of this document, or any part thereof, arising directly or indirectly there from shall be given orally or in writing or communicated in any manner whatsoever to any third party without the prior written consent of Innoveer Solutions Inc.

© Copyright Innoveer Solutions Inc. 2010

Revision History

Version Author Status Date Revisions0.1 Chenly Paz Draft 09/23/2010 Initial document created

Distribution List

Name Organisation

Chenly Paz Innoveer SolutionsDebu Saha Innoveer Solutions

Version 1Owner: Chenly PazLast Updated: 06 October 2010

Page 3: 3Sixty Reporting - Technical Design v1.0.1

Technical Design – OBIEE

Contents

1 Introduction......................................................................................................................41.1 Document Purpose.........................................................................................41.2 Scope..............................................................................................................41.3 Related Documents.........................................................................................41.4 Abbreviations..................................................................................................5

2 Solution Overview...........................................................................................................62.1 Toolset Used...................................................................................................62.2 Implementation Strategy.................................................................................8

3 Star Schemas...................................................................................................................93.1 Opportunity Star Schema................................................................................93.2 UOPS Sales Star Schema............................................................................103.3 MST Analysis Star Schemas.........................................................................103.4 Territory Alignment Star Schemas................................................................113.5 Course Analysis Star Schemas.....................................................................12

4 ETL..................................................................................................................................134.1 Overview.......................................................................................................134.2 DWH Tables Definitions................................................................................144.3 Informatica Repository Changes...................................................................174.4 DAC Repository Setup..................................................................................18

5 RPD – Guide for Developers.........................................................................................195.1 Overview.......................................................................................................195.2 Real-Time Answers Reporting......................................................................20

6 Front-End Reporting: Guide for Developers...............................................................216.1 Dashboards...................................................................................................216.2 Siebel – Embedded Reports.........................................................................216.3 Siebel – BI Publisher Report.........................................................................21

Page 3 of 25 Printed 09/04/23

Page 4: 3Sixty Reporting - Technical Design v1.0.1

Technical Design – OBIEE

1 Introduction

1.1 Document Purpose

This document outlines the changes to the current Siebel application configuration as well as standard Oracle BI Applications v7.9.6.1 modification to be implemented for the purpose of the JAR 1 and JAR 2 build for Pearson Education – 3Sixty Release 1

1.2 Scope

This technical design document only includes JAR 1 and JAR 2 deliverables. This scope corresponds to what is required to be built and presented in JAR 3. Please refer to the ‘BI JAR Delivery Schedule’ to gain more clarity on what is included in this JAR.

Data-Level permissions and other security or visibility-related requirements will be designed in later JARs and will not be part of this particular design document. In addition, the following have been deemed out of scope for this document due to necessary lag between application design and reporting design:

Reports specific to products analysis only Product Specialist reporting where there is a requirement to link a product

specialist to their corresponding FT discipline Complex requirements related to Product Kits and component level reporting

1.3 Related Documents

These documents can be found in the 3Sixty Project Sharepoint application. Please contact the Design Lead for the specific location of these documents.

# Document Version Author1 OBIEE and ETL Development Standards Witold Kusnierz2 JAR 2 Functional Design Document – Reporting Jane Riff3 BI JAR Deliver Schedule Chenly Paz4 Oracle Business Intelligence Applications ETL

Data Lineage Guide Version 7.9.6 / 7.9.6.1Oracle

5 Oracle Business Analytics Warehouse Data Model Reference Version 7.9.6

Oracle

Page 4 of 25 Printed 09/04/23

Page 5: 3Sixty Reporting - Technical Design v1.0.1

Technical Design – OBIEE

1.4 Abbreviations

# Abbreviation Definition1 OBIEE Oracle Business Intelligence Enterprise Edition2 OOTB Out of the Box3 OLAP Online Analytical Processing4 ETL Extract, Transform and Load5 DAC Data Warehouse Admin Console

6 BIU / PIU Book In Use / Product In Use

Page 5 of 25 Printed 09/04/23

Page 6: 3Sixty Reporting - Technical Design v1.0.1

Technical Design – OBIEE

2 Solution Overview

2.1 Toolset Used

The Oracle Business Intelligence Suite Enterprise Edition (OBIEE) is a comprehensive suite of Business Intelligence tools and infrastructure designed to bring greater business visibility and insight to the broadest audiences of users, allowing any user in an organization to have Web-based self-service access to up-to-the moment, relevant, and actionable intelligence. OBIEE comprises of BI server technology and BI presentation tools. The platform consists of several interdependent components, with the Oracle BI Server at its core.

Business Intelligence Server

The foundation of the Oracle Business Intelligence Suite Enterprise Edition Plus platform is a true BI server that is designed to be highly scalable, optimizing concurrency and parallelism to make the value of BI applications available to the largest possible audience. It provides centralized data access and calculation, essentially creating a large pipe through which anyone can consume any information in any form anywhere in the enterprise. The BI server is central to all of the business processes that consume information, including dashboards, ad hoc queries, intelligent interaction capabilities, enterprise and production reporting, financial reporting, OLAP analysis, data mining, and other Web Service-based applications (J2EE and .NET). All of these applications require rich access to broad sets of data across the enterprise, and they all require a sophisticated calculation and aggregation infrastructure that the platform provides to deliver value.

The platform supports a full complement of access, analysis, and information delivery options, all in one fully integrated Web environment. Each of these components serves different audiences in the organization who have different appetites for the same underlying data, but need to access it in different ways. But unlike other BI tools, all components are integrated onto one common architecture, enabling a seamless and intuitive user experience.

Intelligence Dashboards

Oracle BI Interactive Dashboards provide any knowledge worker with intuitive, interactive access to information that is actionable and dynamically personalized based on the individual's role and identity. In the Oracle BI Intelligence Dashboards environment, the end user is working with live reports, prompts, charts, tables, pivot tables, graphics, and tickers in a pure Web architecture. The user has full capability for drilling, navigating, modifying, and interacting with these results. Oracle BI Intelligence Dashboards can also aggregate content from a wide variety of other sources, including the Internet, shared file servers, and document repositories.Answers

Page 6 of 25 Printed 09/04/23

Page 7: 3Sixty Reporting - Technical Design v1.0.1

Technical Design – OBIEE

Oracle BI Answers provides true end user ad hoc capabilities in a pure Web architecture. Users interact with a logical view of the information—completely hidden from data structure complexity while simultaneously preventing runaway queries—and can easily create charts, pivot tables, reports, and visually appealing dashboards, all of which are fully interactive, drillable and can be saved, shared, modified, formatted, or embedded in the user's personalized Oracle BI Intelligence Dashboards. The results are new levels of business user self-sufficiency in an environment that is fully secure and controlled by IT.

Delivers

Oracle BI Delivers is a proactive intelligence solution that provides business activity monitoring and alerting that can reach users via multiple channels such as email, dashboards, and mobile devices. Oracle BI Delivers includes a full Web-based self-service alert creation and subscription portal. This next-generation product can initiate and pass contextual information to other alerts to execute a multistep, multi-person, and multi-application analytical workflow. Furthermore, it can dynamically determine recipients and personalized content to reach the right users at the right time with the right information.

Reporting Solution for 3Sixty Analytics Reporting

For the purpose of JAR 1 and JAR 2 implementation, the reporting solution will comprise of OBIEE Platform v10.1.3.4.1 with Oracle BI Applications v7.9.6.1 providing all necessary metadata and ETL logic. Oracle BI Applications use Oracle Business Analytics Warehouse - a unified data repository, also referred as Data Warehouse, for all customer-centric data - as a primary data source to support the majority of analytical reporting requirements.

OBIEE application will be integrated with Siebel and exposed to end users via additional Screens and Views.

Page 7 of 25 Printed 09/04/23

Page 8: 3Sixty Reporting - Technical Design v1.0.1

Technical Design – OBIEE

Figure 1 OBIEE Architecture Diagram

Users will be granted access to selected OBIEE modules - Dashboard, Answers and Delivers depending on their privileges granted in Siebel application.

Page 8 of 25 Printed 09/04/23

Page 9: 3Sixty Reporting - Technical Design v1.0.1

Technical Design – OBIEE

2.2 Implementation Strategy

In a standard OBIEE implementation, there are 5 main areas that require design consideration.

Database / Data Warehouse DesignFor this project, the strategy for the database design is to leverage (as much as possible) the Out-of-the-box (OOTB) data warehouse schema included in OBI Analytics Applications Version 7.9.6.1. An exception to this would be the following:

When the source application (Siebel) has been modified to add custom fields or custom functionality. In this case, the custom fields or functionality could require new tables or new columns to be added into existing tables.

When the functional requirements cannot be met with OOTB OLAP schema. When it is found that for performance tuning purposes, there is a requisite need

to change the table structure or OLAP schema

ETL / Informatica DesignFor this project, the strategy for the ETL or Informatica mapping and workflow design is to leverage (as much as possible) the Out-of-the-box (OOTB) SDE and SIL mappings contained in OBI Analytics Applications Version 7.9.6.1. An exception to this would be the following:

When new fields and tables need to be added or created. When the logic of the OOTB mappings are not required or do not apply to the

current requirements.

Data Warehouse Admin Console (DAC) DesignFor this project, the strategy for the DAC design is to leverage (as much as possible) the Out-of-the-box (OOTB) DAC repository included in OBI Analytics Applications Version 7.9.6.1. An exception to this would be the following:

When certain subject areas or tasks do not apply to the current implementation of the Siebel application. In this case, a new execution plan will be created tailored to the functionalities required for JAR 1 and JAR 2 only.

OBI Server Repository Administration (RPD) DesignFor this project, the strategy for the RPD design is to create a single new Business Model which will be referred to as ‘Pearson Core’. The aim is to trim and tailor the OOTB Business Model ‘Core’ to meet the reporting needs of the project. Accordingly, custom presentation folders will be created to reflect the new business model and reporting requirements.

Answers, Delivers and Intelligence DashboardsFor this project, the strategy for the front-end design of JAR 1 and JAR 2 is to create new dashboards using the presentation folders created specifically for this project. In addition, custom subject areas will be exposed to enable authorised and trained end-users to generate ad-hoc reports using Answers.

Page 9 of 25 Printed 09/04/23

Page 10: 3Sixty Reporting - Technical Design v1.0.1

Technical Design – OBIEE

3 Star SchemasThis Technical Design Document provides information on which physical database tables and joins will be used to fulfill the business requirements as set out in the JAR 2 Functional Design Spec – Reporting document.

Note that the following star schemas are only in reference to the ‘Simplified Star Schemas’ as the ‘Combined Subject Areas’ are merely a logical grouping of multiple star schemas. Star Schemas

Opportunity Star Schema UOPS Sales Star Schema MST Course + MST Product Schema Territory Account Star Schema Territory Course Star Schema Book In Use Star Schema

3.1 Opportunity Star SchemaThis will be the main star schema used for all Opportunity related reporting. For the latest logical diagram for the Opportunity Star Schema, please refer to the JAR 2 Functional Design Document – Reporting. Figure 2 below is the corresponding Physical Diagram.

Please note,the implementation of component –level opportunity reporting is pending more information on how product bundles will be implemented in the application.

Page 10 of 25 Printed 09/04/23

Page 11: 3Sixty Reporting - Technical Design v1.0.1

Technical Design – OBIEE

Figure 2 Opportunity Star Schema - Physical Design

Page 11 of 25 Printed 09/04/23

Page 12: 3Sixty Reporting - Technical Design v1.0.1

Technical Design – OBIEE

3.2 UOPS Sales Star Schema

This Sales Star Schema is a custom star schema used to report on actual invoiced sales with data sourced from the UOPS application. Dimensional data will primarily be sourced from the Siebel transactional system while the records in the fact table will be extracted, transformed and loaded from the existing Sales Datamart at the Date, Territory, Product, School and Bookstore level. For the latest logical diagram for the UOPS Sales Star Schema, please refer to JAR 2 Functional Design Document – Reporting. Figure 3 below is the corresponding Physical Diagram.

Figure 3 UOPS Sales Star Schema - Physical Diagram

3.3 MST Analysis Star Schemas

There are two MST Analysis Star Schemas. The first (Figure 4) allows for analysis of Courses by MST while the second (Figure 5) is used for analyzing products within an MST.

Figure 4 MST to Course Star Schema – Physical Diagram

Page 12 of 25 Printed 09/04/23

Page 13: 3Sixty Reporting - Technical Design v1.0.1

Technical Design – OBIEE

Figure 5 MST to Product Star Schema – Physical Diagram

3.4 Territory Alignment Star Schemas

There are two Territory Alignment Star Schemas. Both are related to which sales reps, product specialist and/or tech specialist is assigned to an account (whether this is a school, department or course).

Figure 6 Territory to Course Star Schema – Physical Diagram

Figure 7 Territory to Account Star Schema – Physical Diagram

Page 13 of 25 Printed 09/04/23

Page 14: 3Sixty Reporting - Technical Design v1.0.1

Technical Design – OBIEE

3.5 Course Analysis Star Schemas

There are two Course Analysis Star Schemas. One is the Course BIU (Book in Use) star schema which will allow the user to view and analyse which books are used in a particular course. The second is the Course Enrollment star schema. This schema can be used to analyse enrolment by Term and by Course.

Figure 8 Course to BIU Star Schema – Physical Diagram

Figure 9 Course Enrollment Star Schema – Physical Diagram

Page 14 of 25 Printed 09/04/23

Page 15: 3Sixty Reporting - Technical Design v1.0.1

Technical Design – OBIEE

4 ETL4.1 Overview

4.1.1 Oracle Business Analytics Warehouse

Oracle Business Analytics Warehouse, also referred as Data Warehouse or OLAP (ROLAP), is a unified data repository designed to store all customer-centric from a variety of Oracle products such as Siebel CRM, Oracle E-Business Suite or PeopleSoft in dimensional form following best industry practices. It’s a database that contains the data extracted and derived from the online operational database(s) – OLTP (e.g. Siebel database), where the data structures have been optimized for advanced, large volume reporting and analytical processing.

The strategy of a data warehouse is that the main time-consuming transformations, calculations and data consolidation tasks occur during the loading of the data warehouse, which happens outside of business hours, rather than when the user queries the data via a report/analysis. The other key advantage of having a separate database as a data warehouse is that it has no impact on Siebel CRM application during business hours as a different database is used.

4.1.2 ETL Process

The actual transfer of the data from the online operational database to the data warehouse and the related processing that takes place during this movement is called the ETL process:

Extract: Moves the necessary data from the online database to temporary (staging) tables on the data warehouse. No other processing on the online operational database takes place to minimize the impact on its resources.

Transform: Processes the data. Cleans, rearranges and derives data. Load: Loads the data into the real Data Warehouse tables used by the Analytics

application

There are two types of ETL that can take place: Full ETL. This carries out a full transfer of all the related data from the online

operational database to the data warehouse. Incremental ETL. This only transfers data that has been updated or inserted in

the online operational database since the last ETL. Note that incremental ETLs can follow full ETLs or previously run incremental ETLs but can never be the first ETL run on an empty data warehouse. The time for an incremental ETL is considerably shorter than the time required for a full ETL.

For the purpose of the Opportunity Pilot project all ETL execution plans will run in a full refresh mode scheduled to run on a nightly basis, outside business hours.

Page 15 of 25 Printed 09/04/23

Page 16: 3Sixty Reporting - Technical Design v1.0.1

Technical Design – OBIEE

Figure 10 ETL - Full Refresh Mode

4.2 DWH Tables Definitions

The following section lists the key OLAP tables in Oracle Business Analytics Warehouse, which will be used for JAR 1 and JAR 2 implementation.

Note that the table below lists the key tables only, none of the standard tables will be dropped from the database i.e. all tables for the standard Oracle Business Analytics Warehouse will be created. For the full specification for the standard tables please refer to “Oracle Business Analytics Warehouse Data Model Reference Version 7.9.6.1”.

The ‘Status’ field indicates whether the OLAP Table is OOTB or is a new custom table.

4.2.1 Dimension and Helper Tables

Table 1 Dimension and Helper Tables

Table Status

Business Name Comments

W_AFFL_AA_H OOTB Account to Account Affiliation Helper Table

Helper table for Account to Account affiliations.

W_ASSET_D OOTB Asset DimensionW_ASSET_MD OOTB Asset Mini DimensionW_DAY_D OOTB Day Dimension Base calendar dimension for

the Oracle BI data warehouse. Stores the date related information at the individual calendar day level.

Page 16 of 25 Printed 09/04/23

Siebel CRM

S_EVT_ACT

S_CONTACT

Siebel Data Warehouse

Transform& Load

Source Target

Image Capture Tables

S_ETL_I_IMAGES_ETL_R_IMAGE

Staging TablesW_*_DSW_*_FS

Source OLTP System Tables

Normalized structure optimized for OLTP processing

S_CONTACT

S_ADDR_PER

S_ZIPCODE

S_ACT_CON

S_EVT_ACT

Denormalized structure (star/snowflake schema) optimized for OLAP reporting

W_ACTIVITY_F

W_DAY_D W_CONTACT_D

W_LOV_D

Target Tables

Dimension:W_*_DFact”W_*_FAggregate:W_*_AFULL SET OF

RECORDS

W_ACTIVITY_F

W_PERSON_D

W_ACTIVITY_FS

W_PERSON_DS

ETL Process Control Tables

Page 17: 3Sixty Reporting - Technical Design v1.0.1

Technical Design – OBIEE

Table Status

Business Name Comments

Additional fiscal calendar information is loaded from fiscal_week.csv or the iscal_month.csv files

W_EMPLOYEE_D OOTB Employee DimensionW_GEO_D OOTB Geography Dimension Allows for more streamlined

reporting on STATE, CITY, ZIPCODE AND/OR COUNTRY

W_LOV_D OOTB List of Value Dimension Common dimension table based on S_LST_OF_VAL

W_OPTY_D OOTB Opportunity DimensionW_OPTY_MD OOTB Opportunity Mini DimensionW_PARTY_ORG_D

OOTB Account Dimension

W_POSITION_D OOTB Position Dimension Primary Position dimension table used as a source for other Position tables such as W_POSITION_DH or W_POSITION_H

W_POSITION_DH OOTB Position Dimension Hierarchy Flattened hierarchy of the Position dimension W_POSITION_D

W_PROD_CAT_DH

OOTB Product Category Dimension Hierarchy

Flattened Hierarchy of Product Categories

W_PRODCAT_DH OOTB Product to Category Dimension Hierarchy

Flattened hierarchy of Product Categories (W_PROD_CAT_DH) with a link to the Product Dimension (W_PRODUCT_D)

W_PRODUCT_D OOTB Product DimensionW_SSTAGE_D OOTB Sales Stage Dimension Opportunity Sales StagesWC_ORG_CTLG_CAT_H

NEW Account to Categories Helper Table

Custom Helper table for many-to-many Account to Category relationships

WC_PARTY_CTGRY_H

NEW Position to Categories Helper Table

Custom Helper table for Position to FT relationship (via access groups)

WC_PARTY_ORG_MDR_DX

NEW W_PARTY_ORG_D Extension table.

Extension to W_PARTY_ORG_D to store MDR information

WC_REP_TO_SPEC_H

NEW Sales Rep to Specialist Helper Table

Custom Helper table to resolve the relationship between a Sales Rep to multiple Product Specialists or one Tech Specialist.

Page 17 of 25 Printed 09/04/23

Page 18: 3Sixty Reporting - Technical Design v1.0.1

Technical Design – OBIEE

Page 18 of 25 Printed 09/04/23

Page 19: 3Sixty Reporting - Technical Design v1.0.1

Technical Design – OBIEE

4.2.2 Fact Tables

Table 2 Fact Tables

Table Status Business Name CommentsW_ASSET_F OOTB Asset Fact Primary Fact Table

for Assets and used for Book In Use analysis.

WC_ORG_PARTY_F OOTB SDE, NEW SIL

Account to Position Fact Fact table for reporting on Account to Position relationships

W_REVN_F OOTB Revenue Primary fact table for Opportunities based on S_REVN base table.

W_UOPS_SALES_F NEW UOPS Sales Fact Primary fact table for UOPS Sales. UOPS Sales is external sales data from the Pearson ordering system.

4.2.3 Required OLAP Changes

Selected OOTB tables have been extended with additional columns to store custom attributes required for reporting purpose. All customizations and new tables have been documented in “JAR 1&2 3Sixty BI - ETL mappings” spreadsheet and will be applied to Oracle Business Analytics Warehouse using DDLimp utility.

4.2.4 Real-Time Table

For the Product Specialist report, a real-time (OLTP) table will be used to allow for ‘what-if’ analysis of Specialist to Rep Alignment before the actual Territory Alignment runs in the application. This table will need to be added into the Physical Layer of the RPD and is specified as follows:

Table 3 OLTP Real Time Table

Table Column DescriptionS_ACCNT_POSTN OU_EXT_ID Account or Course ID. This will be joined with

the Account ID in Sales Fact for future alignment reporting.

S_ACCNT_POSTN POSITION_ID Position ID of the Rep assigned to Account or Course Team. This will be joined with the Rep Position in Sales Fact for future alignment reporting.

Page 19 of 25 Printed 09/04/23

Page 20: 3Sixty Reporting - Technical Design v1.0.1

Technical Design – OBIEE

Table Column DescriptionS_ACCNT_POSTN NEW_POSITION

_IDPosition ID of new Rep to be added, removed or swapped

S_ACCNT_POSTN OPERATION Add = Rep in NEW_POSITION_ID is to be added the Account or Course Team

Swap = Rep in NEW_POSITION_ID is replacing the current rep in POSITION_ID.

Remove = Rep in POSITION_ID will be removed from the Account or Course’s Team

4.3 Informatica Repository Changes4.3.1 Overview

OBIEE suite uses Informatica PowerCenter 8.1.1 as the main tool to perform the ETL jobs. Oracle BI Applications come with a set of pre-defined Informatica data flows for the OOTB Siebel application covering the majority of key Entities used within Siebel such as Accounts, Contacts, Products, Opportunities etc. As part of the customization process, OOTB data flows will be copied and altered to include any and/or columns not already transferred by the pre-defined flows.

4.3.2 Informatica Mappings

Informatica Mappings are objects that describe how the data is being processed with a data flow including source and destination table definitions, any necessary data transformations or aggregations etc For the Oracle BI Applications, mappings are grouped in the following two stages:

Source Dependent Extract (SDE) Mappings, which are responsible for the Extract part of the ETL process,

Source Independent Load (SIL) Mappings, which are responsible for Transform and Load parts of the ETL process.

4.3.3 Informatica Workflow/Sessions

A Workflow is a grouping of Sessions that in turn contain one or more Mappings. A Session is a particular Mapping instance with definitions for the source and destination parameters (e.g. database names, etc.). In case of Oracle BI Applications each Mapping has a dedicated Workflow and Session with matching names.

4.3.4 Customisations of mappings and workflow/sessions

It’s a best practice that none of the OOTB Informatica objects are being modified during the implementation. In order to modify the data flow logic all necessary objects need to be first copied into “Custom” folders before being altered.

Page 20 of 25 Printed 09/04/23

Page 21: 3Sixty Reporting - Technical Design v1.0.1

Technical Design – OBIEE

All custom and customized Informatica objects have been documented in a Data Mapping spreadsheet - “JAR1/JAR 2 3Sixty BI - ETL mappings”) used for identifying the individual mappings from the OLTP source tables and columns to the Oracle Business Warehouse target tables and columns, along with the extraction, transformation, and loading rules.

Note: Data Mapping spreadsheet is only intended to document customizations to OOTB data flows and NOT the entire data flows themselves.

4.4 DAC Repository Setup

DAC Server is an OBIEE platform component that controls the entire ETL process. It is responsible for execution of all necessary Informatica Workflows in the correct order based on dependencies defined in DAC repository (e.g. extracts before loads, dimension tables loads before fact tables loads etc). In addition to this DAC Server takes care of the incremental load process and various database maintenance tasks related to the ETL process such as dropping and recreating indexes or updating database statistics after each database refresh.

As part of the project DAC repository needs to be updated to in order to:

Trim OOTB Subject Areas to reflect used entities and minimize time necessary for ETL execution,

Register new tasks for all updated Informatica Workflows Register new tables and indexes Create Execution Plan and schedule

4.4.1 Subject Areas and Execution Plan

This section will be populated upon build according the OLAP tables that will be used. Please refer to section 4.2 of this document for the list of facts and dimension tables that will be used.

Page 21 of 25 Printed 09/04/23

Page 22: 3Sixty Reporting - Technical Design v1.0.1

Technical Design – OBIEE

5 RPD – Guide for Developers

5.1 Overview

In developing the RPD, ALL of the following documents (or sections of documents) will be needed:

1. 3Sixty OBIEE and ETL Development Standards v12. Logical Data Dictionary Embedded in JAR 2 Functional Design Document –

Reporting This provides all the logical definition of the measures and dimension

attributes required in this delivery This document also provides the exact labelling of the measures and

dimension attributes in the Presentation Layer3. Star Schemas in JAR 2 Functional Design Document – Reporting

This section will provide the Business Model for the required facts and subject areas

4. Section 3 ‘Star Schemas’ of this document. This provides the translation from the Logical design into the Physical

Model5. JAR 1&2 3Sixty BI - ETL mappings

Use this in conjunction with the Logical Data Dictionary to determine the OLAP columns to be used in the Logical Layer of the RPD

6. Section 5.2 of this document For those reports that combine real time reporting with historical reporting,

more specifically, the Territory Analysis: Product Specialist report. This section refers to the real-time tables to be used (no ETL required)

7. Section 5.3 of this document Outer Joins must be configured as per section 5.3 Required Outer Joins of

this document.

Page 22 of 25 Printed 09/04/23

Page 23: 3Sixty Reporting - Technical Design v1.0.1

Technical Design – OBIEE

5.2 Real-Time Answers Reporting

Table 4 Real Time Physical Tables (to be specified in RPD)

Table Purpose SQLS_ACCNT_POSTN_H Helper table to report on

the future Account Team intersection. This table is to be used after the planned changes are entered into the Sales Assignment View but before the Territory Re-alignment process runs).

SELECT OU_EXT_ID, POSITION_ID, NEW_POSITION_ID, OPERATION, CASE WHEN OPERATION = 'Remove' THEN NULLWHEN OPERATION = 'Swap' THEN NEW_POSITION_ID END AS CALC_FUTURE_POSTN_IDWHEREOPERATION IN ('Remove','Swap')

UNION

SELECT OU_EXT_ID, POSITION_ID, NEW_POSITION_ID, OPERATION, NEW_POSITION_ID AS CALC_FUTURE_POSTN_IDWHEREOPERATION = 'Add'

Please note, column names may not be exactly as stated above as at the time of writing, the design of the application has not been finalized yet.

Page 23 of 25 Printed 09/04/23

Page 24: 3Sixty Reporting - Technical Design v1.0.1

5.3 Required Outer JoinsThe ‘Special Rules’ tab of the JAR 2 Logical Data Dictionary states that certain facts require an outer join to show dimensions where an event has not occurred. These rules and how they can be implemented is stated as follows:

Entity ID

Entity Name Comments Outer Join Description

F3AMST COURSE FACT

Should contain all institutional courses regardless of whether they are coded or not. They will be assigned to "Unspecified" MST)

W_PARTY_ORG_D LEFT OUTER JOIN WC_ORG_CTLG_CAT_H

F4TERRITORY ACCOUNT FACT

Should contain all accounts regardless of whether they are assigned to person or not. They will be assigned to "Unspecified" Rep. It will also show all 'types' of accounts (school, department) at all levels of hierarchy

W_PARTY_ORG_D LEFT OUTER JOIN WC_ORG_PARTY_F

F5TERRITORY COURSE FACT

Should contain all institutional courses regardless of whether they are assigned to person or not. They will be assigned to "Unspecified" Rep.

W_PARTY_ORG_D LEFT OUTER JOIN WC_ORG_PARTY_F

F6

COURSE ENROLLMENT FACT

Should contain all institutional courses regardless of whether they have a BIU or not

W_PARTY_ORG_D LEFT OUTER JOIN W_ASSET_F

Version 1Owner: Chenly PazLast Updated: 06 October 2010

Page 25: 3Sixty Reporting - Technical Design v1.0.1

Technical Design – OBIEE

6 Front-End Reporting: Guide for Developers

6.1 DashboardsFor this JAR, all non-operational reports will be embedded in separate pages in a temporary dashboard called ‘JAR 2 Dashboard’. This will be the only dashboard for all reports.

For this JAR build purposes, point the Sales Dashboard in Siebel -> Sitemap to the temporary dashboard ‘JAR 2 Dashboard’.

IMPORTANT: Create an Action Link for ALL reports on Master Account, Bookstore, Course and/or Department name to be opened in the application.

6.2 Siebel – Embedded ReportsFor this JAR, the following reports are to be embedded in the application:

Report No.

Report Title Embed in Location Reason for Embedding

7 Account Sales History

Sales History Tab in Accounts Screen

To view Sales History for a specific Account

Please refer to JAR 2 Functional Design Document – Reporting for the exact front-end design of the above reports.

6.3 Siebel – BI Publisher ReportThere is no specific technical design for the BI Publisher reports. To develop these reports, please refer to the requirements in the JAR 2 Functional Design Document – Reporting. For this JAR, the BI Publisher reports are:

1. Bookstore Adoption Report (report number 9 in Report Design Section)

Page 25 of 25 Printed 09/04/23