OBIA interview Question

OBIEE & Siebel Analytics Interview Topics :
------------------------------------------------------------------------------------
------------------------------------------------------------------------------------
1: Architecture ( Infrastructure & Applications)
2: Components ( BI Server, Delivers Server, BI Web, BI Cluster, Open Intelligence Interface )
3: Caching ( Query , Web Server, Seed Cache, Siebel Analytic Server Cache))
4: SA Metadata Administration (Physical Layer, Logical Layer,Presentation Layer )
5: Build, Deploy and Generating Requests (Answers, Interactive Dashboards, Delivers, Web Catalog
6: Informatica Mapping Tables
7: Integration of OBIEE with siebel CRM applications
8: Marketing Segmentation ( segment, Segment tree,List Catalog, List Import,Target Levels and Target List)
9: SQL Joins: INNER JOINs, OUTER JOINs, CROSS JOINs. OUTER JOINs are further classified as
10: How to view more than 10000 records in Siebel Analytics web in a Table or Pivot table Views.
11: Bridge Table ( many to Many Relationship in dimension.) Implemenation in Siebel Analytics
12: Objetcs can be Imported in Physical Layer( tables, views, Aliases, synonyms, system Tables, Keys, Fk Keys)
13: Dimension Hierarchy ( Drill Key and Level Key, Prefered drill Path)
14: Business Model Complex Joins (Place holder) and hardcode foriegn key
15: Physical model Connection Pool (shared Logon and Maximum connections and FIFO)
16: Shared logon in Physical layer of the RPD how it works and whats the use of it
17: Global Prompt and Filters, Filter( is Prompted) in SA 7.5.3
18: Dashboard Objects ( content, reports,section, Page , Dashboard and Folder)
19: Admin page ( Sessions, Priviliges, Analytics Catalog, Web Groups and uses)
20: Performacne Tunining in Siebel Analytics ( hints and Nl,)
21: Event Polling ( how event polling is done and also Purging)
22: SDE and SIL Mappings ( Siebel data warehouse ETL, SRMW)
23: Slowly changing Dimension ( type1, Type2, type3)
24: Assocative Entity ( Data Modelling)
25: truncate and Delete ( Auto commit on truncate)
26: Types of indexed (In Oracle ( B* , B tree, clustered)
27: Explain Plan and TK Prof ( Tunning)
29: Aggreagte Navigation, Fragmentation, Intialization Blocks and Variables ()
30: Star and Snow flake Schema
31: SRMW Tables (Fact tables ,Dim Tables, mini Dim Tables, Subset dim Tables,
32: Circular Join, Factless Fact
33: Life cycle DWH
34: Views ( Narrative, Static, View Selector, Compound layout, charts and other Views)
35: Difference between Table and why Pivot Table View ?
36: SRMW Siebel Data Warehouse (W_PARAM_G needs to be populated always for any ETL run or all the SIL mappings will fail.
37: Aliases in siebel Analytics Physical Layer
38: Creation of Reports, Prompts and filters
39: Advantages and Disadvantages of using SQl in Physical Layer
40: XLs Sheet imported in Physical Layer and its use
41: Online and Offline mode in Repository
42: Navigation in SA if column is selected from two same sources in the Logical Layer
43: View and synonym where to use which scenarios in the Physical layer of the RPD
44: Triggers in Oracle
45: Can CASE statements used in Physical and Logical Layer ( IF Case and Switch CASE)
46: Groups and Web Groups, Groubs thats created in WEb will it visible in RPD
47: Customization of Login Page ( style sheets and XML Files)
48: use of a web server in Siebel analytics
49: Full and incremental Load in SA ETL
50: DB Growth and size of the Database after ETL
51: Mapping of new aggregate Table in the Business Layer
52: How to have a new column in siebel naswers if the column is not avalible in Metadata
53: DAC and ETL
54: Informatica, siebel Applications Configuration and Siebel Tools
55: Multiuser check out & Administration of RPDS.
56: OBIEE Security & Single Sign on
57: Visiblity Model in Siebel & OBIEE Analytics
58: function of Connection Pool in the physical layer
59: Different user authentication methods available in Siebel Analytic s
60: SA column selector whats it it and how it can be used
61: Servers installed after ur Installation of siebel Analytics
62: Action Links in siebel application
63: Siebe delivers Automatic population of Devices and profiles for users
64: System session and Variables in the Repository
65: Security Levels in siebel Analytics
66: OLAP and OLTP
67: star and snow flake schema. where snow flaks can be used and which uses what schema (OLAP and OLTP)
68: Image Prompt and column Prompt in siebel answers
69: How a logical request works in Siebel Analytics
70: Performance issues applied in the siebel Analytics
71: Siebel analytics clustering how fail over recognises the other server
72: properties of connection pool, multiple connection pools to the same Database
73: Narrative View and Styles applied to charts and different view avalible in analytics
74: Upgrade of a old web cat to a new Web cat After the new installation of OBIEE
75: Disconnected Who uses it and steps in configuring Disconnected application
76: How to Bypass the Repository Authenication
78: Corelated sub query, Derived Tables
79: Normalization and five normal forms
80: What is the primary key, foreign key, alternate key, composite key and candiate key
81: Bringing data at run time from other database
83: Meta data ( do we actually have database or is data stored in meta data
84: which triggers the ETL and how data is refreshed
85: How is the Event polling and purging done
86: Addding a New dimension to the Existing DataMart
87: Is Data model changed in Newer version of siebel analytics ( why and what measures needs to be taken while upgrading)
88: Ibot fails and ggives odbc error in Production how to prevent the error in delivering to the recipent
89: How to Create the report and what are the standards followed to do the same
90. Hierarchy of the Siebel Analytics Web components
91: How comfortable in Siebel tools to get the understanding of the Tables and joins
92: Data Modelling Fundamentals and Concepts Different Types of Data modelling (Physical & dimensional)
93: Different utilities in Siebel Analytics(Admin tool,odbc client & catalog)
94: Joins & Keys(in analytics Layers ie. Phy & Bus) , creation of Aggregation Tables(Hirearchy,summary,sources)
95: Different stages of working in analytics Repository(12)
96: Datawarehouse Basics & ETL
ETL (A,b,c into x (a,b,c ->different Data sources) how ot achieve by writing oracle procedure
97: Visiblity Model in Siebel Analytics
98: Advanced Formatting in analyitcs(Conditional Fomating of Reports)
99: Physical SQL, NQQuery Log, NQS Config. INI, Cluster Config
100: Integrated ,stand alone Analytics Difference.
101: Relationship between saved objects in Analytics Web Catalog and Repository
102: Configurable NQSConfig.ini file parameters which affect disk space
103: Setting INTERRUPT_ENABLED parameter for Analytics Server using DB2 as a source
104: Displaying Multiple Time Periods in a Single Report
105: PopChart image server functionality in Siebel Analytics version 7.5.x
106: How to set up LDAP Security within Siebel Analytics Repository
107: When are Subject Areas and View Privileges visible in the Admin > Manage Privileges link?
108: How can users move the "My Accounts" Link to the "My Dashboard" screen?
109: What are the standard/best practice rules to build a hierarchy?
110: How can users check the status of an iBot?
111: How to set-up multiple analytics repository access in Windows OS installs
112: How should usage tracking information be loaded into Siebel Analytics 7.5.x?
113: Can the Siebel Analytics Platform be upgraded without upgrading the Siebel application repository?
114: What is guided navigation, custom page layout, & system message
115: How do we add/control a system message, explain the steps in detail
116: What are alerts How do we schedule alerts
117: why is the 'number of elements at a level' required for dimension
118: Log level in Production, Locale
119: bumping log files in prodcution and how to debug the issue in prodcution when log level set to 0 and how to get the query in the log file
120: DAC system Properties design, setup and configure, indices and tasks and sessions defn in the dac
121: etl configure dw_rep tables create and drop dac repository, informatica Repository Tables
122: OBIEE briefing books and xml publisher
123: ETL takes more time to complete how to debug and what approach to resolve the same
124: session log, mapping, workflow, configuration settigns of informatica
125: Roll back segment error, snapshot too old error
126: Performance tuning, Conformed dimensions
127: change capture Process in ETL, Pruene Days
128: Design the report from scratch ( Data Model)
129: Level Based Measure, Grain in a fact Table
130: Architecural Difference between OBIEE & Siebel analytics

Diff between OBIEE 10g and 11g

OBIEE 10g and 11g

Thanks for the support you provided for my Differences Between Oracle 10g and 11g and Differences between OBIEE 10g and 11g security models? post.Here I am posting the difference in features available in OBIEE 10g and OBIEE 11g.When we compare OBIEE 10g and OBIEE 11g, there is lot of enhancements in services provided by OBIEE 11g and some changes in terminology is also there in OBIEE 11g.

Some important points/enhancements in OBIEE 11g when compared to OBIEE 10g are listed below
OBIEE 11g uses WebLogic Server as the application server as compared to Oracle AS or OC4J in OBIEE 10g.
The clustering process in much easier and automated in OBIEE 11g.
We can now model lookup tables in the repository.
The new UI called Unified Framework now combines Answers, Dashboards, and Delivers.
A new column called the hierarchical column in introduced.
BI Publishers is fully and seamlessly integrated with OBIEE 11g.
New time series functions PERIOD ROLLING and AGGREGATE AT are introduced.
In OBIEE 11g we can create KPIs to represent business metrics.
The aggregate persistence wizard creates indexes automatically.
The session variables get initialized when they are actually used in OBIEE 11g unlike OBIEE 10g where they were initialized as soon as a user logs in.
OBIEE 11g now supports Ragged (Unbalanced) and Skipped Hierarchy.
You can also define Parent-Child hierarchy in OBIEE 11g as well.
SELECT_PHYSICAL command is supported in OBIEE 11g.
In OBIEE 11g there are some changes in the terminology as well.
iBots are renamed as Agents.
Requests are renamed as Analyses.
Charts are renamed as Graphs.
Presentation Columns are renamed as Attribute Columns.
You can also refer http://gerardnico.com/wiki/dat/obiee/11g
Please give your suggestions and queries as comments
You might also like:

Oracle Fusion Basic......just for you all

Before we start with what oracle fusion really is and the magic it does let’s familiarize ourselves with the basic terminologies which we may have come across.

Oracle Fusion

An integration of oracle applications such as Business Suite, People soft, JD Edwards, Siebel, Retek, Stellent etc into a set of next generation application based on an open industry standards having based on Service Oriented Architecture is known as Oracle Fusion.

Oracle Fusion Middleware

The technical platform used to build the Oracle Fusion application is termed as Oracle Fusion Technical platform which together forms the Oracle Fusion Middleware.

Oracle Fusion Architecture

The blue print which holds the Oracle Application, middleware platform and grid technology as one entity describes the architecture of Oracle Fusion

The Below outline sketch describes in brief some left out details of Oracle fusion

The abbreviated coined firms are better knows as:

• OLM: Object Relational Mappers
• SOA: Service Oriented Architecture
• XML: eXtensible Markup Language
• SAML: Security Assertion Markup Language
• BPEL: Business Process Execution Language
• JFDP: Java Frameworks and Design Parameters

Let’s have a view of Products which are comprised in Oracle Fusion.

• JD Developer Top Link & ADF
• BPEL Process manger, SOA Suite, e-Business Suite
• Identity Management Suite
• BI Suite, Web Centre and Oracle Protocol
• Single Sign ON
• Grid Control

From the above points, we come across the different aspects of Oracle Fusion both technical and product wise. The whole laying of foundation stone for Oracle fusion has been done on the basis of Industry Standards working across the globe thus defining oracle technical foundation in a way so that Oracle customers understand the skill sets which their team will be supporting in current as well as in the times to come.

Oracle Fusion Components

The following are high level definitions of key technical components of Oracle Fusion.

Oracle JDeveloper - This Integrated Development Environment is the base development platform used by Oracle developers to build Oracle Fusion applications. JDeveloper contains interfaces for development with J2EE, SQL, PL/SQL, HTML, Web Services, SOA, JSF, ADF, etc. This IDE should be looked at as a development environment for developing database and Internet applications.

Java 2 Enterprise Edition (J2EE) – J2EE is an industry standard for developing enterprise multi-tiered applications. J2EE is an architecture and framework for enterprise wide applications. J2EE applications include JSPs, JSFs, ADF Faces, EJBs, etc.

Oracle Application Development Framework (ADF) – ADF is a J2EE development framework that is based upon best practice design patterns for building Web applications. ADF is based upon the Model-View-Controller that separates User Interface, Business and Data logic. J2EE frameworks can be complex and it can be difficult to determine how to organize different components. ADF helps organize J2EE components into a well organized Web application. ADF Faces provides a Web user interface similar to the Oracle Forms and Reports interfaces.

Top Link - Top Link is an Object Relational mapper that manages the communication between Java (object-oriented) applications and the Oracle database (relational).

XML - XML has become the universal language for transmitting data structures independent of the environment. J2EE, Web Services, SOA and BPEL use XML.

Web Services - Web (software) Services uses XML standards and transport

Communication protocols to exchange data between applications. Web services allow different types of applications to communicate. Web services are standards that define the semantics for how software communicates.

Service Oriented Architecture (SOA) -SOA is an architecture that defines how loosely coupled software services communicate with each other. SOA increases reusability that allows different software services to identify and communicate with each other.

Business Process Execution Language (BPEL) – BPEL is a standard for organizing reusable web services into more than one type of process flow.

Identity Management - Identity Management provides enterprise management of user identities across resources inside and outside the firewall.

Single Sign-On (SSO) – SSO provides unified authentication allowing a user to logon once and SSO will manage single sign-on capability across applications.

Grid Control – Oracle Enterprise Manager provides administration across the database and all middle tiers. Grid Control provides monitoring of databases, application servers, web services and applications.

Below is the pictorial view of the Oracle Fusion Middleware which also gives pictorial description of terminology as well as concepts of Oracle Fusion.

Gains from Oracle Fusion

While viewing the technical part of Oracle fusion one point which we can overlook is the gain which this tool will give us in the market. Whatever tools comes in or goes out even during its initial stage of development one thing which is kept in the mind during its development and execution is the target it will achieve to be short

• Is it really worth it to be launched?
• Does market and customer need it?
• Is it value for worth and will it achieve a good growth for a long period of time?

Well above are some of the main queries which is made standard before coming to a conclusion of any development to be taken place .Well, the benefit of Oracle fusion has already started being achieved which are Capacity for growth and change, Operating efficiencies and lower TCO, Better management of risk & compliance and Access to comprehensive, more timely information about people’s businesses, so they can make better decisions.

The on demand pathway to Fusion has the customers streamlining their business operations and adopting advanced technologies to gain competitive advantage in phases. As a trusted technology partner, Oracle Fusion is transforming the technology in lock step, supporting and enabling the business transformation at the customers’ pace.

Conclusion

Oracle Fusion tools are going to hide developers from a lot of the technical complexity behind Oracle Fusion. However, dependent upon the customizations made to Oracle Fusion applications, developers may need a strong understanding of the technical components of Oracle Fusion. There are three types of developers that need to learn the products in the Oracle Fusion Technology Platform:

Traditional Oracle Developers – Developers that have used Oracle Forms, Reports, Discoverer, PowerBuilder, Visual Basic, C/C++, etc. are going to need to learn the technologies supported in Internet development environments. Most Oracle developers are going to have to be knowledgeable with some or all of these technologies.

Traditional Oracle Apps Developers –Developers who has customized Oracle, Siebel, PeopleSoft, JD Edwards, Retek, and Stellent are not likely to hit the lottery jackpot, then learning the Oracle Fusion Technology Platform will give them an edge to hit the jackpot efficiently.

Internet Developers – Developers building Internet applications are likely to work with some or all of the products of Oracle Fusion. Internet developers may be working with Eclipse instead of JDeveloper, or Hybernate instead of Top Link or Web Sphere instead of the Oracle Application

Server. However the principles of Frameworks, ORMs, Design Patterns, J2EE, Managing Web Services, XML and SOA are still going to be technical areas that need to be understood. A consistent layout and look and feel is provided by Oracle. It is important to understand that components such as J2EE, Web Services, XML, SOA, etc are not just tied to Oracle. They are based on open standards. Skills in the technology are incredibly valuable in any Internet development environment. These open standard components are moving into your future like a freight train. They require skills that are going to be incredibly marketable and valuable in the future.

DW Schemas and the Facts and the Dimension Tables

DW Schemas and the Facts and the Dimension Tables….

DW Schemas

A Schema is a collection of Database objects like tables, views, indexes etc. The DW schema is designed based on the model of the source schema and the requirements from the users. There are number of other things that decide the design of a DW and can be classified in 2 categories:
Physical Design
Logical Design

Star Schema

This is simplest DW schema. It resembles a star with points radiating from the center.The center of the star is the Fact Table and the points of the star are Dimension Tables. A star schema resembles a Start Topology in networking and in this the Fact Table at the center joins to the individual Dimension tables at the corners of the star with only one join. Each Dimesion table is joined to the Fact table using the Primary Key and the Foreign Key join. The Dimension Tables are not joined to each other.
A Star Schema optimizes performance by keeping queries simple and providing fast response time. All the information about each row is stored in one row.

Snowflake Schema

This is a more complex schema as compared to a Star Schema and is called Snowflake schema cz its ER Diagram resembles a Snowflake. The Snowflake Schema normalizes dimesions to eliminate the redundancy which means that the Dimension data is grouped into multiple tables instead of a single table. While this saves space at the same time it increases the number of Dimension tables and hence more number of foreign key joins and hence complex queries and reduced query performance. In this theDimesion table is joined to another Dimension table.

Hybrid Schemas

These are the third type of schemas and are hardly used. These are a combination of number of schemas.

Now you must be inquisitive to know that what are the Fact and Dimension tables which i have used in my previous posts as well as the present post. So lets move ahead with that…..

Facts and Dimensions are the DW objects.

Fact Tables

The fact tables are large tables that store business measurements known as measures or facts. They typically contain facts and foreign keys to the dimension tables. 
Eg: We have Customer Dimension and Sales Fact. Then the Sales fact will contain the Sales information of the various customers like profit, total sales etc.
The fact tables generally contain facts at the same level of aggregation which means that all the facts present in the fact table are at the same level. To better understand this lets again take an Eg.
Now in the Sales Fact all the data that will be present will be based on the customer data, like a single customer A will have his profit or sales listed in the Sales Fact and same is the case with customer B and so on. Means the enitre data is at the same level.

3 types of facts:

Additive : Can be aggregated by simple maths calculation.
Semi Additive: Can b aggregated along some dimension and not along others.
Non Additive: Cant be aggregated at all.

Dimension Tables

Dimension attributes help to describe dimension value. They are normally descriptive, textual values. Several distinct dimension when combined with facts enable u to answer a business question. Each Dimension table has a Unique Identifier for each record which becomes the PK for the Dimension tables.

If Fact is an Entity then Dimension are the attributes that best define the fact.
Zafar.

Must Know Before you learn Oracle BI ....

2 common industry techniques viz. Datawarehousing & Dimensional Modelling. So i have brought a brief overview of whaht exactly is dimensional modelling(DM)…

So lets start….

Whats DM????

Dimensional modelling is a logical design technique used for DWs.

Lets understand it in a diff way. If a user want to c some report of dollar value with region for an eg. so what will he want to c???
He wud like to c a column dollar with region…
Based on the user requirement the data needs to be segregated in facts and dimensions and the data should have a proper relationship between the fact & the dimension so that the user can c the data is the desired format.

So, to segregate the data into facts and dimensions and to logically organize the data in a way so that the user can understand it is done in Dimensional Modelling.

Now people have a general tendancy of confusing this with the ER Diagrams, so lets c wht exactly are ER diagrams…

ER Diagrams is also a logical design technique but this technique is used in transactional DBs like OLTP. It aims at removing the redundancy and hence is best used for transactional queries as it makes transactions simpler and deterministic.

DM is a logical design technique which aims to provide a standard framework for a high query performance and is Dimensional in nature.

So, whts the relationship between a DM and ER diagram and how it takes the shape of DM???

Lets c how it happens…..

The key to understand the relationship between the DM & ER  is that a single ER diag. breaks into many DM diag.
Think of a large ER diag. having all the business processess & relations of a company. Now

1) Separate the ER diag. into separate bnusiness processes and model each separately.
2) Identify many to many relations in ER diag. which have numeric or additive nonkey facts in them as designate them as facts.
3) Denormalize the rest of the tables with single keys (dimension tables) and join them to fact tables.

Confirmed Dimension : When a dimension table joins to more than 1 fact tables it is repsesented in both the schemas and is referred to as Conformed between 2 dimensional models.

The above process can b better understood by the below images of ER Diag. & DM Diag.

ER Diagram

DM Diagram

This is how we result in doing the DM and create a DW from an OLTP systems…

OBIEE Architecture in simple lines

The below diagram shows the basic architecture of OBIEE and its components:

Now, first of all lets understand the flow in which a request flows from Client to Data Source.

If a client runs a report, the request first goes to the Presentation Server and then it gets routed to the BI Server and then it gets further routed to the underlying  Database or the data source.

Client -> Presentation Server -> BI Server -> Data source

Now, the request is routed back through the similar route to the client. Which means, the data is fetched from the Data source and it gets routed to Presentation server through BI server and then to the client.

Client <- Presentation Server <- BI Server <- Data Source

The above flows provide a very basic idea of how the data is fetched and showed in a report in OBIEE.

Now, lets understand it more properly by dividing the above diag. into segments and then :

1) Client and User Interface

2) Presentation Server & Presentation Catalog

3) BI Server & Admin Tool

