Table of contents for Architecture
- Insight of OBIEE Architecture
- Insight of OBIEE Architecture-II
- Insight of OBIEE Architecture-III
- Insight of OBIEE Architecture-IV
Hey Friends,
We have been discussing the OBIEE Architecture and we have covered 3 segments. So, here I am with the 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.
The next question is “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 intellegent 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 behaviour. In the upcoming posts I will also try to go into the details and throw some more light on the BI Server components.
Posts
