Everything Oracle

Introduction

In its early days, Oracle just offered a database and some development tools, such as SQL*Forms and SQL*Reports, tools that allowed clients to build bespoke applications from scratch. Then it decided that there was money to be made by providing tailorable applications aimed at the ERP market, and what we now know as the Oracle E-Business Suite (for example, Oracle Financials and Oracle HR) was born. The E-Business Suite consists of a collection of OLTP-type applications for data entry, together with a consolidating reporting tool, Daily Business Intelligence (DBI) – so called because it allows up to date reports to be generated on a daily basis. In simple terms, DBI works as per the following diagram:

E-Business Suite Consolidated Reporting using DBI

Now DBI may offer an adequate solution if all your corporate data is stored in Oracle’s E-Business Suite. However, if yours is a large organization then it’s quite likely, as a result of acquisitions and mergers, to sport a collection of ERP applications from different vendors. Even if all your company’s own data is held in the E-Business Suite, you may well source data, such as marketing data, from external sources and wish to consolidate that data with your own internally generated data for reporting purposes.

So when it comes to consolidated corporate reporting DBI is unlikely to offer a viable solution. Enter Oracle Business Intelligence Enterprise Edition (OBIEE) stage left:

Corporate-Wide Consolidated Reporting using OBIEE

OBIEE allows data from disparate sources – the E-Business Suite, other Oracle ERP products, common 3rd party ERP products, and generic data sources – to be consolidated together for the purposes of corporate reporting. If you like, it’s DBI “on steroids” with a global, cross-platform and cross-vendor reach.

Daily Business Intelligence

Before comparing OBIEE and DBI in more detail and examining how they work together as part of Fusion Intelligence, let’s look first at the architecture of DBI. While it’s an integrated product, running on a single database instance, it’s useful to think of it as consisting of three different components:

Daily Business Intelligence - Architecture

Firstly, we have an Application Component, consisting of the set of OLTP applications that are part of the E-Business Suite (EBS).

Summarized data for reporting purposes is held in a set of Base Summary Tables, and this data is summarized still further for enhanced query performance using Oracle’s Materialized Views. At intervals specified by your DBI Administrator, typically once per day, a Request Generator pushes changes to the OLTP application tables into the Base Summary Tables and the Materialized views to keep them up to date. This is the type of functionality that we normally find in a data warehouse, so this functionality constitutes what we might call the Data Warehouse component of EBS/DBI.

Finally, we have the Reporting component of EBS/DBI. This component consists of a Rendering Engine that imports metadata containing report definitions. The Rendering Engine accepts requests from the web browsers of end users and generates the requested reports and dashboards by drawing on data from the Base Summary Tables and Materialized Views and by formatting it using the instructions contained in the metadata.

Interfacing OBIEE to the E-Business Suite

The following diagram compares DBI at a standalone reporting tool (on the right), and DBI as a component data source in an OBIEE reporting solution (on the left):

A Comparison of OBIEE and DBI Reporting Architectures

OBIEE hooks into the Data Warehouse component of EBS/DBI, the part that contains the aggregated data. Note that OBIEE’s generic reporting architecture could also be made to hook directly in to the OLTP tables in the EBS Application Component, but this would lead to very inefficient queries due to the large volumes of application data that would have to be summarized in real time in response to each OBIEE query.

While the DBI Data Warehouse component could be the only source of data for OBIEE queries, in general OBIEE will also be pulling in data from other data sources, either to answer independent queries, or to answer “federated” or “heterogeneous” queries, as when, say, some sales data is held in EBS and some is held on other ERP platforms.

The DBI Rendering Engine and its metadata are redundant as far as OBIEE is concerned. And note the difference in architecture. The functionality performed by the Rendering Engine is performed in the case of OBIEE by two independent processes, the BI Presentation Services process and the BI Server process (this diagram provides a highly simplified view of the OBIEE architecture; OBIEE makes use of many other processes, all of which are deployed in the form of multiple instances to facilitate scalability and fail-over). Similarly, the metadata used by the DBI Rendering Engine is divided into two separate data stores in the case of OBIEE, a Repository which contains the mapping needed to create a unified semantic view of corporate data, and a Catalog, which contains definitions of the reports and dashboards displayed to end users by the BI Presentation Services. This division of labour lends considerable flexibility to the OBIEE architecture, allowing, for example, the BI Server to serve data to third-party reporting software from different vendors, instead of, or as well as, the BI Presentation Services.

Fusion Intelligence

So, finally, to Oracle’s Fusion Intelligence. How does it differ from OBIEE? Fusion Intelligence consists of three components:

E-Business Suite

OBIEE

Pre-built Repository and Catalog

Now if you were to license just OBIEE and the E-Business Suite from Oracle, then you could connect them as shown in the diagram in the previous section. But OBIEE is not supplied with any repositories or catalogs (apart from demonstration versions), so you’d have to construct the repository mapping for the E-Business Suite and the catalog that defined the reports and dashboards that you wished to view from scratch. The extra that you get with Fusion Intelligence is the pre-built repository and catalog (just as you get pre-built metadata in the case of DBI-based reporting). If you look at the many thousands of items contained in the repository supplied with Fusion Intelligence, you’ll appreciate that a very considerable development effort has gone into its creation. So if you want to use OBIEE with the E-Business Suite then licensing Fusion Intelligence makes very good sense.

At present, Oracle’s Fusion Intelligence offering only supplies a pre-built repository and catalog to connect to the E-Business Suite. In the future we can certainly expect this offering to be expanded to include Oracle’s other ERP applications, as well as those of third party competitors. When we reach this point then Fusion Intelligence will begin to bring substantial benefits to those organizations with multi-vendor ERP applications (this form of integration is already available with Oracle BI Applications, but this is a more overarching solution that involves a pre-built data warehouse, the Business Analysis Warehouse (BAW), together with pre-built ETL by Informatica and ETL Orchestration by DAC).

But that’s what we can expect in the future. What about the present? Does Fusion Intelligence have any advantages over DBI in the meantime?

Well, OBIEE makes it easier to customize existing reports and to generate new reports than DBI. But this facility will only be of value if you feel that DBI reporting is too inflexible to meet your current reporting requirements.

The main advantage that OBIEE offers at present is its ability to extract data from other data sources as well as from the E-Business Suite, and to display this data as separate reports and dashboards or as data merged into existing reports and dashboards. The downside to using OBIEE in this manner is that you’ll have to modify the repository and the catalog to accommodate the additional functionality. Now if all these other data sources are bespoke or are not supplied by mainstream ERP vendors, then you’ll have to hand-craft the changes in any case, so you might as well get started. However, if the data sources you need to integrate belong to well established ERP applications, such as PeopleSoft, then it just might be worth your while waiting until Oracle does all the hard work for you. Then you can license the fruits of Oracle’s labour at a fraction of the one-off development cost.

You’ll find details on the implementation of Fusion Intelligence here.

Everything Oracle

Home

Everything Oracle