ODI11g - A silent evolution in Version Management? (3/3) - Using "Smart Exp-Imp"

ODI11g - A silent evolution in Version Management? (3/3) - Using "Smart Exp-Imp"
Fig.01. Exporting the source objects specifications into .xml file In ODI 11g ... I had the pleasure to discover the Smart-Export / Smart-Import process. I must admit, I had to search for it. This new feature was hidden in the documentation and the "What's new in" document was not providing the attention it deserved. As shown in Fig.01., clicking the button of the Designer Navigator under the "Export" command, one could discover the "Smart" export feature. The same "drag and drop" movement would be applied as for the "Solution" to build a consistent set of source code for a given project.
The "principal element" usually a project is pulled into the Smart Export window and the 'Objects to be exported' area and then the procedure collects all the required elements using the known dependencies. As you may see in Fig.02., shared Models, shared Global Objects are collected together with ... the 'Topology specifications stored as you known in the Master Repository. The Logical architecture as well as the Physical Architecture info is picked up  (ie: added properties to Data Servers, the connection information to the Development data sources and target, ...) The last may be useful when for instance the url specifications have changed and you would need to test your fix or correction in the same configuration as in Production. Remember, for the "Solutions" one will use the current connection information which might no longer be the same as in Production.   The end result is a complete set that may then be reloaded in a stand-alone, empty Master & Work set of repositories.	Fig.02. the assembled set of objects and specifications
Fig.03.Smart Import into an empty set of Repos. The developer may then quickly using a local Oracle instance to create a temporary "Hot-Fix" environment without being dependent on a DBA who manages the central set of repositories.   Your .xml file may be saved into a central SCM / ALM solution. You may even think about having a dedicated naming convention like:         <project_name>_<project_release_level>_<odi_release_level> Depending on your target set of repositories: an existing Master with an empty Work repository, an set of empty Master and Work repository, the developer will have the choice to specify which of the Master specifications she/he wants to keep. Further, as you may notice, the Smart Import process will guide you to fix any issue detected with the set of source specifications. Fig.04.Smart Import - Controls and Options
Personally, I found this process really "smart" and this feature is still currently my favorite option to keep a version of my project code because of its performance versus the "Solutions" option, the available logging/trace during the export step, the autonomy and flexibility it offers afterwards.

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