ODI11g - A silent evolution in Version Management? (2/3) - Using "Solutions"

ODI11g - A silent evolution in Version Management? (2/3) - Using "Solutions"
Back to Sunopsis V4 and later ODI10g ... when an ODI developer wanted to keep a copy of the source her/his project - keeping in mind the usual Projects - Models approach implemented by the tool - not forgetting the "Global Objects" that could be shared by all Projects - she/he was left with the option of making a full copy/export of the Work Repository and to be completely safe of the Master repository also. The "Solution" concept was still in an embryonary stage and the modus operandi was such that it could only be used for small project (low number of objects in the project). Fig.01. Projects - Models Fig.02. Global Objects (may be shared or used in projects)
In ODI 11g ... the "Solution" feature further leveraged the ODI versioning feature that enabled a developer keeping copies of specific objects like  "procedure",  "variable" as a "version" object (kept in a table of the Master repository) independently of any other related object in the Work Repository.	Fig.03. Solution (creating a new container)
The Solution container is eventually built as a set of version objects (re-used when they already exist and are current, created when missing in the Master repository table) for all objects (in case of a Project : Interfaces, Procedures, ...) belonging to the main object (Principal Element) dragged and dropped in the "Solution" container and  to the related objects of the Principal Element (shared Models, Variables, ...)	Fig.04 Solution container named Blog_Example
Fig.05. above: objects the developer wants to source safe Fig.06. right:    objects automatically pulled in the solution
Once, the "Solution" has been assembled, it may be shared between all the Work Repositories bound to the (same) Master Repository wherein the version objects have been collected.   In Fig.07, we see a brand new created work repository, still empty. Though, we see the "solution" in the Designer Navigator. The "Solutions" objects are in fact an exception in this GUI sub-part (their specifications are stored in the Master Repository) since specifications of all other objects  visible in the Designer Navigator are stored in a Work Repository. .   A usual situation will then be to reverse the 'archived' source of a project into an empty Work Repository in order to bring a 'hot fix' to the code. The developer import the source code from the Master in this empty Work Repository for the purpose.   It is also possible to export a solution into an xml file. In the next post, we will see how it goes with Smart Export-Import ... I must admit now my favorite!	Fig.07 a 'target' empty Work repository ready for HotFixing