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.
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:
- All environments has DWR
- A generic process is developed in Development environment
- After be imported at test environment, a small bug is detected
- The “tester” take a decision to fix it once is just “add a comma” and doesn’t talk to the developer
- The process goes to Production (too a DWR)
- The Operator see some other small problem and, too, take the decision to fix it.
- 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!