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:
As you can see, there are 3 environments
- Development — GREEN
- Test — YELLOW
- 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:
- The developers access the ODI Development Work Repository (DWR) to storage developed code;
- The ODI environment is accessed thru Designer and Operator Module or Metadata Navigator;
- The code execution (development) is done at Development System/Hardware
- 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:
- 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;
- The ODI environment is accessed only thru Operator Module or Metadata Navigator;
- The code execution (tests) is done at Test System/Hardware;
- 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:
- 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;
- The ODI environment is accessed only thru Operator Module or Metadata Navigator;
- The code execution (production) is done at production System/Hardware
- The ODI Application (or agent) will execute all production process, scheduled or on-line.
- 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
November 8, 2010 at 9:43 AM
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?
November 10, 2010 at 7:22 AM
Anand,
When you say prod logs . Do you mean sessions. If not please let me know what logs are you talking about. ?
October 7, 2009 at 11:40 PM
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
September 9, 2009 at 2:00 PM
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!
September 2, 2009 at 3:06 PM
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