Oracle Transactional Business Intelligence (OTBI) - Technology Overview Part I

Oracle Transactional Business Intelligence(OTBI) is one of the reporting tools that Oracle gives access to it's customer for their reporting in SaaS model. Like me many of the people are coming from eBusiness Background. When they see SaaS access constraints they will wonder what this OTBI is.

OTBI is exclusively for Oracle Fusion Applications. It has been designed to meet real-time, ad-hoc, current state reporting and analysis of operational data. It combines Oracle ADF and OBIEE technologies. Below is the picture which tells everything about it.

OTBI Architecture

As can be seen from the picture that OBIEE uses ADF Model Layer View Objects for its meta data source. In ADF Model Layer Entity Objects(EOs) are created and VO objects are created from these EOs. These VOs represent the SQL query for the physical layer in OBIEE. These view objects simplify access to data and abstract the underlying data model and business logic complexities. By doing this oracle has made sure to keep only one source of truth. Changing business logic in one place makes it available in Fusion Applications as well as in OTBI.

Another fact is that OTBI and OBIA use the single logical definition of the object in the OBIEE Business Model and Mapping layer. This is a unifying factor that allows users to see the Oracle Fusion applications data from either a transactional or a historical perspective. Most of the common dimensions and a few facts in the Business Model and Mapping layer of Oracle BI repository are shared between Transactional Business Intelligence and BI Applications.

Once you open the RPD file in OBIEE Administration Client you will see that there are three connections of type OracleADF11g. Financials, Oracle Fusion Supply Chain Management Connection Pool, Projects, and Incentive Compensation use the FSCM connection; CRM and HCM use thier own connection Pools. So basically they are

1. FSCM
2. CRM
3. HCM

Marked in RED are those three connections. If you double click any one of those connections you will see the something similar to the next screen.

This is what tells OBIEE to query ADF View Objcts in stead of tables. There is also a concept of SQL Bypass. This extracts the SQL query from the VOs and executes them in the database. In this process it reduces the burden of executing the VO objects.

Each of the three connection pools has one connection pool containing Oracle ADF server connection information, such as application server, application module name, and user information. Oracle BI Server uses this information in connecting to the data source.

Let's see how does SQL bypass works. Following is the picture from Oracle documentation which explains

You must set the SQL Bypass Database Option. To do that double click HCM(oracle.apps.hcm.model.analytics.applicationModule.HcmTopModelAnalyticsGlobalAM_HcmTopModelGlobalAMLocal)  in Physical layer; Click on Connection Pools Tab, select the Connection Pool and click on edit.

Once you click on edit button the next screen will pop up

Select the Miscellaneous tab.
Select Set.
Available database connections are displayed.
Select the database connection that is pointing to the Fusion Applications database, as shown in Figure, Connection Pool Miscellaneous Tab.
Select OK.

Now let's see how the View Objects are specified in the three connections - FSCM, HCM & CRM. The next screen will give a snapshot of some view objects in HCM connection

View objects are named using the following convention, which can help in tracking back to the corresponding module in Oracle Fusion applications:

Global Application Module Name. Sub-Application Module Name.view object-Name.For example:
HCMTopModelAnalyticsGlobalAM.AnalyticsServiceAM.CurrenciesPVO, where HCMTopModelAnalyticsGlobalAM is the application module name, AnalyticsServiceAM is the sub-application module name, and CurrenciesPVO is the view object name.Similarly, all the alias physical tables are named as <Dim/Fact>__VO-Name_Role.
The next screen shows this.

This is all about Physical Layer in RPD. The Business Model and Mapping layer is the one where business or logical model is written. It is also the layer where Mapping between Model and Physical layers schemas are specified. Business Models contain dimensions, facts (Logical Tables in OBIEE) and hierarchies (Logical Dimension in OBIEE).

All OTBI objects are part of Business Model Core, which is common model for both OTBI and OBIA.

Let's stop here today. At the end of this series I will show how to get RPD File and and open it OBIEE Client tool.

SO Till now you have got idea about the OTBI Architecture. In the next few post will cover Model Layer & presentation layer and will show on the fly how to create OTBI report from OBIEE.

Keep reading...









Cheers..............................