4) Datasource

Client & User Interface: This level has the UI of OBIEE which is accessible to the clients and users. The OBIEE UI has several components like OBIEE Answers, Interactive Dashboards etc.

• Oracle BI Answers is a powerful, ad hoc query and analysis tool that works against a logical view of information from multiple data sources in a pure Web environment.
• Oracle BI Interactive Dashboards are interactive Web pages that display personalized, role-based information to guide users to precise and effective decisions.
• BI Delivers is an alerting engine which gives users flexibility to schedule their reports and get them delivered to their handheld devices or interactive dashboards or any other delivery profile and helps in making quick business decisions.

In simpler terms we can say that, this is a web application which is accessible to the users for preparing their reports/dashboards and do Ad-Hoc reporting to cater the business needs.

We will continue with the other segments in the upcoming posts. Till that time if you have any questions or comments they are most welcome.

Presentation Server & Presentation Catalog:

The BI Presentation server is basically a web server on which the OBIEE web application runs. It processes the client requests and routes it to the BI Server and vice versa. It can be deployed on any of the following IIS or Oc4j. It makes use of the Presentation catalog which contains the aspects of the application.

The Presentation catalog stores the application dashboards, reports, folders and filters. It also contains information regarding the permissions of dashboards & reports created by users. It is created when the Presentation server starts and can be administered using the tool called Catalog Manager.

