This appendix lists the known issues and their solutions.
This appendix contains the following topics:
The following are the issues are known at the time of the release. This section also provides the solutions to work around these issues.
Symptom: The OWB to ODI Migration Utility does not migrate the comments from OWB Joiner Condition to ODI Joiner Condition.
Solution: Comments are migrated when the OWB Mapping is not ANSI. Otherwise, the comments are filtered out and not migrated. If you need Joiner comments to be migrated over for OWB mapping that is ANSI, you can use the migration configuration property SPLIT_JOIN_FOR_ANSI_SYNTAX=false and migrate the mapping again.
Symptom: A misspelled configuration parameter has been added to the configuration file. The Migration Utility execution does not report/list the misspelled configuration parameter in the generated log files.
Solution: Check carefully the properties name in the migration utility configuration file.A sample configuration file is provided in the following location.
<owb_home>/owb/bin/admin/migration.config
Symptom: After having migrated OWB mappings to ODI using the OWB-ODI Migration Utility, ODI generates database links for mappings that have source and target table in the same Oracle database.
Cause: This is not a bug. In OWB, when having e.g. a mapping with one source and one target in the same database but in different schemas, one location is required for every schema. When these two locations are migrated using the migration utility, the utility will create two data servers in topology. However, when ODI generates code for a mapping having source and target from different data servers, ODI will generate a database link to the source. The disparity in the code generated in ODI when compared with OWB is coming from the conceptual differences about how connections and schemas are described in OWB and ODI. The semantics and assumption in ODI is that if two physical schemas are under different data servers, these two physical schemas are always considered to be in different database instances. As a result, ODI will create two execution units in the ODI mapping and thus a database link will be used to access the source table. This is the expected behavior in ODI. The OWB-ODI migration utility is also behaving as designed. Since it is possible in OWB to have multiple locations with the same host/post/service name information but different user or schema, this will result in having multiple data servers with the same JDBC URL in ODI after migration.
Solution: Do the following:
Create a new physical schema (pointing to the source) under the dataserver of the target.
Change the context for the logical schema for the original source to make it point to the new physical schema.
Symptom: The Migration Utility fails to migrate OWB mappings containing the Data Generator operator. The Data Generator operator is used to introduce constants or sequences into a SQL*Loader mapping.
migration.log shows:
--------START MIGRATE MAPPING MAP1_DATA_GENERATOR.
------------[ERROR][Migration][MU-5001]Unable to migrate mapping with mapping operator DATA_GENERATOR:DATA_GENERATOR.
--------FAILED MIGRATE MAP1_DATA_GENERATOR.
The Migration Utility does not support upgrading OWB mappings that contain the Data Generator operator.
Solution:
Before migrating, remove the Data Generator operator from the OWB mapping.
Migrate the mapping from OWB to ODI.
After migration add a constant or sequence (depending on the way the Data Generator was used) to the ODI mapping.
Symptom: When attempting to migrate an OWB Project with only a few selected objects into ODI 12c the result in unexpected.Instead of migrating in a 1 to 1 manner (for example to MY_PROJECT), the operation creates a new Project (ex MY_PROJECT_0) in ODI.
Solution: A new value for parameter MIGRATION_STRATEGY has been introduced in migration utility for ODI 12.1.3 and above. Change the MIGRATION_STRATEGY parameter from CREATE to NODUP.
Symptom: The OdiStartOwbJob utility is used to execute Oracle Warehouse Builder objects (e.g. mappings, process flows) from within Oracle Data Integrator and to retrieve the execution audit data into Oracle Data Integrator. Trying to configure OdiStartOwbJob, the Location listbox shows the location PlatformSchema. However all other locations are missing. Also a situation might occur where location PlatformSchema is listed together with only a subset of locations that can be seen in the OWB Design Client.
Cause: The location listbox of the OdiStartOwbJob utility, shows only locations that are registered in the OWB Control Center. Locations that are only registered in the Design Center are not listed by OdiStartOwbJob.
Solution:
Start OWB 11.2.0.4 Design Client and login to the OWB Repository.
Open the Control Center and register locations (target locations, process flow locations) that are missing in the listbox of the OdiStartOwbJob utility.
Exit from the OWB Design Client.
Start ODI 12c Studio and login to the ODI Repository.
Open the Package where OdiStartOwbJob is being used and verify that the location listbox of OdiStartOwbJob shows the registered locations.
Symptom: The OdiStartOwbJob utility is used to execute Oracle Warehouse Builder objects (e.g. mappings, process flows) from within Oracle Data Integrator and to retrieve the execution audit data into Oracle Data Integrator.
Starting an ODI package containing OdiStartOwbJob fails with:
ODI-13702: Unexpected error when connecting to OWB workspace OWB_WORKSPACE_OWNER.OWB_WORKSPACE_NAME.
StatementCallback; bad SQL grammar [SELECT LOCATION_NAME, LOCATION_TYPE, LOCATION_TYPE_VERSION FROM OWBSYS.OWB_ODI_LOCATIONS]; nested exception is java.sql.SQLSyntaxErrorException: ORA-00942: table or view does not exist.
Solution:
Check if required privileges are missing.
Using the query below, check if required privileges are missing:
connect owbsys/<password>
set lines 130
SELECT grantee,
table_name,
privilege
FROM user_tab_privs
WHERE table_name IN ( 'OWB_ODI_LOCATIONS', 'OWB_ODI_TASKS',
'OWB_ODI_TASK_PARAMETERS', 'OWB_SNP_SESSIONS',
'OWB_SNP_SESS_STEPS', 'OWB_SNP_SESS_TASKS',
'WB_RT_ODIAUDIT' );
Grant required privileges.
When required privileges are missing, grant the correct privileges using following grants:
connect owbsys/<password>
grant execute on wb_rt_odiaudit to OWB_USER;
grant select on owb_odi_locations to OWB_USER;
grant select on owb_odi_tasks to OWB_USER;
grant select on owb_odi_task_parameters to OWB_USER;
grant select on owb_snp_sessions to OWB_USER;
grant select on owb_snp_sess_steps to OWB_USER;
grant select on owb_snp_sess_tasks to OWB_USER;