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.