10 Advanced Upgrade Options

You can set extra options for upgrading Oracle Data Integrator.

These are extra options that were visible in the 12c (12.1.3) Upgrade Assistant, but are hidden in the 12c (12.2.1.2) Upgrade Assistant. If you need these options, set them in the response file used in silent mode.

Table 10-1 Advanced Upgrade Options

Option name in 12c (12.1.3) Option name in 12c (12.2.1.2) response file Possible values (default = yes) Description

Option name in 12c (12.1.3)	Option name in 12c (12.2.1.2) response file	Possible values (default = yes)	Description
Upgrade repository to use GUIDs	`ODI_GUID.option`	yes/no	This selection sets the repository to 12c full mode. All objects are referenced using the 12c GUID rather than the internal ID. You should leave this option checked in order to take advantage of the truly universally unique identification scheme in Oracle data Integrator 12c. Note: This option only applies when upgrading from 11g repository. For the 12c repository, the option is ignored, and the repository stays in the same mode as before the upgrade. If you have custom Knowledge Modules and procedures that use `odiRef` substitution APIs, which take internal identifiers as parameters such as `getFlexFieldValue()`, you may choose to not select this option, leaving your repository in "11g compatibility mode." Scenarios generated from objects using such Knowledge Modules and procedures continue to work in "11g compatibility mode" but will not work in 12c full mode. "11g compatibility mode" can be used to smoothly transition the custom Knowledge Modules and procedures to use the new `odiRef` substitution APIs (the ones that take GUIDs as parameters). After all custom Knowledge Modules and procedures have been modified to use the new `odiRef` substitution APIs, the repository can be switched to 12c full mode. To change the repository to full GUID mode after upgrade (in case you did not choose the option in Upgrade Assistant during upgrade), go to Studio, in the ODI drop down menu, select the option Switch Repository Compatibility Mode. This brings up the option to switch to full GUID mode. If the repository is already in full GUID mode, then that option is disabled. For a list of all substitution methods impacted by the GUID changes, see Table A-1.
Upgrade interfaces to use 12c mappings - losing 11g SDK compatibility	`ODI_SDK.option`	yes/no	This selection converts all 11g interfaces to 12c mappings. Once converted to 12c mappings, all of the existing scenarios must be regenerated before use. There is no ability to use existing 11g SDK applications; they must be upgraded to use the 12c SDK. Some conversion is performed, but the resulting mappings are left in 11g compatible mode, which allows them to be modified using 11g Java SDK. But they can only be modified using 11g SDK; in Studio UI they are read-only. If this option is not selected, some conversion to 12c mappings are performed but the resulting mappings are left in "11g compatibility mode."After these interfaces are modified using the 11g SDK, they can then be converted to 12c mappings using the ODI Studio graphical interface or the 12c SDK. Oracle recommends leaving this option checked, unless you have significant amount of Java code that uses the 11g SDK to read or update existing interfaces. This option only applies when upgrading from 11g repository. For the 12c repository the option is ignored, and the repository stays in the same mode as before upgrade. NOTE: In order for this migration to work properly, all interfaces in 11g repository must be valid (for example, they should not return any errors when validating from 11g Studio, for example). If an 11g interface is not valid, the Upgrade Assistant will try to migrate it into a 12c mapping, but there are no guarantees about the result: the migration of that interface may fail, or exceptions may printed out the in log file. In any case the resulting mapping will be invalid. The best way to ensure a smooth upgrade is to make sure all interfaces in 11g repository are valid to start with. The upgrade process does not stop even if some 11g interfaces fail during the migration; the upgrade will continue until all interfaces are processed.
Use AES-128 encryption algorithm	`ODI_AES.option`	yes/no	AES with 128-bit keys provides adequate protection for sensitive information. AES with 256-bit keys is required to protect classified information of higher importance. If the option is unchecked, then AES-256 encryption will be used.

Upgrade repository to use GUIDs

ODI_GUID.option

yes/no

This selection sets the repository to 12c full mode. All objects are referenced using the 12c GUID rather than the internal ID.

You should leave this option checked in order to take advantage of the truly universally unique identification scheme in Oracle data Integrator 12c.

Note: This option only applies when upgrading from 11g repository. For the 12c repository, the option is ignored, and the repository stays in the same mode as before the upgrade.

If you have custom Knowledge Modules and procedures that use odiRef substitution APIs, which take internal identifiers as parameters such as getFlexFieldValue(), you may choose to not select this option, leaving your repository in "11g compatibility mode." Scenarios generated from objects using such Knowledge Modules and procedures continue to work in "11g compatibility mode" but will not work in 12c full mode. "11g compatibility mode" can be used to smoothly transition the custom Knowledge Modules and procedures to use the new odiRef substitution APIs (the ones that take GUIDs as parameters). After all custom Knowledge Modules and procedures have been modified to use the new odiRef substitution APIs, the repository can be switched to 12c full mode.

