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

Leave a Reply

Required fields are marked *.


This site uses Akismet to reduce spam. Learn how your comment data is processed.