In other words we can say that the Presentation server and the Presentation Catalog are together responsible for providing the clients with a web server on which the web application runs and also administers the look and feel of the User Interface.

BI SERVER AND ADMIN TOOL

BI Server is a highly scalable query and analysis server.  It is the heart of the entire architecture. It efficiently integrates data from multiple relational, unstructured, OLAP application sources, both Oracle and non-Oracle.

It interacts with the Presentation server over TCP/IP  and takes the reporting request from the presentation server. Then the BI server processes the request and form logical and physical queries(in case of database as data source) and this physical query is sent to the underlying data source from which the data is processed. The BI Server interacts with the underlying database using ODBC. Hence, the entire processing of request is done by the BI server.

In the above paragraph I have mentioned that the BI server creates a logical and physical query. But how will the BI server generate this query?? How will the BI Server know what all joins need to be used?? I guess all these questions must be coming to your mind. So, lets understand the underlying process..

The BI server makes use of the BI Repository for converting the user request into logical and physical queries. The BI Repository is the metadata using which the server gets the information of the joins and the filters to be used in the query. It is the backbone of the architecture.

Now, this is the place where all the modelling is done and the role of OBIEE developers come into picture  . The BI Repository is created using the Administration Tool. The repository contains three layers: Physical, BMM and Presentation Layer.

