ODIExperts.com

The blog for Oracle Data Integrator ( ODI )

Repository Architecture – Work Repository, Development or Execution? When and why uses each one.

Hi Friends,

I got a lot of emails asking me what is the difference between Development Work Repository (DWR) and Execution Work Repository (EWR) and too, why and when use each one.

In this post, I will try to explain these questions.

First we are discuss the concept of each type of repository and, after, the inter-relationship between them.

What is a work repository from ODI point of view?

It is a set of tables where all information from Designer and/or Operator is stored. It means, code, interface, procedure, variables, packages, execution log, scenarios, etc…

In this way, the ODI client install is only for GUI (Graphical User Interface) and then if, for instance, a HD from a ODI developer hardware crash, since the database wasn’t at same HD, absolutely nothing is lost.

 Concepts

Development Work Repository (DWR) – The code storage.

  • It’s where all developments (or wrote code) are storage, I mean, each single comma wrote in a interface or procedure, each OK line from a package, each datastore created or reversed in a model, etc… and plus, store any execution log from process started from there

In my concept of a perfect ODI environment it’s where the unitary tests are executed, I mean the tests, from developers, after finish the development of an object.

Execution Work Repository (EWR) – The “compiled code” (scenario) storage.

  • It’s where all scenarios are stored and no code alteration is allowed. Only accessible by Operator 

It means, after a generic development be ready to go to test (or production) and a scenario is generated from it (“compiled code” from ODI concept) it should be imported into a EWR for integrated tests (once again in my concept of a perfect ODI environment).

 

Work Repositories Inter-Relationship

OK, after define each repository, let me try to show how to use each one.

In theory, any program code, doesn’t matter if ODI, Java, Visual Basic, PL/SQL, should have just one version in production and just one code to be altered. Of course there is exceptions, when a “bug fixer” is necessary for some old version but this is more frequent in softwares, not at single programs or process.

Based on this theory, the Test and the Production environment couldn’t have a DWR. Imagine the following sequence and its consequences:

  1. All environments has DWR
  2. A generic process is developed in Development environment
  3. After be imported at test environment, a small bug is detected
  4. The “tester” take a decision to fix it once is just “add a comma” and doesn’t talk to the developer
  5. The process goes to Production (too a DWR)
  6. The Operator see some other small problem and, too, take the decision to fix it.
  7. Now, the Business Analyst ask for a new mapping and the developer executes it.

Think… In wich code the new Business Analyst request will be implemented? Can anyone assure that the same process will be tested for the same “tester” and he will remember the process and fix the old issue once more?

Of course that I’m creating limit situation but is to build a terrible scenario and scare you, for sure!!!

Worse than that, imagine if someone put a malicious code in production once can access it with the Developer module?

I know that controls can be created to try to avoid these situation but I prefer doesn’t create a door if no one can pass thru it. There is no reason to create it.

Well, these are my reasons to defend a Work Repository Architecture with just one Development Work Repository and so many Executions Work Repositories as your environment asked for!

Best Regards,

Cezar Santos

9 Comments

  1. Hello,

    A very informative article!
    I am trying to schedule a load plan in the execution repository, but unable to do so. When I update the schedule for the agent, only the development repository schedule as seen. Can you please help me with the steps to schedule a load plan in the execution repository?

    Thanks,
    Prats

  2. Great post. Very nice. This ODI repository book might also be of interest for ODI 11g users in particular https://www.amazon.com/Discover-Oracle-Integrator-Repository-Model-ebook/dp/B00H8O6H1W

  3. Could you please share how to migrate from DWR to EWR( in my project i am using smart export import which exports all the objects related apart from scennario) and if any issues you faced?

  4. For automated continuous integration processes using Test Driven Development (TDD), using EWR causes issues in not being able to have forward-compile code to make sure code is 100% in each environment at compile time. All manipulation of the Develop screens should be locked down at this time outside of true develop environment.

    • Hi Jonny,

      From my point of view, the compiled code must be from DWR to an EWR because then it’s possible to test the complete deployment process in a EWR before goes to production.

      I never experimented the kind of problem as you described but, when you have a second DWR issues like duplicated objects (Interfaces, procedures, models and all others ODI objects) become frequent and generate scenarios from this kind of “second” DWR could bring several severe business errors.

      Thank you for visit us Jonny!

  5. Cezar, I totally agree with you. I have been a big proponent of this architecture. apart from just being very clean. It also reduces the human error in exporting all the dependent objects one one environment to another one.

  6. Hello Cezar,

    In which Master repository table I will find the work repository information.

    Regards,
    Harshad Ambekar

Leave a Reply

Required fields are marked *.