The blog for Oracle Data Integrator ( ODI )

Scenarios, a lot in the first delivery makes maintenance very simple!

Hi Everyone!

First I wish to all of you a really Happy New Year! I hope that 2011 can be the best year ever to all of us!

Second, sorry, sorry and sorry. We “abandoned” our blog this last few weeks. I got a lot of new responsibilities on my formal job and Dev was in vacation with his family. We are going to try to be more present from now forward.

Third (and last) let’s talk about scenarios!

I created this title “Scenarios, a lot in the first delivery makes maintenance very simple!” in the hope of a full understanding about what this post is in just one phrase once I would like that after we finish to discuss it you can tell me if the title is right or not…

I Oracle Data Integrator, our famous ODI, is very common to develop all objects that you need to your integration and, at end of the development, add all of these at a package, create a scenario and that is it. Test and go to production.

That is the common way in all ODI environments that I saw until today… let’s discuss this.

When we are developing a it’s normal to have several tables to load in some order (parents, children, etc), procedures to performs some “not interfaceble” task and variables that uses code (refreshing type). Then, all we do is add all of this in a package, generate de scenario and our development is done.

OK, now let’s think about it from the Software Development Life Cycle (SDLC)  perspective, I mean, everything that is developed will get some maintenance in one of his “pieces” some day.

As we change just one piece from all our package, of course we should test just that piece right?

NO!  And here is the problem!

Who can guarantee that none of the others pieces (or ODI objects) was changed? In fact, using a trusted SDLC, you need to execute the complete test plan (the same that allows the first delivery) once all code was “compiled”, I mean, regenerated (in ODI terms).

Do you agree?

And if we split the development in small pieces of scenarios, as small as possible, even at object level (as we can generate scenarios from objects ) and then create a package (or packages) that orchestrate the execution of this small pieces????

Of course that the first delivery will have a lot of scenarios to be imported at production but when some change is necessary you can update only the relevant code and, too, test only it.

In this way your SDLC will get less errors and the cost (HR, Financial, Hardware, etc) of tests will decrease substantially and plus, you can always re-use any of the object scenario.

If you pay attention, you will see that we are talking about the old concept of Object Orientation, nothing new.

And now, what do you think? Is the title right? 🙂

A tip to use this approach is to have the Operator (scenarios tab) organized in folders. This will avoid the endless list of scenarios and brings organization to the environment.

Well friends, that’s all for now. I hope you keep traking us!

Once again, Happy 2011!!!!

Cezar Santos


  1. Hi Devendra,

    Also the PKG_DETAIL comes in a tree structure. The format got changed once i have sent.


  2. Yes Devendra, That is what i am looking for.


  3. Hi Experts,

    How to get the relationship between scenario and step from odi repository?

    For example,
    Scenario A consist of 2 scenarios AA and BB, which is scheduled with odi agent every hour.
    Scenario AA consist of step AA1 and step AA2.
    Scenario BB consist of step BB1 and step BB2.

    How could I get the tree of scenario A from odi repository? Like this:

    One more Example :
    There is a package “PKG_DETAIL” which have lot of steps and scnearios mapped. One of the scenario (called “Load DETAIL1”) from the mapping calls another package scenario “PKG_FR”.

    We will have the tree as shown below,

    PKG_DETAIL (root) – |-***
    |- PKG_FR |- v_fr1_user
    |- v_fr2_user
    |- p_load-fr
    |- p_fail_fr

    What I want to know is how to get this tree from ODI Repository, only with SQL query. And the output could like this:
    column1 column2 column3
    ——— ———– ————
    PKG_DETAIL PKG_FR v_fr1_user
    PKG_DETAIL PKG_FR v_fr2_user
    PKG_DETAIL PKG_FR p_load-fr
    PKG_DETAIL PKG_FR p_fail_fr

  4. Hi,
    you forgot to mention that source codes for Scenarios must be kept in safe place, internal versioning or external, but to be available on change moment to be consistant with what is in PROD

  5. Hi Cezar,

    The title seems to fit the blog post perfectly. I am actually implementing ODI this year, migrating from our old data warehouse tool. Our approach will be just as you described – many scenarios built and executed by larger packages. I’m glad this is the recommended way to do it!


    Michael R.

Leave a Reply

Required fields are marked *.