Statement of Direction for Oracle Business Intelligence Analytics (OBIA)

Last week Oracle released a Statement of Direction (SOD) for Oracle Business Intelligence Analytics (OBIA). The message from Oracle to their Customers is clear; Move away from OBIA 7.9.6.x and move to OBIA 11g, either in the Cloud or On Premise.

Let us have a look what the actual message is. Find below a picture would find in a lot of the current Oracle presentations regarding Oracle Business Analytics. It’s shows you Oracle’s Business Analytics Strategy

Oracle Business Analytics Strategy - 2014Oracle delivers ‘Any Data’ via a ‘Full Suite of Analytic Tools’, Pre-Configured in ‘Packaged Analytic Applications’, Engineered together on Exalytics (one of Oracle’s ‘Engineered Systems’)

Oracle delivers Packaged Analytic Applications in roughly two different flavors:

  • Informatica 7.9.6.x
  • ODI 11g

There will be no more upgrades on Oracle BIA 7.9.6.x (Informatica release). A few months ago there was a rumor that there would come an Oracle BIA 11g (Informatica release). This is not going to happen.

What are the options?

If you read the SOD for OBIA, existing Oracle BIA 7.9.6.x-Customers are left with three options:

  1. Remain on Oracle BIA 7.9.6.x
  2. Move to ODI 11g
    • New separate instance
    • Migrate to a new instance
  3. Move to the Cloud

Remain on Oracle BIA 7.9.6.x

Remain on Oracle BIA 7.9.6.x

If a client wants to stay on Oracle BIA 7.9.6.x, please check Oracle’s Lifetime Support Policy. You will find the Oracle BIA Lifetime Support Details under the Oracle Business Intelligence EE Releases.

OBIA Lifetime Support - 2014

There are three different Support Levels.

  • Premier
  • Extended
  • Sustained

Check the Oracle Software Technical Support Policies for more details about these Support Levels.

Of course if you want to benefit from new content and new functionality, its better to choose one of the two following options.

Check the Oracle picture below for the OLTP Coverage for OBIA

Oracle BI Applications OLTP Coverage for

Move to ODI 11g

Move to ODI 11g


Move to ODI 11g and benefit from:

  • New Content
  • New Adapters
  • Common Enhancements

Prebuilt Solutions for Orale eBS, PeopleSoft, Siebel, JD Edwards, Fusion Applications, etc.

Move to the Cloud

Move to the Cloud

There will be different Cloud offerings for OBIA.

  • Oracle Transactional Business Intelligence for Oracle SaaS Applications
    • OBIA embedded within every Oracle SaaS Application (CRM, HCM, Finance, Supply Chain, etc.)
  • Oracle Transactional Business Intelligence – Enterprise

Global Currencies in Oracle BIA

