ODIExperts.com

The blog for Oracle Data Integrator ( ODI )

Repository Architecture – Two or more Masters – Part 3

Hi Friends,

I got some emails and comments asking for publish about how to work with more then one Master Repository and, you will see, it isn’t so complicated.

I will use, as base, the post  Repository Architecture – Just one Master – Part 2 to show to have a multiple Master Repositories environment.

First:

Question: Why to have 2 or more Masters Repositories?

Answer: When there is any restriction, physical or by policy, about contacting between environments, i.e. Development Environment has no physical connection with Production. Very common architecture to financial institutions like banks.

Take a look in the following image, we will discuss it: 

Three environmnets with no connection between them

Three environments with no connection between them

Here is how it will work:

  1. Development
    • One Master Repository (MR)
    • One Development Work Repository (DWR)
    • ODI modules – Designer and Operator – are used to developing, tests and log view
    • Topology has only connections to development database (source and target)
    • CENTRAL POINT OF ARCHITECTURE: ALL LOGICAL SCHEMAS AND LOGICAL AGENTS NEED TO BE DEFINED EXACTLY AS WILL BE DEFINED IN THE OTHERS ENVIRONMENTS
  2. Test
    • One Master Repository (MR)
    • One Execution Work Repository (EWR)
    • Operator will be used to import and export scenario and to create scheduling process
    • Metadata Navigator will be used to test (manual execution from Business Analysts)
    • Topology has only connections to test database (source and target)
    • CENTRAL POINT OF ARCHITECTURE: ALL LOGICAL SCHEMAS AND LOGICAL AGENTS NEED TO BE DEFINED EXACTLY AS WILL BE DEFINED IN THE OTHERS ENVIRONMENTS
  3. Production
    • One Master Repository (MR)
    • One Execution Work Repository (EWR)
    • Operator will be used to import and export scenario and to create scheduling process
    • Metadata Navigator will be used to log view and manual execution from Final Users (when necessary)
    • Topology has only connections to test database (source and target)
    • CENTRAL POINT OF ARCHITECTURE: ALL LOGICAL SCHEMAS AND LOGICAL AGENTS NEED TO BE DEFINED EXACTLY AS WAS DEFINED IN THE OTHERS ENVIRONMENTS

 

About the “CENTRAL POINT OF ARCHITECTURE”

ODI works with Logical Objects (Schemes and Agents) to separate the developing from “physical ” changes, I mean, changes of IP, User, Password, hardware, etc.

Using this concept, once exactly the same Logical objects are declared (created) in the three environments, it is absolutely possible to migrate scenarios from Development to Test to Production.

The connection and agents (physical objects) created at Topology can be, with no problem, created each one in its respective environment with its own parameters once they will be different once each one go to distinct hardware. I mean, no ODI import/export is necessary for physical objects.

An other possible question is “Why there is just one Development Work Repository?” but this one I will answer in my next post. 😉

I hope to have helped you to obtain more knowledge about ODI Repositories.

See you soon!

Cezar Santos

2 Comments

Leave a Reply

Required fields are marked *.


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