Physical Layer: Contains the tables imported from the underlying DB with appropriate joins between them.

BMM Layer: This is the Business Model layer and hence all the Business logics are implemented on this layer eg: Calculation of %age Sales, Revenue etc.

Presentation Layer: As the names specifies this layer is used for Presentation of required tables and columns to the users. The columns pulled in this layer are directly visible to the users.

Where BI Server and Admin Tool come in picture???

Now, when the users log into the BI Answers i.e the user interface, they see all the columns that are pulled on the Presentation Layer in the Repository. They choose the desired columns from there and click results button to view the report. After that the request is sent to the BI Server through the Presentation server, the BI server makes use of the BI Repository to formulate a query out of the requested report based on the joins and tables specified in the repository. This query is sent to the underlying DB and hence results are fetched.

4th segment DataSources.

This is a rather simple one as we all know till now that OBIEE is a reporting tool and works on data from  underlying Databases, so here DataSources are the underlying Databases with which the OBIEE server interacts. OBIEE is a very smart tool and it has got the capability of reporting on multiple Databases and also multiple types of Databases like XML, Oracle, SQL Server etc.

Now, in the previous posts you have seen what is an OBIEE Repository and what is the Physical Layer and what are connection pools. I am reminding you of these things because our current segment is based on this and we will see how.

