This chapter provides an overview of migration from Oracle Warehouse Builder (OWB) to
Oracle Data Integrator (ODI).
The following topics are addressed here:
ODI is Oracle's strategic product for heterogeneous data integration. Because many Oracle Database customers have significant investment in OWB, Oracle supports a phased migration from OWB 11gR2 (11.2.0.4) to ODI 12c. The following features are provided to make the transition to ODI easier:
ODI 12c supports the execution and administration of OWB 11gR2 jobs directly within ODI Studio and ODI Console, providing a single orchestration and monitoring solution. This feature enables you to migrate OWB objects over a longer period of time and in a way that makes sense for your business. For more information about this feature, see "OdiStartOwbJob" in the tools reference section of the Developer's Guide for Oracle Data Integrator.
ODI 12c supports an easier mapping between OWB 11gR2 concepts and objects and their ODI 12c counterparts. A migration utility is provided that automatically translates many OWB objects and mappings into their ODI equivalents. For more information about the migration utility, see About the Migration Utility.
The migration utility is a command-line tool that enables you to migrate design-time metadata from OWB to ODI. Runtime data and physical objects are not migrated. The migration utility uses the settings in the migration utility configuration file to perform the migration.
The migration utility is an aid only to assist migration of design-time metadata from OWB to ODI. OWB and ODI are two different products with overlapping but not identical features, and hence behaviors of migrated artifacts will differ. Customers shall expect to do post-migration work to ensure the migrated artifacts in ODI are working as expected. Post-migration work shall include but is not limited to examining the migrated artifacts, making modifications in order to obtain desired behaviors in ODI, and executing artifacts in ODI runtime environment.
For information about obtaining the patch, see Migration Requirements.
For information about planning the migration, see Roadmap for Migrating.
The migration utility is an aid to migration only, and not all types and variants of OWB objects are migrated. Manual effort should be expected including further modifications of the migrated Mappings in ODI or extensive testing to verify the Mappings.
The following topics are addressed here:
The following OWB objects are supported for migration when you run the migration utility:
modules (source and target)
locations
data objects
table (columns, keys, indexes)
view (columns, keys)
materialized view (columns, keys, indexes)
external table (columns)
file (records, fields)
sequence
mappings
classic mappings
Code Template mappings
pluggable mappings
mapping operators
Aggregator
Constant
Deduplicator
Expression
External Table
Filter
Flat File
Joiner
Key Lookup
Mapping Input Parameter
Materialized View
Pivot
Pre/Post Mapping Process
Sequence
Set
Sorter
Splitter
Subquery
Table
Table Function
Transformation
Note: Transformation objects are actually not migrated, but transformation operator in mapping is migrated as expression component in ODI, only if the transformation object is present in ODI repository.
Unpivot
View
The following OWB objects are not supported for migration when you run the migration utility:
data objects
table (partitions, attribute sets, data rules)
view (attribute sets, data rules)
materialized view (partitions, attribute sets, data rules)
external table (data rules, locations)
sequence (columns)
dimensional modeling metadata
Oracle Discoverer metadata and derived Oracle Business Intelligence Suite Enterprise Edition (OBI EE) metadata
custom transformations, PL/SQL (procedure, package, and so on)
queues, streams, CDC (Change Data Capture) configurations, user-defined types
process flow
mappings using dimension and cube, cursor-based maps, name and address, match-merge, data rules, data auditors, iterators, expand, construct, Anydata Cast, Data Generator
data quality, data profiles, data auditors
configuration details (security, user extensions, transportable modules, schedules/collections, user folders)
OWB Experts
OMB*Plus scripts
Internal variable, which is used by the OWB runtime during code generation, for example, get_model_name
The activities to migrate from OWB to ODI would require considerable amount of planning ahead and involve multiple teams and resources. An overall plan should be in place and discussed with all involved parties before the actual activities are carried out.
The overall plan should include the following suggested phases:
Pre-Migration phase
Helps to prepare the environment for migration.
Planning phase
Helps all parties involved to be familiar with the Migration Utility and learn about what it can do and its limitation, and hence identify potential gaps that would require alternate migration activities.
Using the Migration Utility phase
Actually does the migration using the utility but also identifies objects that cannot be migrated.
Manual migration phase
Handles alternate migration activities for objects that cannot be migrated by the Migration Utility
Post Migration Development phase
The migrated solution (using the Migration Utility or by manual) is reviewed, re-examined, and compared with the OWB solution to ensure the same end results are achieved. Note that additional changes or development are expected on the migrated solution to achieve the same result.
Post Migration Testing/QA phase
When the migrated solution has been examined to work the same as in OWB and enters into full testing and QA.
Rolling out the ODI Solution phase
The final phase when the ODI solution is rolled out. One should plan on gradually cutting over from the original OWB instance to the new migrated ODI instance until all the new jobs in ODI are working satisfactorily. That is, both systems would be kept up and running in production until the last OWB job are moved over to ODI and tested to work.
Table 1-1 provides a high-level summary of the steps required to migrate from OWB to ODI. The table also lists where to find more information for each step.
Table 1-1 OWB to ODI Migration Roadmap
| Step | Description | Documentation |
|---|---|---|
|
Phase: Pre-Migration Phase The goal of this phase is to prepare the environment for migration. |
||
|
Back up existing OWB repositories |
Before running the migration utility, backup your existing OWB repositories. |
See OWB documentation. |
|
Verify your system environment |
Before running the migration utility, verify that your system meets requirements and that you are not connected to the design repository. |
|
|
Phase: Planning The goal of this phase is to get familiar with the Migration Utility, learn about what it does and its limitations, identify potential gaps that the Migration Utility may not be able to assist with, plan the migration activities using the Migration Utility and alternate migration activities without using the Migration Utility. |
||
|
Review the entire Migration Utility document, especially the section on ”Supported and Unsupported objects”. |
Make sure you understand what will and will not be migrated. |
|
|
Edit the migration utility configuration file for a test migration. |
Edit the migration utility configuration file and make sure the settings are correct for your environment. The configuration file contains connection information and other details required for migration. Set MIGRATION_MODE to FAST_CHECK or DRY_RUN to do a test run of the Migration Utility. |
|
|
Perform a test migration by running the migration utility in FAST_CHECK or DRY_RUN mode. |
Run the migration utility to migrate OWB objects to ODI using the settings in the migration utility configuration file. Before running the migration utility, verify that you are not connected to the design repository. |
|
|
Review the migration utility log file |
After migration is complete, review the migration utility log file. The file contains details about objects that were migrated, and error messages if errors occurred. |
|
|
Review the migration utility exclusion report |
After test migration is complete, review the migration utility exclusion report. The report provides a summary of objects that can be migrated, and lists whether migration succeeded or failed for each object. For objects excluded from migration, manual migration steps will be needed. |
|
|
Finalize migration plan |
Based on the test migration run and the result, the objects that will be migrated by the migration utility and those that cannot be migrated by the migration utility will be known. For those objects that cannot be migrated, some manual effort will be needed to recreate these objects in ODI. Create a list of all these objects that will require a manual migration. |
|
|
Phase: Using the Migration Utility to do the migration The goal of this phase is to actually perform the migration of objects that can be migrated by the Migration Utility. |
||
|
Edit the migration utility configuration file |
Edit the migration utility configuration file and make sure the settings are correct for your environment. The configuration file contains connection information and other details required for migration. |
|
|
Run the migration utility to perform the migration using MIGRATION_MODE=RUN |
Run the migration utility to migrate OWB objects to ODI using the settings in the migration utility configuration file. Before running the migration utility, verify that you are not connected to the design repository. |
|
|
Review the migration utility log file |
After migration is complete, review the migration utility log file. The file contains details about objects that were migrated and error messages if errors occurred. |
|
|
Review the migration utility exclusion report |
After migration is complete, review the migration utility exclusion report. The report provides a summary of objects that were migrated, and lists whether migration succeeded or failed for each object. |
|
|
Verify your migration |
In ODI Studio, connect to your ODI environment and perform post-migration testing to verify your migration. |
|
|
Phase: Manual Configuration For the objects not migrated by the Migration Utility, manual migration will be needed. |
||
|
Create objects in ODI manually |
For any objects not migrated by the Migration Utility, some manual effort will be needed to recreate these objects in ODI. The list of objects excluded from migration by Migration Utility is noted in the Planning phase above. |
|
|
Verify your migration |
In ODI Studio, connect to your ODI environment and perform post-migration testing to verify your migration. |
|
|
Phase: Post-Migration Development After running the migration plans (either using the Migration Utility or manual steps), the migrated repository should be examined, reviewed and verified. This should be the most crucial and probably the biggest phase of any migration project. It shall involve reviewing each migrated artifact, executing all executable artifacts in ODI, as well as examining results. It is expected that the behavior of migrated artifacts will not be the same as in OWB and modifications may be needed to make the artifact behave as desired. Customers shall plan to invest significant amount of time in this phase. |
||
|
Verify your migration |
In ODI Studio, connect to your ODI environment and perform post-migration testing to verify your migration. |
|
|
Review gaps or differences, re-create or re-implement existing logic |
For artifacts that do not execute with the same results as in OWB, review the OWB artifacts and compare with the corresponding ODI artifacts. The ODI artifacts may need tweaking or re-design for the artifact to behave similar to the OWB artifact. One may need to re-create or re-implement the OWB logic in ODI. |
|
|
Phase: Post Migration Testing / QA After all the mappings have been migrated (by the Migration Utility or manually created) and verified in the phases above, the migrated ODI solution should be handed over to testing team for full QA testing. |
||
|
Phase: Rolling out the ODI solution Before cutting over to ODI, the migrated ODI solution should run in concurrent with OWB until all the artifacts in ODI have been reviewed, verified and stabilized. When the ODI solution is running as expected or desired, the cut-over from OWB can be done. |
||