Copying and moving objects between projects in ODI

Get our e-books Discover the Oracle Data Integrator 11g Repository Data Model and Oracle Data Integrator Snippets and Recipes
One of the really annoying things about ODI is that it is not easily possible to move or copy objects between projects. Below is a step by step guide you can follow to copy or move objects between projects. We will take the object of type package as an example as this is the most complicated and covers off any of the others as well. The method shown uses Duplication mode import. While this method is not recommended by Oracle support. I never had any issues with it.

So let’s get started:
1. Migrate any of the variables used inside the package using Export and Import (Duplication Mode). A variable with the same name may already exist in the target project. This means you have to rename the variable and fix any references to it in interfaces, procedures, packages, and the Topology (the details on this follow below).
2. Migrate any of the project functions and project Knowledge Modules used using Export and Import (Duplication Mode)
For the KMs consider using global KMs instead
3. Export the root folder (with child components) of where the package is located. The reason for this is how Duplication mode import in ODI works. Basically it does not recreate internal IDs for objects that are part of the export XML. This strategy is used to minimise the number of missing references and as a result the amount of work we need to do.
4. Next we import the exported folder into our new project.
Note the import needs to be made in Duplication Mode.
5. Next we move (drag and drop) the object(s) we need from our imported folder to our target folder in the new project.
6. Next we can delete the imported folder
7. Any missing references to Knowledge Modules need to be recreated for all of the interfaces used in the package
Note: This also applies to all of the options for each KM.
If variables are referenced using the old project code in any of the KMs or you had to rename a variable during import then these need to be updated as well
8. Update references to any variables or project functions used in procedures
If variables are referenced using the old project code in any of the Procedures or you had to rename a variable during import then these need to be updated as well
9. Update references to any variables or project functions used in other variables
If variables are referenced using the old project code in any of the Variables or you had to rename a variable during import then these need to be updated as well
10. Update references to any variables used in the Topology, e.g. as part of physical data servers
11. Update references to any variables or project functions used in other project functions
12. Next we need to replace any missing references inside the package
These are typically only references to variables unless your package also references procedures etc. from outside the root folder that we exported/imported
We need to recreate those links by deleting the variables in the package and adding them again. Make sure that you select the correct Variable Type when recreating the variable in the diagram (Refresh Variable, Declare Variable etc.).
Open the legacy package for a side by side comparison to minimise mistakes.
13. If you reference scenarios in your package and you pass variables to these scenarios you will also need to repoint the variables in the Additional Variables tab for this scenario
14. Replace and fix references to new markers
15. Delete any scenarios for the legacy object(s) and then for the migrated object(s) if applicable.
16. Generate scenario for the migrated object(s)
17. Export legacy objects for backup (optional, if you are the cautious type)
18. And finally: Delete any of the legacy objects you migrated.
[big_data_promotion]