Now, when we design the OBIEE Metadata or repository for reporting, we import the tables on which we need to perform reporting into the physical layer from the respective DBs. And then we apply appropriate joins between the tables and furthur pull them to BMM and then to Presentation Layer for reporting.

 The question that comes out here is “How does the BI Server interacts with the underlying DBs for showing the reports???”

The answer to this question lies in the Connection Pools. If we open the Connection Pool we can see that we need to select the Call Interface, give the name of the DSN, give a Username and password. These things help up to connect to the Database.

Call Interface – There is a drop down from where we can select the appropriate Call Interface. Some examples are ODBC, OCI etc. Both ODBC and OCI can be used for Oracle. The main difference between using them is, In ODBC we need to create a DSN in the system where the server is installed but OCI is a native DSN and we can use it directly without creating the DSN in the system.

DSN- This is the name of the DSN which OBIEE uses to connect to the underlying DB.

Username- The user with which OBIEE connects the DB. Generally the user used for reporting should only have the read priviledges on the DB.

Password- Password of the user with which OBIEE connects to the DB.

 Now, when a user runs the report in Answers the OBIEE server accesses the DB using the connection pool with the specified Call Interface and username and returns the data.

How does the BI server takes care of a report formed using columns and tables from multiple DBs???”

As I have told you earlier also that BI server is very intelligent and is built in such a way that it can process request formed form multiple DBs. When the user generates a report involving multiple DBs, the request navigates to the Navigator section in the BI Server which checks the underlying DBs with which OBIEE needs to interact to. Then the BI server generates separate queries for the DBs and fire them on the respective DBs. Then it fetches the data from the underlying DBs and combines the result set in its own memory and displays the result in the report.

With this post we have covered the 4 segments of the OBIEE Architecture. I hope this will help you alot in understanding the BI Architecture and also in understanding the OBIEE behavior  In the upcoming posts I will also try to go into the details and throw some more light on the BI Server components.

Open RPD without password

You can follow the below steps to open the RPD without a password in offline mode:

• Copy the RPD to your local system which you want to open.
• Make sure that the BI Server is not running.
• Navigate to the NQSConfig.ini file on your local system. Generally its present at “<OracleBIHome>\server\Config” .
• Under the Security section in the NQSConfig.ini file, search for the below text and uncomment it.

              “AUTHENTICATION_TYPE = BYPASS_NQS;”

• Save the file and try opening the RPD in offline mode without giving any password.

 The default Authentication type for OBIEE is NQS but when we uncomment BYPASS_NQS it bypasses the default authentication and enables us to open the RPD without a password.

 It can also be used for resetting the password of the RPD or sharing your RPD with someone without sharing the credentials.

To revert it back, modify the NQSConfig.ini file and comment out the AUTHENTICATION_TYPE = BYPASS_NQS again. Restart the BI services.