Hi all, I’m back with the continuation of this Groovy and ODI series. Last post we saw how to find the different scenarios between two environments. Today we will look on how we may export those different scenarios from our source repository and how to import them in our target repository. We will do a two-step operation: first we will export the different ODI objects from our source repository as XML files into a folder and then we will import those xml files into our target repository.
Our code is very similar to the one that we did for post 3, but we will need to enhance it a little bit. First thing that we will have to change in our code is the function that creates the list of objects. In the previous post, we were just adding the name of the scenarios to the list. Now we will need to store the object itself in the list, since we will need to have the ODI object (scenario) to have it exported.
def listObjects (odiInstance,odiClass,listOfObjects) {
odiObjects = odiInstance.getTransactionalEntityManager().getFinder(odiClass).findAll().sort{it.name}
for (Object odiSingleObject: odiObjects)
listOfObjects.add(odiSingleObject)
}
Also, we will need to create a variable that will indicate the path where the objects will be temporarily exported.
exportPath = "C:\\Odi"
One import thing that we will need to change is how to compare the objects. In the previous post, we were simply comparing them, as they were strings, which was ok for our propose there. However, now we cannot simple compare the java objects because they will be different even if they represent the same scenario name/version. They are considered “different” because they came from different environments and logically, they represent different ODI entities.
diffScenarios = []
for (Object odiSingleObject: sourceScenarios)
if (targetScenarios.find {targetScenarios -> targetScenarios.getName() == odiSingleObject.getName() && targetScenarios.getVersion() == odiSingleObject.getVersion()}.equals(null))
if (odiSingleObject.getName().startsWith('TEST'))
diffScenarios.add(odiSingleObject)
I’m basically doing three tests to see if the source scenario will be migrated or not: first I compare its name, than its version and finally if its name starts with TEST (this last step does not need to be done if you want to get the complete scenario list). Next step I just print the scenarios names and versions that will be exported/imported:
println("List of ODI Scenarios that will be migrated")
for (Object singObject: diffScenarios)
println(singObject.getName() + "_" + singObject.getVersion())
Now comes the new code:
encode = new EncodingOptions();
transSource = sourceOdiInstance.getTransactionManager().getTransaction(new DefaultTransactionDefinition());
exportService = new ExportServiceImpl(sourceOdiInstance);
for (Object singObject: diffScenarios)
exportService.exportToXml(singObject, exportPath, true, false, encode)
Export objects in ODI SDK is very straight forward: you need to inform which scenarios you want to export (in our case, all objects that were stored in diffScenarios array), the path where the object will be exported and the encode option that will be used. In this case, I just went ahead with the default encode options.
Importing objects is also easy, but similarly to a database, you need to explicitly commit your actions to make it effective in the target repository. Also, for the sake of simplicity, we will import all new scenarios under “root”, but we could explicitly say under which ODI objects we would want to have it imported to:
tm = targetOdiInstance.getTransactionManager()
transTarget = tm.getTransaction(new DefaultTransactionDefinition());
importService = new ImportServiceImpl(targetOdiInstance);
for (Object singObject: diffScenarios)
{
println(exportPath+"\\SCEN_"+singObject.getName() + "_Version_" + singObject.getVersion()+".xml")
importService.importObjectFromXml(ImportServiceImpl.IMPORT_MODE_SYNONYM_INSERT_UPDATE,exportPath+"\\SCEN_"+singObject.getName() + "_Version_" + singObject.getVersion()+".xml", true, null, true)
}
tm.commit(transTarget)
Once you run the job, you will get the following:

Our target repository already had TEST2, so that’s why its not in the list. When the user connects to the target repository, he will see the following:

That’s it for today folks! Hope you like it! See you soon! The code for part 4 can be found here.