SAP SRM-MDM Catalog Migration from Solaris to IBM AIX 7.1

Body

Author: Abdul Mohammed, IBM Systems Lab Services

Brief background

An IBM client was running almost all SAP components (like SAP ECC, PI, BW, SRM, SAP Netweaver MDM 7.1, Portal for SRM, Portal and databases like Oracle, MaxDB, SAP HANA and couple of non-SAP interfaces) to accomplish its daily business transactions on the Solaris platform. Its existing hardware infrastructure was nearing end of life and in need of a refresh. During the refresh the client opted to migrate to POWER8 infrastructure, as it realized that AIX is the only UNIX operating system with a strong roadmap.

The uniqueness of this opportunity was utilizing the Oracle Transportable Database (TDB) method for migration of a MDM database from Solaris to AIX. There was no proper procedural document from SAP, nor did we have prior experience of utilizing the TDB method for migration of a SAP MDM database. After careful study and consolidation of supporting documents from Oracle and SAP, we documented the procedure and utilized it to achieve the migration.

General overview on SAP MDM and SRM-MDM Catalog System

SAP NetWeaver Master Data Management is a component of SAP's NetWeaver product suite and is used as a platform to consolidate, cleanse and synchronize a single version for master data within a heterogeneous client system, which includes SAP applications and non-SAP applications. Master data can be details of materials, vendors, customers, products, retail articles, business partners, employees and so forth.

The SAP MDM system does the whole range of activities of importing, cleansing/de-duplication and distribution of the master data to and from the connecting SAP application. The SRM-MDM catalog system setup provides catalog content management functions and a procurement catalog, enabling users to search, compare and procure products and services from suppliers.

In this scenario, the client was using an SRM-MDM catalog system setup to publish a supplier’s products, services and contracts to a procurement application like the SAP SRM system.

Proposed solution

The client we were working with used multiple types of SAP client software to connect to the SRM-MDM server.

The prerequisite for establishing connection between the client software and MDM server is that their version and SP level should be same. On the source environment, the client software version was on a higher level than the MDM server. To overcome this issue, we proposed to upgrade the SP level after migration of the MDM server.

Below is the comparison between source and target environment.

Migration approach

We had two options to migrate:

1. Migrate database + Install MDM server
2. Build new Oracle database on target + archive and unarchive repositories

We chose option #1 for following reasons:

• Same endianness of source and target
• Source database had multiple old repositories
• Multiple schema users in source
• SAP BR*Tools configured

With database migration, we were confident about seamless migration of all objects. This helped us eliminate the following overheads:

• Creating new database and running post scripts
• Creating schema users and granting authorization
• Running ‘n’ of steps to configure SAP BR*Tools. Check SAP note “320457 - Installing BR*Tools on a non-ABAP database”

Migration challenges

The challenges faced as part of migration were:

• Existing SP level incompatibility between MDM components of SAP EP and SAP MDM server
• High availability setup for MDM server and Oracle DB
• DR setup for MDM server and its Oracle DB
• MDM component’s SP difference in DEV, QA and production systems of portal landscape

Post migration Issues

• MDM console was not connecting to database due to difference in ORACLE_HOME for <sid>adm and ora<sid>
• Verify repository check detected errors. After running repository repair the issue was resolved

IBM Systems Lab Services has proven expertise on SAP migration. If you want to engage the IBM Systems Lab Services team, you can contact us at ibmsls@us.ibm.com.