Oracle Data Integrator with OBIA 11.1.1.7.1 --Migration Issues.

Dt:19 March 2014


The honeymoon is over literally.Just when you were close to giving ODI the best ETL tool for OBIA award.They have goofed up.And Big time.

ODI-23040 -->this is the error which I get when I am trying to import my code from one environment to another.
No Rhyme no Reason. Guess it feels good to be a developer at Oracle when they are told never let the end user know what the error is.Let them come to us and beg for support.

But seriously for something as simple as migrating code from one environment to another which Informatica does so efficiently .I had to go through 100s of documents advising me how to use Internal Ids .What these internal Ids mean.How ODI stores this .......& so on....so forth..... .

I mean common which developer would share this information to his customer that this is how we store our objects and you have to change your backend Ids for our migration to work.

I understand that ODI was designed with another view of code migration .But Oracle being the business leader should have known for sure that the three tier architecture of DEV, QA & PROD is how projects are executed in the real world & this is how they should have built the migration module.

For now hope for those guys at Oracle Support to come out with a meaningful answer.It sucks.But yes its business !!!

How to add Custom PLP ,SDE & SIL interfaces to ODI load Plans in OBIA 11.1.1.7.1

Dt: 15 March 2014

Well its easy.

Of the many things you would like to do to get this done.Here are a few.

Make  the flex fields on the custom tables in Models to  point to fact group --> X_CUSTOM_FG. This lets ODI know all your custom fact tables.
Create foreign keys in ODI to the dimensions attributed in your custom facts.
This helps in understanding dependencies.

Just like you would add Informatica sessions to the DAC task lists.
Add the ODI scenarios into the BI Apps Load Plan provided Out of The Box.
You need to add your scenarios to the X_CUSTOM Facts, X_CUSTOM Dims in the LOAD PLAN DEV components.
There are seperate classifications for SDE,SIL & PLP.

Unfortunately once you go to the PLP section here you will not find the custom groups available.
No worries just create your own custom Load plans here within the parallel steps.

Once you have added your scenarios those will reflect in the new load plan done using custom fact group(X_CUSTOM_FG).

For PLP you have to add your newly created load plans into the  LOAD PLAN SYSTEM components.
This is a small piece of wiring which has to  be done.This was left unanswered in the documentation.

For that matter ODI with OBIA is like a new game on the blocks.Steps & rules provided for most of the things but then some hidden secrets left for you to explore.


Seems like a blockbuster so far.

Moving on with Oracle Data Integrator for OBIA

Dt:23 Feb 2014

Its been a roller coaster of a year so far on the technical front.Two months gone by and with a young team conquering the world of OBIA with ODI for data support has been challenging to say the least.

When I started with ODI I had my reservations about how this tool would match up with Informatica which for so long has been taking on the burden of building the  OBAW on its broad shoulders.My first hunch was that ODI would fail and fail miserably at that to make an impact.

As the days have passed by I have seen no major upsets  though and the project has been running smoothly as if we never migrated from one ETL tool to another.But there are differences of course and ones which you have to get used to as time goes by.

For an Informatica developer working on  OBIA projects, moving into the world of ODI .I would say that things are not that bad as they seem .They probably are a lot better.

Some of the comparisons that I can make now that I have worked for some time on ODI are,

For starters you do not have to write your queries.You got to validate them of course.

Odi has flows for everything so your multilevel lookups in Informatica would turn into two yellow interfaces in ODI. As the lookups are done on the database itself the query has to be generated as either a subselect or a join clause.Of course you need to be your judge as to what design you would prefer.

Another interesting thing that comes to mind is that the performance of ODI depends on the performance of your database as well .A slow source database may make you  change your design .As you have the luxury of moving transformations to a quicker target database.

Load plans are generated in the BIACM .Need to look into more details as to how we can customize them.

Overall on the design front ODI seems to rock it .The next challenge seems to be in how it will be able to handle environment migration.

But I can surely say that  ODI with OBIA is not going to be a let down for Oracle