Importing and Applying ETL Customizations

After you upgrade the data warehouse table definitions and data, you need to import the customizations into the post-upgrade repository.

If you have separate ODI repositories for Development (DEV), Testing (TEST) and Production (PROD), there is a difference in the steps for getting the customizations into the post-upgrade DEV repository and into the post-upgrade TEST or PROD repository. Assuming that only DEV is open to developers to make changes and TEST and PROD instances are locked down so content can only be migrated, the following summarizes the differences. Refer to the respective documents for the exact implementation of each step.

ODI Repository Steps to Import Customizations
DEV Customizations Imported using Regular Export/Import

Pre-Upgrade Dev Repo

  • Export Custom Folders

  • Export Custom Datastores

Post-Upgrade Dev Repo

  • Version Model

  • Version Model again

  • Import Custom Datastores

  • Import Custom Folders

  • Reapply Customizations

  • Generate Custom Scenarios

  • Apply Customizations to Generated Load Plan

DEV to TEST/PROD Customizations Migrated using Smart Export/Import

Post-Upgrade Dev Repo

  • Smart Export of Custom Folders

Test/Prod Repo

  • Smart Import of Custom Folders

The following sections describe the process to import the customizations previously exported from the pre-upgrade repository into the post-upgrade DEV repository. Refer to the T2P ODI migration document (BI Applications 11.1.1.7.1–Migrating Configurations and Customizations from Development to a Test OR Production Environment, My Oracle Support Document ID 1587872.1 ) for the steps to migrate the customizations from the DEV repository to TEST and PROD repositories.

An important difference in the two processes is the use of Regular and Smart import. Smart import’s default behavior is to overwrite the target while Regular import allows us to merge with the target. Smart import brings a lot of extra objects while Regular import just brings the objects you specified.

When moving from pre-upgrade to post-upgrade, we want to move only the customized objects. Using Smart import would bring almost all objects from the pre-upgrade repository and by default overwrite the objects in the post-upgrade repository. As the post-upgrade repository includes bug fixes and enhanced functionality, we would lose all of that and replace it with the legacy pre-upgrade objects. Regular import does not bring these extra objects with it.

When moving from DEV to TEST, the objects in the DEV repository should be replacing the objects in TEST as they represent the bug fixes and enhanced functionality. For migrating, we use Smart Import to bring all objects as these objects should always take precedence and overwrite what is in the target.