To change the repository to full GUID mode after upgrade (in case you did not choose the option in Upgrade Assistant during upgrade), go to Studio, in the ODI drop down menu, select the option Switch Repository Compatibility Mode. This brings up the option to switch to full GUID mode. If the repository is already in full GUID mode, then that option is disabled.

For a list of all substitution methods impacted by the GUID changes, see Table A-1.

Upgrade interfaces to use 12c mappings - losing 11g SDK compatibility

ODI_SDK.option

yes/no

This selection converts all 11g interfaces to 12c mappings. Once converted to 12c mappings, all of the existing scenarios must be regenerated before use. There is no ability to use existing 11g SDK applications; they must be upgraded to use the 12c SDK.

Some conversion is performed, but the resulting mappings are left in 11g compatible mode, which allows them to be modified using 11g Java SDK. But they can only be modified using 11g SDK; in Studio UI they are read-only.

If this option is not selected, some conversion to 12c mappings are performed but the resulting mappings are left in "11g compatibility mode."After these interfaces are modified using the 11g SDK, they can then be converted to 12c mappings using the ODI Studio graphical interface or the 12c SDK.

Oracle recommends leaving this option checked, unless you have significant amount of Java code that uses the 11g SDK to read or update existing interfaces. This option only applies when upgrading from 11g repository. For the 12c repository the option is ignored, and the repository stays in the same mode as before upgrade.

NOTE: In order for this migration to work properly, all interfaces in 11g repository must be valid (for example, they should not return any errors when validating from 11g Studio, for example). If an 11g interface is not valid, the Upgrade Assistant will try to migrate it into a 12c mapping, but there are no guarantees about the result: the migration of that interface may fail, or exceptions may printed out the in log file. In any case the resulting mapping will be invalid. The best way to ensure a smooth upgrade is to make sure all interfaces in 11g repository are valid to start with.

The upgrade process does not stop even if some 11g interfaces fail during the migration; the upgrade will continue until all interfaces are processed.

Use AES-128 encryption algorithm

ODI_AES.option

yes/no

AES with 128-bit keys provides adequate protection for sensitive information. AES with 256-bit keys is required to protect classified information of higher importance. If the option is unchecked, then AES-256 encryption will be used.

Table 10-2 contains descriptions of the combinations of options that may or may not be selected on the ODI Options screen.

Table 10-2 Possible ODI Options screen combinations

Replace Knowledge Modules with mandatory updates	Upgrade repository to use GUIDs	Upgrade interfaces to use 12c mappings	Description
Yes	Yes	Yes	This is the most common combination and is the configuration with which the new 12c repositories are created. With this combination, all objects use the new GUID identification, and all interfaces are converted into full 12c mappings, which can be modified in ODI Studio editors.
Yes	No	Yes	With this combination, the repository stays in ID compatibility mode, which means that `odiRef` APIs that use legacy numeric identifiers continue to work. Use this combination if you have significant number of custom Knowledge Modules or procedures that use `odiRef` APIs with numeric IDs as arguments.
No	No	Yes	With this selection, the Knowledge Modules existing in the repository are preserved and are not overwritten with the new 12c updates. Also, the repository stays in ID compatibility mode. Use this combination if you have modified default Knowledge Modules but would like to use full 12c mappings.
Yes	Yes	No	With combination, the 11g interfaces are converted to 11g compatible mappings, which can be accessed and modified through 11g interface SDK. These mappings are read-only in ODI Studio editors. Use this combination if you have significant investment in programs or scripts that use the 11g interface SDK.
Yes	No	No	With this selection, the repository stays in ID compatibility mode, which means that odiRef APIs that use legacy numeric identifiers continue to work. Also, the 11g interfaces are converted to 11g compatible mappings, which can be accessed and modified through the 11g SDK. However, they are read-only in ODI Studio editors. Use this combination if you have significant number of custom Knowledge Modules or procedures that use odiRef APIs with numeric IDs as arguments, and you have significant investment in programs or scripts that use 11g interface SDK.
No	No	No	If you do not select any options, the Knowledge Modules existing in the repository are going to be preserved and not overwritten with the new 12c updates. Use this combination if you have existing applications that use the ODI 11g SDK to read or modify these mappings, but you do not have modified Oracle supplied Knowledge Modules for your own purpose.

Table 10-3 describes the Invalid ODI Options screen combinations.

Table 10-3 Invalid ODI Options screen combinations

Replace Knowledge Modules with mandatory updates	Upgrade repository to use GUIDs	Upgrade interfaces to use 12c mappings	Description
No	Yes	No	With this selection, most Knowledge Modules will not function correctly since they will be using deprecated `odiRef` APIs, which use legacy numeric IDs.
No	Yes	Yes	With this combination, most Knowledge Modules will not function correctly since they will be using deprecated `odiRef` APIs, which use legacy numeric IDs.

Note:

The Upgrade topology and security metadata option can be selected or not selected independently of all the other options and has no effect on the other options.

Also Use AES-128 encryption algorithm option can be selected or not selected independently of all the other options and has no effect on the other options.

Parent topic: Troubleshooting and Advanced Configurations