ODI11g - A silent evolution in Version Management? (1/3)

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:   Developer 1 ended his/her project (code freeze) at T1 but developer 2 used and had to alter the object definition for his/her project that would end later at T2 (T1 point in time earlier than T2 point in time) When developer 1 has to develop a fix between T1 and T2, he/she will have a problem with the representation of the table since his/her version is in production and the version of his/her colleague will be later (T2) in production so the source or target object definition does no longer have the same definition as at T1.   And the fix has to be made on the original representation of the object. 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 11.1.1.6.3 version of ODI- how one may from now on address this request.