Components, Compatibility, and Upgrading of the ODI SAP Adapter

C Components, Compatibility, and Upgrading of the ODI SAP Adapter

It is important to understand the components and compatibility of the ODI SAP Adapter. You can also upgrade to a new ODI SAP Adapter version if required.

This appendix includes the following sections:

Components

The ODI SAP ABAP Adapter consists of three components:

ODI SAP LKMs and ODI SAP RKMs
ODI SAP OpenTool (odi-sap.jar)
ODI SAP Components

The KMs connect to the SAP system either via the SAP JCo or via the ODI SAP OpenTool (which internally also uses the SAP JCo). So either directly or indirectly the KMs connect to the SAP system and call RFCs delivered as part of the ODI SAP Components.

Note:

Please note the following points:

KMs are centrally installed in the ODI repository and are shipped with ODI Software or patches.
The ODI SAP OpenTool (odi-sap.jar) is part of each local ODI software installation. This applies to ODI Studio installations and ODI Agent installations. The OpenTool is part of the ODI Software.
The ODI SAP Components must be installed in every SAP system which ODI is to connect to. This installation is done as part of the Installation of the ODI SAP Adapter.

Compatibility

The following are a few rules regarding compatibility:

Newer KMs often require a newer OpenTool version. The required minimum OpenTool version is given in the KM description. The OpenTool version can be checked by executing the odi-sap.jar using java -jar odi-sap.jar.
Newer KMs often require newer ODI SAP Components. The need for updating is described in the respective release or patch note.
ODI OpenTools are backward compatible: any OpenTool can be upgraded to a newer version without impacting existing ODI mappings or ODI Scenarios.
Existing ODI Scenarios work with newer ODI SAP Component versions and newer OpenTool versions.

Upgrading the ODI SAP Adapter

Note:

The primary source for upgrade steps are product or patch release notes. There may be other steps required than just the ones described below.

If you have any doubts, contact Oracle Product Support.

Unless otherwise specified, upgrading to a new ODI SAP Adapter version consists of the following steps:

Upgrading the OpenTool

There should not be any need to manually upgrade the OpenTool, as it is shipped as part of the ODI Software or Patch. If needed, the OpenTool is upgraded, by replacing the odi-sap.jar.
Upgrading the ODI SAP Components

Upgrading the ODI SAP Components is described in Updating ODI SAP Components.
Upgrading KMs

In case the SAP Adapter update has happened as part of an ODI Update, KMs may have already been replaced by the Upgrade Assistant, if Replace KMs with Mandatory Updates had been checked. If not, there are two methods for manually updating the KMs in a repository. Please choose based on your requirements. Both methods may be combined, for example, start with method 1 for a few mappings and if tests have been successful, method 2 can be applied.

Note:

No matter which KM update method is used, it is recommended to test all mappings.

Method 1: Add as new KMs

This update path leaves the existing KMs unmodified and imports the updated KMs as new KMs. All existing mappings and existing ODI Scenarios will stay unchanged. This approach allows a step-by-step update to the new KMs, but requires every mapping / model to be updated to use the new KMs.

Import all new KM files in Duplication mode inside your project or as global KMs depending on what you have been using so far. This will create new KM objects.
Rename each KM from Copy of <KM Name> to <KM Name>. For example, Copy of LKM SAP ERP to SQL to LKM SAP ERP to SQL v38.
For every mapping / model (which should use the updated KMs) switch the L/RKM to v38, for example LKM SAP ERP to SQL to LKM SAP ERP to SQL v38.

Note:

Existing ODI Scenarios will stay unchanged, until they are regenerated.

Replace existing KMs

This update path replaces the active KMs inside the repository with the new versions. Any mapping or model using the old KMs will immediately be using the updated KM. Existing ODI Scenarios will stay unchanged, until they are regenerated.

Steps to repeat for every KM:

Take a backup of existing KM. For example, right-click the KM and click Export.
Right-click the KM, select Import Replace..., select the corresponding new KM file and then click OK.
No changes required to any mappings or models.

Note:

Existing ODI Scenarios will stay unchanged, until they are regenerated.

Upgrading from ODI 11g to ODI 12c

ODI 12c introduces GUIDs for identifying repository objects (as opposed to internal ids as in ODI 11g) and mappings (as opposed to ODI 11g interfaces). The introduction of GUIDs means that any odiRef API call using internal ids will fail, unless the 12c repository is in legacy mode. The 11g ODI SAP scenarios use internal ids and thus will only work in the 12c legacy repository mode. Another implication of moving to GUIDs is that the default ABAP_PROGRAM_NAME will change during upgrade. Please note that this default ABAP_PROGRAM_NAME is intended only for convenience during development. See Managing ODI SAP Transport Requests for more information.

Note:

Any explicitly set ABAP_PROGRAM_NAME KM option will remain unchanged.

Evolving from 11g interfaces to 12c mappings means that during upgrade any 11g interface will be converted into a new 12c mapping object. This new mapping will still represent the very same data transformation, but its new 12c semantics will result in a different ABAP code being generated even when using the very same SAP KM version.

Upgrade Path

The upgrade path keeps all the existing ODI SAP scenarios running in ODI 11g for a start (phase 1). In a later step-by-step migration, the ODI SAP scenarios are regenerated/redeployed and then execution for these scenarios is switched from ODI 11g to ODI 12c (phase 2). The upgrade path is in line with general ODI upgrade recommendations.

This upgrade path has the following advantages:

No ABAP redeploy needed in phase 1
No ODI scenario regeneration needed in phase 1
Use of latest SAP KMs (latest fixes/features) for every phase-2-upgraded mapping

The only inconvenience would be the parallel use of ODI 11g and ODI 12c (completely separate repositories and agents).

Phase 1: Use ODI 11g

In the first phase, we preserve the existing ODI 11g repository and execution environment and set up a new parallel ODI 12c environment. This phase consists of the following steps:

Upgrading from ODI 11g to ODI 12c using all default options (Replace KMs) following the standard ODI upgrade instructions.
Preserving the ODI 11g environment. Do not run any in-place upgrade, as you will continue using the ODI 11g environment.
Continuing use of ODI 11g for running any ODI SAP jobs.

Phase 2: Migrate to 12c

Over time, all ODI SAP interfaces/scenarios need to be regenerated and redeployed. Once an interface/mapping/scenario has been redeployed using ODI 12c, the execution of the respective 11g interface/mapping/scenario should be disabled (e.g. deactivate in 11g scheduler), as the job is now run from ODI 12c. Phase 2 consists of the following steps:

Following upgrade instructions for ODI SAP Components. See Updating ODI SAP Components for more information. This step only needs to be executed for the very first SAP interface being upgraded.
Regenerating ODI SAP mapping/scenario.
Redeploying generated SAP ABAP code using ABAP_UPLOAD = true. See Controlling ABAP Uploading / ABAP code in production for more information.
Following standard procedures to deploy ODI scenarios into production. For SAP specific details, please see Moving ODI and SAP Components from Development to Production.
Deactivating execution from ODI 11g environment and activating execution from ODI 12c environment (e.g. by updating schedulers).

Once all ODI SAP mappings/scenarios have been migrated, the ODI 11g environment can be switched off.