|Oracle Data Integrator 11g - A silent evolution in Version Management? (1/3)|
Version Management with Sunopsis and later ODI has not always been a straigthforward exercise especially when one wanted to externalize a project version to keep this source code together with other pieces of source codes belonging to the same release wave in a third party application dedicated to serve this purpose (ie: StarTeam, ...)
Usually ETL solutions implement a "Project based approach" to support the development around a functional subject.
Hence, developer 1 will create his/her project, reverse engineer the data container definitions (files, tables, messages) he/she would have to work with and then he/she would start developing the integration components.
All these data container objects will belong to a "project".
Developers 2, 3 would do the same and might actually at some point in time have to interact with the same objects (let us take the usual case of a table).
Since they would all reverse this object into their own "project" the table's metadata would exist 3 times in their development platform, one time in each project, hence 3 times if we have 3 project/developers working.
This configuration will high probably lead to a situation at one point in time where all these objects (the source object in the database, the 3 metadata representations in the ETL solution) will no longer be synchronized.
Further, from a 'change impact' perspective, these many representations of a single object (our table) might lead to difficulties in evaluating the impact of a change to this object (finding all the project components touching or interacting with it).
There are 'to do's' to manage this.
The ELT-(L) ODI development platform exposes a very specific model or approach.
It leverages the nice concept of naturally enabling sharing the representation of source or target objects.
The 'data container' metadata would exist only once in the ETL solution and would be exposed to each developer for him/her to interact with.
It is then possible to quickly see what are the impacts of a change to this object since all interacting objects (referring to) are exposed as linked to it.
The downsize of this approach would be that the version level of the metadata of this source or target object might no longer be 'in sync.' with the code level in the different projects interacting with it.
As a matter of example:
Till Sunopsis v4, the way to address this was to export the complete Work Repository at project code freeze.
Sunopsis v4 and ODI till version 10g (and early 11g) offered the concept of "solution" to address this aspect of concurrent development. But it had a downsize, it was a good (internal) answer as long as the implemented ETL solution architecture was revolving around a single Master repository to support the different phases of the development cycle (Development, Test, Quality Control, Production). Since the "Solution" approach relies on objects shared between development repositories attached to the same Master.
The request for separated Master Repositories has raised with time and one had to wait until very recently to have working answers to enable exchanging (or exporting) a complete project source code set (mapping, source-target metadata)
In the next parts (2/3, 3/3) of this subject, I shall expose -using the 184.108.40.206.3 version of ODI- how one may from now on address this request.