ODI Migration Process

Purpose: - The purpose of this document is to outline the ODI migration process, list out all the
objects to be migrated and also to specify the limitations etc. We will use ODI commands like
OdiExportObject and OdiImportObject to export and import objects into different
environments.
Prerequisite: - In order to execute ODI commands from windows command prompt or as UNIX
script we need to have an ODI standalone agent installed which can connect to the work
repositories.
ODI Object Internal ID:To perform export and import process in ODI, it is essential to understand the internal Identifier
concept in ODI.
To ensure object uniqueness across several work repositories, ODI uses specific mechanism to
generate unique IDs for objects like Technologies, Models, and Projects etc. Every object in ODI
is identified by an internal ID. The internal ID appears on the Version Tab of each object as
shown below.
Internal ID of Silos Folder

Although it is possible to modify the Internal ID of an object, it is highly recommended not do

so.

ODI Master and Work Repositories are identified by their unique internal IDs. The Internal ID of
an object is calculated by appending the value of the Repository ID to and automatically
incremented number: <Unique Number><Repository ID>
ODI Export Process: We can export ODI objects into an XML file. ODI objects have dependencies. These
dependencies will be exported in the XML export file. The contents of this XML file will depend
on export method used:
1. Exporting an Object with its Child Components.
2. Exporting an Object without its Child Components.
Exporting an Object with its Child Components: This is the most common method when you want to export an object. It allows you to export all
sub components. When an object is exporting with its child components, all containerdependent objects i.e. those which possess a direct parent/child relationship are exported.
Referenced Objects are not exported.
Eg:- When you export a project with its child components, the export will contain the project
definitions as well as the objects included in the Project such as Folders, Interfaces etc.
However this export will not contain dependent objects referenced which are outside of the
Project itself such as Datastore and columns etc. Only the numeric ID references of these
Objects will be exported.
Exporting an Object without its Child Components: This allows you to export only the top-level definition of an object without any of its subobjects.
Eg: - If you export a Model without its children, it will only contain the Model definition but not
the underlying Sub-models and Datastores when you import this model to a new repository.
Command Line for Export:This section explains ODI export process from command line in both windows and Linux
environments.
OdiExportObject command can be used to export objects from current repository. This
command reproduces the behavior of the export feature available in the user interface.
The syntax for OdiExportObject is as follows:

OdiExportObject -CLASS_NAME=<class_name> -I_OBJECT=<object_name> EXPORT_DIR=<path> -EXPORT_NAME=<name_file> -FORCE_OVERWRITE=yes RECURSIVE_EXPORT=yes

Where
-CLASS_NAME is the class name
-I_OBJECT corresponds to the internal version number of the object to export.
-EXPORT_DIR corresponds to the directory of the export file.
-EXPORT_NAME corresponds to the name of the file. For example if you export a folder and
give EXPORT_NAME as custom, the name of the export file will be FOLD_Custom.xml.
-FORCE_OVERWRITE is a flag allowing the overwriting of existing files.
-RECURSIVE_EXPORT is a flag allowing the export of child components along with given object
Id.
Below are the set of steps and screenshots explaining the ODI export process with
OdiExportObject:Lets say we have an ODI project to be migrated
which contains the following objects as shown below:
1.) Project ---> Migration
2.) Folders ---> Custom, SDE, SILOS
3.) Interface ---> Load_AP_terms
4.) Package ---> Load Ap Terms
5.) Models ---> APPS and DWH
6.) Markers ---> Custom Marker
7.) Variable ---> Status

The list of steps to export ODI objects is as follows:

1. Identify the location where we would generate the XML files.
2. Standalone agent is running.
The below picture shows the window in which ODI Standalone Agent runs

3. Open the location where startcmd.bat\startcmd.sh files are present in a terminal.

4. To export the Custom Folder. Identify the Object Version ID.

5. To export the ODI folder object execute this command.

startcmd.bat OdiExportObject -CLASS_NAME=SnpFolder -I_OBJECT=12501 EXPORT_DIR=C:\ODI\ODI_Export_Directory -EXPORT_NAME=Custom FORCE_OVERWRITE=yes -RECURSIVE_EXPORT=yes

6. The File gets generated in the shared folder created earlier.

7. Now we can import this object using OdiImportObject command.

8. The same process can be used for exporting other object like Packages, Interfaces etc.
The Class Name Parameter shall vary with the type of object being exported. Below
table contains the list of Object and its corresponding Class Name to be used.