If you read the Oracle Documentation for Oracle BIA (, you could find the following; “Currency conversions are required because your business might have transactions involving multiple currencies. To create a meaningful report, you have to use a common currency.”

Oracle BIA stores amounts in the following currencies;

– Document Currency –> Currency of the actual Transaction (Can vary in a multinational organization)
– Local Currency –> Currency defined in the Ledger
– Global Currency –> Defined in the DAC

You can use a Global Currency if you want to report all the different Currencies in one Global Currency (eg. ‘EUR’, or ‘USD’). Oracle BIA for Oracle eBS is able to report in 3 different Global Currencies. If you use Oracle BIA for CRM, you are able to store an additional two Global Currencies. You define the Global Currencies in the DAC.


You will have to define a Global Rate Type for each Global Currency as well.

– $$GLOBAL1_RATE_TYPE (for the first global currency)
– $$GLOBAL2_RATE_TYPE (for the second global currency)
– $$GLOBAL3_RATE_TYPE (for the third global currency)

DAC - Currency - Rate - Parameters

You would use the above DAC Parameters for a Document Currency to Global Currency Conversion ($$GLOBALn_CURR_CODE & $$GLOBALn_RATE_TYPE). The $$DEFAULT_LOC_RATE_TYPE-Parameter is used for the Document Currency to Local Currency Conversion.

To get a better understanding about how these Conversions work, you should try to understand the; ‘MPLT_CURCY_CONVERSION_RATES’-Mapplet. The purpose of this Mapplet is to; “Find the Conversion Rate for a given Currency Code, Rate Type and Exchange date. You should find this mapping in the Out-of-the-Box SILOS-Folder.

Informatica - Mapplet - MPLT_CURCY_CONVERSION_RATES - Diagram

In the ‘MPLT_CURCY_CONVERSION_RATES’-Mapplet you will find an Expression; ‘EXPT_CALC_EXCH_RATES.’ This ‘EXPT_CALC_EXCH_RATES’-Expression is responsible for the actual Conversion (Calculation).


There are a few other Mapplets with similar name and functionality compared to the ‘MPLT_CURCY_CONVERSION_RATES’-Mapplet.

The Conversion for eg. the GLOBAL1_EXCHANGE_RATE basically consists of three components:

– Input from a Mapping (eg. SIL_APInvoiceDistributionFact – W_AP_INV_DIST_F)
– Lookup to the W_GLOBAL_CURR_G-Table
– Lookup to the W_EXCH_RATE_G-Table

Informatica - Mapplet - MPLT_CURCY_CONVERSION_RATES - EXPT_CALC_EXCH_RATES - Calculate Rate

Input from a Mapping

The ‘MPLT_CURCY_CONVERSION_RATES’-Mapplet is part of a Mapping. Let’s take the ‘SIL_APInvoiceDistributionFact’-Mapping which populates the ‘W_AP_INV_DIST_F’-Table as an example.

Informatica Mapping - SIL_APInvoiceDistributionFact

Lookup to the W_GLOBAL_CURR_G-Table

The ‘SILGlobalCurrencyGeneral_Update’-Mapping in the ‘SILOS’-folder stores the values of the  to the $$GLOBALn_CURR_CODE-, and $$GLOBALn_RATE_TYPE-DAC-Parameters in the W_GLOBAL_CURR_G-Table.

W_GLOBAL_CURR_G - Currency - Rate

As you can see the values in the W_GLOBAL_CURR_G-Table, match with the values in the DAC-Parameters. Of course you can setup these Parameters anyway you like.

Lookup to the W_EXCH_RATE_G-Table

The W_EXCH_RATE_G is a Table which resembles the GL_DAILY_RATE-Table in Oracle eBS. If the contents of this Table are incomplete or incorrect, the whole setup of the different Currencies is useless. The ‘LKP_W_EXCH_RATE’-Lookup is used to find the Conversion Rate for a given Currency Code (‘From’ and ‘To’) and Exchange Date .

Informatica - Mapplet - MPLT_CURCY_CONVERSION_RATES - LKP_W_EXCH_RATE - Complete


If you query the  ‘W_AP_INV_DIST_F’-Table an you find the ‘GLOBAL1_EXCHANGE_RATE’-Column empty for a certain Transaction, the above should help you find out the reason.

Good Luck.

The Fit of Oracle Analytical Applications

My colleague Ronald Kok wrote a blogpost yesterday. Next to Oracle BI Applications for ERP / CRM (OBIA), Oracle offers BI Applications for the industry as well. I agree with Ronald, that there is nothing wrong with the technology. Still there are (a lot of) Oracle Analytical Applications (OAA) projects which struggle to succeed.

In my experience one of the major reasons of these struggles is the fact that a lot of Implementation Partners refuse to implement OAA like it is meant to be. They just start customizing and before you know it, you are no longer looking at OBIA, but you have built your own custom solution. I don’t have anything against custom solutions, but if you have spent a large amount of money on buying OBIA,  then it’s sin if you do not use it.

I do not have any experience with the Industry BI Applications. From my on-hands OBIA implementations, I know for a fact that you should always start with a Vanilla Implementation. Take your time to follow the Configuration Guide. Include Functional expertise in the process of configuring OBIA. If you do the configuration properly and run your first load, you will see the out-of-the-box dashboards and they will show data. Not just data, but the data of the source system OBIA extracts it’s data from.

From this point on, you will be able to assess what OBIA can do for your organization. Perform a Fit/Gap analyses, but focus on the Fit and not solely on the Gap. Oracle BIA - IcebergIn a lot of Oracle BIA presentations you will see the picture on the left side. What you see is definitely not only what  you get. The top of the iceberg could be compared with the dashboards and reports of OBIA. The OBIEE metadata and the ETL (DAC & Informatica or ODI and the Web Configuration Tools) represent the remainder of the iceberg.

A Gap does not necessarily mean that you have to build a whole new customization or dig your way through the existing ETL. It’s quite possible that just changing an out-of-the-box analysis would be sufficient. I have mentioned it earlier, the out-of-the-box Balance Sheet, can easily be customized by using GL Segments instead of the Group Accounts. The GL Segments are out-of-the-box functionality (just some configuration) as well. It’s ‘just’ a matter of replacing fields.

Therefore I recommend everybody to take the time to investigate what’s actually in OBIA. Fit/Gap analyses will take time, but building a customized solution will take time too.