Viewing the Differences between two Versions

19 ExportingImporting 19-1 19 ExportingImporting This chapter describes how to manage export and import operations in Oracle Data Integrator. An introduction to the import and export concepts is provided. This chapter includes the following sections: ■ Section 19.1, Import and Export Concepts ■ Section 19.2, Exporting and Importing Objects ■ Section 19.3, Repository-Level ExportImport ■ Section 19.4, Exporting the Technical Environment

19.1 Import and Export Concepts

This section introduces you to the fundamental concepts of export and import operations in Oracle Data Integrator. All export and import operations require a clear understanding of the concepts introduced in this section.

19.1.1 Internal Identifiers IDs

Before performing export and import operations, it is essential to understand in detail the concept of internal identifiers ID in Oracle Data Integrator. To ensure object uniqueness across several work repositories, ODI uses a specific mechanism to generate unique IDs for objects such as technologies, data servers, Models, Projects, Integration Interfaces, KMs, etc.. Every object in Oracle Data Integrator is identified by an internal ID. The internal ID appears on the Version tab of each object. ODI Master and Work Repositories are identified by their unique internal IDs. This RepositoryID of 3 digits must be unique across all work repositories of an ODI installation and is used to compute the internal ID of an object. The internal ID of an object is calculated by appending the value of the RepositoryID to an automatically incremented number: UniqueNumberRepositoryID If the Repository ID is shorter than 3 digits, the missing digits are completed with 0. For example, if a repository has the ID 5, possible internal IDs of the objects in this repository could be: 1005, 2005, 3005, ..., 1234567005. Note that all objects created within the same repository have the same three last digits, in this example 005. This internal ID is unique for the object type within the repository and also unique between repositories for the object type because it contains the repository unique ID. This mechanism allows to: 19-2 Oracle Fusion Middleware Developers Guide for Oracle Data Integrator ■ Avoid any ID conflicts when exporting and importing from one repository to another ■ Understand the provenance of every object, simply by looking at its Internal ID. The 3 last digits always refer to the repository where it was created. Important ExportImport Rules and Guidelines Due to the structure of the object IDs, these guidelines should be followed: ■ Work repositories must always have different internal IDs. Work repositories with the same ID are considered to contain same objects. ■ If an exportimport operation is performed between two MasterWork repositories possessing identical internal IDs, there is a risk of overwriting objects when importing. Objects from both repositories that have same IDs are considered the same.

19.1.2 Relationships between Objects

Oracle Data Integrator stores all objects in a relational database schema the Repository 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. Solutions allow to export and import sets of dependent objects automatically. Using solutions and versioning is the recommended way of maintaining the dependencies automatically when doing exportimport. See Chapter 18, Working with Version Management . Therefore, the Model or Sub-model holding this Datastore needs to be exported and imported in Synonym mode prior to importing the integration interface. There are also dependencies between work repository objects and master repository objects. Dependencies within a work repository are ID-based. Dependencies between objects of the work and objects of the master are based on the Codes and not the IDs. This means that only the Code of the objects for example ORACLE is the code of the Oracle technology in the master of the master repository objects are referenced in the work repository. It is important to import objects in the appropriate order. You can also use Solutions to preserve these dependencies. Table 19–1 lists the dependencies of an integration interface to other objects when importing the integration interface in synonym mode.