Gürcan ORHAN presented steps for migrating from Oracle Warehouse Builder (OWB) to Oracle Data Integrator (ODI). He discussed preparing the environment, running the migration utility, and reviewing reports. Special cases during migration include mappings with multiple connections to the same operator or tables with multiple primary keys. If full migration is not possible, remaining OWB mappings can be called from ODI packages using the OdiStartOwbJob tool. The migration should be planned and executed incrementally in work packages.
2. Who Am I ?
+20 years of IT experience.
+14 years of DWH experience.
+10 years of Oracle Data Integrator experience.
+8 years of Oracle Warehouse Builder experience.
Sybase Power Designer, ERwin Data Modeler, SDDM
OBIEE, Cognos, Microstrategy, Business Objects, Qlikview, Tableau
IBM Data Stage, SAP Data Services, Informatica, etc…
Oracle Excellence Awards - Technologist of the Year 2011 :
Enterprise Architect
DWH & BI Chair : TROUG (Turkish Oracle User Group)
Published Customer Snapshot for NODI @Oracle.com
Published videos about ODI @Oracle.com (Oracle Media Network)
Published OTN Podcasts about
“Data Warehousing and ODI”
“ODI and the Evolution of Data Integration”
3 different “2MTT”s
Articles in OTech Magazine, SearchSoftwareQuality.com
Annual panelist for ODTUG “Ask the Experts Panel : ODI”
Presenter in OOW since 2010 (7 times in a row ⭐ )
Presenter in many OUG conferences in globe
Presenter in various universities in Turkey
16 JUNE 2017 / #OGHTECH17 2
3. Ekol Germany
Warehousing
Solutions
begin with the
Kardelen Facility
1996 2003 2010 2012 2014 2016
201520132011200820021990
Acquire STS Int.
Transport
Ekol Bosnia
Ekol France
Ekol Greece
Ekol Ukraine
Ekol Spain
Ekol Bulgaria
Ekol Czech Rep.
Ekol Iran
Ekol PolandEkol Italy
Ekol Romania
Ekol HungaryAcquire
Unok/Unatsan
Rainbow
Replaced by
Quadro
(software)
Intermodal
operations Ro-Ro
operations
Established
Ekol Milestones
9. 16 JUNE 2017 / #OGHTECH17
Some Facts
ODI is the strategic product for heterogeneous data
integration as declared in “statement of direction”
No major releases in Oracle Warehouse Builder
(latest release is 11GR2 - 11.2.0.4)
OWB will not be shipped with database 12c
No OWB documentation included in database 12c
OWB Support continues 😊
OWB is still supported by database 12c 😊
OWB 11.2.0.3 + CP2 is certified with database 12c 😊
OWB is not supported by Cloud environment
11. 16 JUNE 2017 / #OGHTECH17
REQUIREMENTS (safe harbour)
Oracle Warehouse Builder
- version 11.2.0.4
(plus patch # 18537208)
(plus patch # 21687102)
Oracle Data Integrator
- version 12.1.3.x.x or 12.2.1.x.x
2 Oracle Database instances
recommendation : 11G R2 (11.2.0.4)
A Linux based server
- version 11.2.0.3
(plus CP3 #16568042)
12. 16 JUNE 2017 / #OGHTECH17
Build Up Laboratory Environment (safe harbour)
SOURCE TARGET
OWB
ODI
Run your OWB jobs initially
before starting migration
Migration Utility is a command-line tool which runs on OWB installation
directory, migrates design-time metadata.
Linux 64-Bit or Windows 64-Bit StandAlone ODI Agent (with patch
17224695 for Migration Utility)
Upgrade your OWB, ODI
installations to required versions
13. 16 JUNE 2017 / #OGHTECH17
When your manager asks you…
19. 16 JUNE 2017 / #OGHTECH17
NOT Supported OWB Objects (Limitations)
table
(partitions
attribute sets,
data rules)
dimensional
modeling
metadata
custom
PL/SQL
(procedure,
package,
and so on)
user-defined types
streams
CDCconfigurations
process
flow
mappings using dimension and
cube
nameandaddress
match-merge
data rules
data auditors
expand
configuration details
(security,
user extensions,
transportable modules,
schedules/collections,
user folders)
OMB*Plusscripts
data profiles
materialized view
(partitions,
attribute sets,
data rules)
27. 16 JUNE 2017 / #OGHTECH17
Special Cases During Migration
2 Operators connected to same operator
28. 16 JUNE 2017 / #OGHTECH17
Special Cases During Migration
Tables with multiple Primary Keys
if target table has multiple primary keys, since only
one primary key is allowed in ODI, the redundant
primary keys will be migrated as alternate keys.
29. 16 JUNE 2017 / #OGHTECH17
Special Cases During Migration
Multiple operators connected from and to same operator
30. 16 JUNE 2017 / #OGHTECH17
Special Cases During Migration
Lookup operator has a constant as input
31. 16 JUNE 2017 / #OGHTECH17
Special Cases During Migration
Lookup Operators Have No Driver Table (Mapping Is Invalid)
32. 16 JUNE 2017 / #OGHTECH17
Special Cases During Migration
Multiple operators connected to same operator, some with no
upstream source
33. 16 JUNE 2017 / #OGHTECH17
Special Cases During Migration
Multiple operators connected to same operator, all with
different upstream operator
35. 16 JUNE 2017 / #OGHTECH17
Planning to Decide HOW
Manual jobs after “successful” migration
User Folders
Packages
Scheduling
User Defined Data Types
Model Folders
36. 16 JUNE 2017 / #OGHTECH17
Recommendations
Migrate everything and see what is migrating, what is not
Run everything without source data
Rollback everything (a fresh new ODI
12c)
Create folders, model folders in ODI 12c
Start migration per folder
Check migration logs for errors
Correct issues for mappings with error
Re-run ODI 12c with source data
42. 16 JUNE 2017 / #OGHTECH17
1. Call OWB Mappings from ODI Packages
Create an ODI package with
many ‘OdiStartOwbJob’
tool.
Run everything in ODI, but call
OWB mappings in right order
and sequence (synchronous /
asynchronous).
42
43. 16 JUNE 2017 / #OGHTECH17
Divide into Work Packages (Agile Methodology)
Divide OWB
mappings into Work
Packages
Perform Migration for
WP #n
Correct errors, rewrite if
not migratedChange
OdiStartOwbJob to ODI
object.
44. 16 JUNE 2017 / #OGHTECH17
Step by Step Migration Facts
PASSED : Include only objects that succeeded. FAILED : Include only objects that failed. ALL : Include all objects.
Mode :
FAST_CHECK : The migration utility performs a quick check for selected objects and provides a report that lists objects that can and cannot be migrated to the target ODI repository. Use this mode to quickly determine which objects can and cannot be migrated.
DRY_RUN : The migration utility checks whether the specified objects can be created in the target ODI repository, and executes the migration without committing the objects to the repository. This mode provides more information than FAST_CHECK. Use this mode to more completely determine which objects can and cannot be migrated.
RUN {default}: The migration utility executes the migration and commits migrated objects to the target ODI repository. Use this mode to perform the migration from OWB to ODI.
SPLIT JOIN : Indicates whether to split the join operator to binary join when the property Use ANSI Syntax of the OWB mapping is set to TRUE.
OUTBOUND OPERATOR : When set to TRUE, mappings that contain unbound operators are migrated. For unbound entity operators (external table, table, view, materialized view, and lookup), an ODI datastore corresponding to the unbound operator is created in the ODI model. For an unbound pluggable mapping operator, an ODI reusable mapping is created in an ODI folder named STAND_ALONE.
MIGRATION OBJECTS : Project, Folder or a single object name. Use semicolumn to concatenate. Asterisk (*) for all objects starting/ending with the name.
LOG : The migration utility log file contains details about objects that were migrated, and error messages if any errors occurred.
REPORT : The migration utility exclusion report contains a summary of the objects migrated, and lists whether migration succeeded or failed for each object.
The following figure shows an OWB mapping for which operators EMP and EXPRESSION are both connected to operator TGT_EMP through the same map attribute group INOUTGRP1. This is not allowed in ODI, because each input connector point in ODI can only be connected once.
OWB tables are migrated to ODI data stores. In OWB, tables can have multiple primary keys. In ODI, data stores can have only one primary key. In the case of multiple primary keys, the first primary key is migrated as the primary key in ODI, and the others are migrated as alternate keys.
When this situation occurs, the following warning message is written to the migration utility log file.
The following figure shows an OWB mapping for which operators FILTER and EXPRESSION are both connected to operator TGT_EMP through the same map attribute group INOUTGRP1. This is not allowed in ODI.
During migration, FILTER and EXPRESSION operators are chained together to ensure that only one is connected to TGT_EMP. As a result, the ODI mapping may be EMP > FILTER > EXPRESSION > TGT_EMP or EMP > EXPRESSION > FILTER > TGT_EMP.
The following figure shows an OWB mapping for which the Lookup operator has no upstream source operator, and is only connected from a constant.
The OWB mapping in the preceding figure is migrated to the ODI mapping in the following figure (DEP is the lookup table of the Lookup operator).
The constant operator CONSTANT in the OWB mapping is not migrated to any map component in ODI. Instead, the expression of the constant attribute is migrated, and that expression is set on the Lookup component.
For example, in OWB, if the expression of the attribute CONSTANT.OUTGRP1.NO is set to 5, and the lookup condition of LOOKUP_DEPT is OUTGRP1.DEPTNO = INGRP1.NO, then after migration the lookup condition of LOOKUP_DEPT in ODI is DEP.DEPTNO = 5.
The following figure shows an OWB mapping for which several Lookup operators are connected to operator TGT_EMP, but some of the Lookup operators have no upstream operators as driver tables. This mapping is invalid, but will also be migrated. Only one map component can be connected to TGT_EMP in ODI. As a result, Lookup operators without driver tables will lose the connection to operator TGT_EMP.
Note that expressions for the target attributes are migrated, even though these two lookup components are not connected.
The following figure shows an OWB mapping for which two operators are connected to the same operator TGT_EMP. The EXPRESSION operator has an upstream source operator, while the JOINER operator does not. Only one map component can be connected to TGT_EMP in ODI. As a result, the operator with no upstream source operator will lose the connection to TGT_EMP.
The OWB mapping in the preceding figure is migrated to the ODI mapping in the following figure.
The following figure shows an OWB mapping for which two operators are connected to the same operator TGT_EMP. Both operators have an upstream operator. Only one map component can be connected to TGT_EMP in ODI. As a result, one operator will lose the connection to TGT_EMP.
The OWB mapping in the preceding figure is migrated to one of the ODI mappings in the following figures.
WORKSPACE : Logical schema of the OWB Runtime Repository technology. This resolves to a physical schema that represents the OWB workspace that contains the OWB object to be executed. OWB workspace was chosen when you added a Physical Schema under the OWB Runtime Repository DataServer in Topology Navigator.
LOCATION : Name of the OWB location that contains the OWB object to be executed. This location must exist in the physical workspace that resolves from -WORKSPACE.
OBJECT_NAME : Name of the OWB object. This object must exist in -LOCATION.
OBJECT_TYPE : Type of OWB object : PLSQLMAP, PROCESSFLOW, SQLLOADERCONTROLFILE, MAPPING, DATAAUDITOR, ABAPFILE.
EXEC_PARAMS : Custom and/or system parameters for the OWB execution.
CONTEXT : Execution context of the OWB object. This is the context in which the logical workspace will be resolved. Studio editors use this value or the Default Context. Execution uses this value or the Parent Session context.
LOG_LEVEL : Log level (0-5). Default is 5, which means that maximum details are captured in the log.
SYNC_MODE : Synchronization mode of the OWB job => 1: Synchronous (Default), Asynchronous
POLLINT : The period of time in milliseconds to wait between each transfer of OWB audit data to ODI log tables. The default value is 0, which means that audit data is transferred at the end of the execution.
SESSION_NAME : Name of the OWB session as it appears in the log.
KEYWORDS : Comma-separated list of keywords attached to the session.
OWB PARAMS : List of values for the OWB parameters relevant to the object. This list is of the form -PARAM_NAME=value. OWB system parameters should be prefixed by OWB_SYSTEM, for example, OWB_SYSTEM.AUDIT_LEVEL.