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.
Great blog, dont know, how I missed reading it, but you had explained this in greater detail in the CLM webcast series.
I am really waiting for that day to see the transport enabled via CTS+, is this possible without having portal business content for this application
I have had requests from various customers, that the CHARM integration into the change management process becomes cumbersome and loosely coupled with the OMA and the csv transport methods.
Just like in EP, when a custom JAVA object is developed and transported via CTS+, it would be a blessing for folks that have a very tightly coupled Change Management process
..just a wish list from my long standing list
Great thought leadership content again to the install base
You will know how to change the time zone used in SAP CLM, is through a Workbook or is there a specific way you can change ... Thank you in advance for your answer
There are different areas in CLM where timezones are used. User accounts have a timezone field which is set depending on timezone of the location of the user. This can be done manually on the UI or via an import file. There are couple of system properties (syste.default.timezone and system.master_timezone) that are configured at the system level. These system properties can be accessed by logging in as the system user. This is typically a onetime setup performed by the system admin type of user.
Hope this helps.
Thanks for answer,
I'm looking to change the default time zone for a specific country, Chile, however, and the time zone was set. Chile has time change, it is possible to reconfigure this?
Excelent blog Vikram! Thanks.
Great information, Vikram. I'm wondering if there's been any progress made on integrating OMA export/import into CTS+ in a meaningful way. We had configured it for OMA file movement, but had no way to control that the file being imported was the one moved by CTS+. Do you have any updates on this? Thanks!
Great Blog and very useful.