Object
Column
Condition/Filter
Context
Data Server
Datastore
Folder
Interface
Language
Model
Package
Physical
Procedure or KM
Procedure or KM Option
Project
Reference
Scenario
Sequence
Step
Sub-Model
Technology
User Functions
Variable
Version of an Object

Class Name
SnpCol
SnpCond
SnpContext
SnpConnect
SnpTable
SnpFolder
SnpPop
SnpLang
SnpModel
SnpPackage
SnpPschema
SnpTrt
SnpUserExit
SnpProject
SnpJoin
SnpScen
SnpSequence
SnpStep
SnpSubModel
SnpTechno
SnpUfunc
SnpVar
SnpData

ODI Import Process: Oracle Data Integrator can import objects, topology or repositories in several modes.
The various import types are
Duplication: This mode created a new object with a new Internal ID in the target repository, inserts
all the elements of the export file.
Dependencies such as parent child relationships between objects are recalculated.
This type of import is typically not used in migrating objects across various
environments.
Synonym Mode INSERT: Tries to insert the same object (with the same internal ID) into the target repository. The
original object ID is preserved.
If an object of the same type with the same internal ID already exists then nothing is
inserted.
Dependencies between objects which are included into the export such as parent/child
relationships are preserved.
References to objects which are not included into the export are not recalculated.
If any of the incoming attributes violates any referential constraints, the import
operation is aborted and an error message is thrown.
Synonym Mode UPDATE:

Tries to modify the same object (with the same internal ID) in the target repository.
This import mode updates the objects already existing in the target Repository with the
content of the export file.
If the object does not exist, the object is not imported.
This import mode does NOT create objects that do not exist in the target. It only
updates existing objects.

Synonym Mode INSERT_UPDATE:

If no ODI object exists in the target Repository with an identical ID, this import mode will
create a new object with the content of the export file.
Already existing objects (with an identical ID) will be updated; the new ones, inserted.
Existing child objects will be updated, non-existing child objects will be inserted, and
child objects existing in the repository but not in the export file will be deleted.

Dependencies between objects which are included into the export such as parent/child
relationships are preserved.
References to objects which are not included into the export are not recalculated.

Command Line for Import:This section explains ODI import process from command line in both windows and Linux
environments.
OdiImportObject command can be used to import the contents of an export files into a
repository. This command reproduces the behavior of the import feature available from the
user interface.
The syntax for OdiImportObject is as follows:
OdiImportObject -FILE_NAME=<FileName> [-WORK_REP_NAME=<workRepositoryName>] IMPORT_MODE=<DUPLICATION | SYNONYM_INSERT | SYNONYM_UPDATE |
SYNONYM_INSERT_UPDATE> [-IMPORT_SCHEDULE=<yes|no>]
Below are the set of steps and screenshots explaining the ODI export process with
OdiImportObject: 1. Identify the Shared Folder in which the export files are present.
2. Standalone agent should be running.

3. Open the location where startcmd.bat\startcmd.sh files are present in a terminal.

4. To Import the Custom Folder execute this command:

startcmd.bat OdiImportObject FILE_NAME=C:\ODI\ODI_Export_Directory\FOLD_Custom.xml WORK_REP_NAME=WORKREP505 -IMPORT_MODE=SYNONYM_INSERT_UPDATE
5. The Folder gets migrated to the target environment.

6. As we can see from the above all the screenshot the folder along with its child objects
gets imported.
7. This folder export assumes that the project Test1 is already present in the Target
repository.

Export and Import dependency Recommendations:Oracle Data Integrator stores all objects in a relational database schema with
dependencies between objects. Repository tables that store these objects maintain these
dependencies as references using the IDs. When you drag and drop a target datastore into an
integration interface, only the reference to the ID of this datastore is stored in the interface
object. If you want to export this interface, and import it in Synonym mode into another work
repository, a datastore with the same ID must already exist in this other work repository
otherwise the import will create a missing reference.
The missing references can be resolved either by fixing the imported object directly or
by importing the missing object.
Below are set of recommendations to be considered before we import objects:

Global Variables, Sequences and Functions used within the Interface need to imported
first
Local Variables, Sequences and Function used within the Interface need to imported
first
Knowledge Modules referenced within the Interface need to be imported first
Any Interface used as source in the current Interface needs to be imported first
Folder: Folder holding this Interface needs to be imported first.
Model/Sub-Model: all Models/Sub-Models holding Datastore definitions referenced by
the Interface need to be imported first.
Datastore definitions including Columns, Data Types, Primary Keys, Foreign Keys,
conditions must be exactly the same as the ones used by the exported Interface