5 important things to know about transporting objects in SAP Sourcing/CLM

Often times question comes up on whether transports in Sourcing/CLM are same as transports in a traditional SAP application. The answer is, it’s not quite the same. Sourcing/CLM uses a technique called Object Migration. The purpose of Object Migration is same as transports in SAP, but that’s where the similarity ends. Object Migration uses OMA (Object Migration Archive) file to transport configurations and master data objects. The process involves exporting objects from the source system to an OMA file, store the OMA file on the disk, and finally import the OMA file in the target system. There is also another approach using Excel workbooks to transport certain objects (more on this later). Generally in an On-Premise deployment, the export from the source will be performed by the person who is doing the configurations or by the developers. The import into the target system will be performed by the BASIS team.

In this blog my goal is to explain the 5 most important things that you should know when dealing with transports in SAP Sourcing/CLM.

One: Plan transport strategy early on in the project

Applies to – Project leads, developers, security team and BASIS team

Often in Sourcing/CLM implementations there is little importance given to planning of transport strategy. This is primarily due to two reasons – 1) The implementation team assumes transports in Sourcing/CLM works the same way as other SAP applications, 2) The implementation team is aware that transports can be done using OMA but do not fully understand how it works and some of the nuances involved. Lack of planning would result in issues later on in the project, potentially during cutover activities which could seriously impact the go-live date. 

When it comes to transport strategy for Sourcing/CLM, an important step for the project technical team is to come up with a plan very early in the implementation cycle. There are several key advantages to this approach.

First let’s take a look at transport options we have. There is couple of different ways configurations can be transported in Sourcing/CLM – 1) via Object Migration (using OMA) and 2) via Excel workbooks. Although Object Migration may seem like an obvious choice to perform transports between Sourcing/CLM landscapes, for certain objects using workbooks is a better approach. For instance, transporting extensions, it is better to use workbooks because you have more control over what extensions get transported. However, for this approach to work; the extensions should be created in the source system via the workbook right from the beginning and manual creation of extension should not be done in the target system. Now let’s look at couple of other examples. For scripts and queries and reports, Object Migration is your only choice. For objects like Page Customizations, Localized Resources, etc. you could either use either OMA or workbooks. The key is to plan early on what the migration strategy should be used for each object. You may consider creating a spreadsheet containing information on this and shared with everyone involved in realization phase of the implementation. The screenshot below shows an example of what that document could look like.

Once the transport strategy has been finalized it is very import that it is clearly communicated to the implementation team. The security team should be involved to help plan appropriate security roles and roles assignments for the project team.

Two: Naming conventions

Applies to – Script developers, Report developers, Workflow developers, Configuration team

Naming Conventions are especially important when it comes to transports in Sourcing/CLM. Object Migration offers the user the flexibility to extract selected objects to migrate. For instance, you may have created several custom queries and may want to transport only those custom queries to another landscape. The Object List option in Object Migration allows you do that, however, the key is that the naming convention of the custom queries should be consistent. If no naming convention is followed by the project team, then Object Migration could become time consuming and potentially error prone.

It’s a standard practice to have all custom script definitions, query definitions, reports, etc. to start with CUSTOM- or Z-. This allows the user to use the Object List option to selectively export only the custom reports.

Three: Release number and IDs of the source and target system

Applies to – Script developers, Report developers, Workflow developers, Configuration team, BASIS team

In order for Object Migration to work, the source and the destination system should be in the same release number including the patch level. For instance, if the Source system is Sourcing 7.0 SP2 Patch 6, the target system should also be in the same SP and Patch level. It is not possible to use Object Migration on systems that are on different release numbers.

Typically On-Premise deployments will have 3 or more landscapes. Because of the aforementioned requirement, careful planning is required as object migration will not be possible if the “gold” system where all the configurations are performed is on a newer patch release than the target system.

Another important point to note here is that, the baseline configurations (typically done by BASIS team) for source and the target system should have been created with same ids. For instance, the Context id, Directory Configuration id and Cluster Configuration id must match between source and target systems. Manual editing of OMA file is NOT supported and should not be attempted.

Four: Change management approval process

Once the objects are exported from the source system to an OMA file, the OMA file is typically stored on the user’s machine and then imported into the target system. There is no standard integration with Solution Manager to manage and the approve transports. If there is a need for an approval process, one option is to use ChaRM tool which is delivered with SAP Solution Manager. Note that ChaRM is used only for storing and managing OMA and workbooks approvals. The import of OMA or workbook would have to done manually.

Five: Delta changes

Transporting delta changes between landscapes should be paid careful attention. A plan should be in place and communicated to the implementation team. For instance, for extensions, if the transport mechanism is workbooks then it is very important to stick to that for delta changes as well. Mixing workbooks with OMA for extensions should be avoided and could put the system in an unstable state.  If Page Customizations are managed via workbooks, it is important to follow the same process for delta changes as well. By performing page customizations manually via the UI may result in system being out of sync.

To be in full control of what objects are being migrated, for certain objects the Data Set option should be avoided. For example, using Data Set option for Query Definitions is not a good idea as it will export all the Query Definitions in the system (both standard and custom ones).

Other useful info

From Sourcing 7.0 SP3 and above, SAP provides a tool to delete inactive extensions from the system permanently. This tool could be used prior to object migration so inactive extensions are not created in the target system.

Depending on the content of the OMA file, it could be potentially disruptive to import the OMA file during normal business hours. Best practice would be to do it after business hours and communicate the changes to the end-user community. For example, transporting configuration to make a field required when end users are using the system could be confusing.

After importing the OMA file the system admin/core user should verify that the expected changes are created/modified in the target system.

Name of the export.oma should be changed.

If using workbook for extensions make sure the class names are grouped together and not inter mixed.