Sunday, October 14, 2012

OBIEE Architecture in simple lines

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.