ODIExperts.com

The blog for Oracle Data Integrator ( ODI )

Repository Architecture – Just one Master – Part 2

Hi Everyone,

 Let me continue to discuss about repository architecture…

In the previous post (Repository Architecture – Just one Master – Part 1) we saw a proposal of architecture with one Master repository (MR) and just one Work Repository (WR).

That first discussion was more about how important is to have the best backup policy possible and now I will present architecture for environment with one MR.  We will discuss more than one MR in a future post.

Let me show the suggested design for this:

A complete design for an ODI Environment

A complete design for an ODI Environment

 As you can see, there are 3 environments

  1. Development — GREEN
  2. Test                   — YELLOW  
  3. Production    — RED   

But be careful:

THOSE ARE SYSTEMS ENVIRONMENTS.
ALL ODI REPOSITORIES ARE AT PRODUCTION DATABASE!!!

 It happens except for ODI Applications (Agents) that will be installed at each environment.

 In this way we have: 

  • From Development:
    1. The developers access the ODI Development Work Repository (DWR) to storage developed code;
    2. The ODI environment is accessed thru Designer and Operator Module or Metadata Navigator;
    3. The code execution (development) is done at Development System/Hardware
    4. There is an agent that can be used to any development and can be restated or has its configuration changed at any time with no interference at Production process. 
  • From Test:
    1. The Business Analysts (“testers”) can access only an ODI Execution Work Repository (EWR) that contains only executable code. The Designer module can’t connect to EWR;
    2. The ODI environment is accessed only thru Operator Module or Metadata Navigator;
    3. The code execution (tests) is done at Test System/Hardware;
    4. There is an agent that can be used to any test and should be a mirror from production to allow a best test. 
  • From Production:
    1. The Final User (or scheduled process) can access only an ODI Execution Work Repository (EWR) that contains only executable code. The Designer module can’t connect to EWR, then, never a code will be altered at Production;
    2. The ODI environment is accessed only thru Operator Module or Metadata Navigator;
    3. The code execution (production) is done at production System/Hardware
    4. The ODI Application (or agent) will execute all production process, scheduled or on-line.
    5. All ODI Repositories are in this hardware (even at distinct database if you thing necessary). The backup policy must be the same as any production system. The risk of loose information is the same of any other company system.

 

Well my friends, that is the architecture as I suggest to be used.

I will publish a specific post about how configure users to connect at database and his rights (ORACLE case) for this architecture.

Please, any question just let a comment.

 

Cezar  Santos

5 Comments

  1. Hi Cezar,

    Thank you for all info, i have question on accessing PROD logs from Operator, is there any possiblity to limit just read only for Developers in operator?

  2. hi Cezar,Thanks lot for this wonderful article.It truly explains the fact in a very concise yet clear manner.Just one point,could you please use a bigger image of the complete design for an ODI Environment,as i was unable to make out of it.
    Thanks a lot

  3. Hi Ankit,

    Sorry for the time that I took to reply, last days I was in MBA exams and I got no time.

    Until the end of week an article about how to promote code between environments.

    About multiples Masters, I intend to publish until next Monday, OK?

    Good to see you here!

  4. Cezar,

    Thanks for the detailed article. Have you also published the next article containing multiple Master Reps?

    What would be a scenario in which multiple Master Reps would be needed ?

    Also, can you write an article that illustrates how code is migrated (promoted) from one environment to another ?
    eg. DEV -> TST -> PRD

    Thanks

Leave a Reply

Required fields are marked *.