Few words about SAP transports

For developers coming to SAP world from different ecosystems it is sometimes confusing to understand how does SAP (e.g. within NetWeaver) works with transporting of developer objects. As a starter, there are few terminology things as per different types of development objects transporting:

ABAP world:

Change and Transport System (CTS) - organizes development projects in ABAP Workbench and in Customizing, and then transport the changes between the SAP systems in system landscape.

Transport Management System (TMS) - it is infrastructure for the transports, provides tools to configure transport routes, display import queues, import requests, transport workflow etc.

Non-ABAP world:

The CTS is used to transport ABAP objects. There is also Enhanced Change and Transport System (CTS+), used to transport also non ABAP objects, mostly JAVA based artefacts (like SAP BusinessObjects, SAP Cloud Platform, SAP Enterprise Portal, SAP HANA. SAP Hybris Commerce Suite, SAP Manufacturing Integration and Intelligence (SAP MII), SAP Mobile Platform, SAP NetWeaver Development Infrastructure (NWDI), SAP NetWeaver Master Data Management, SAP Process Integration (PI), etc.).

HANA world:

When it comes to HANA development artefacts there is so called SAP HANA Application Lifecycle Management (HALM) or CTS+ for SAP HANA. It is used to move HANA objects throughout their application development lifecycle. There is also SAP HANA Transport for ABAP (HTA) that can be used to synchronize objects and packages from the SAP HANA repository to the SAP HANA Transport for ABAP repository (HTA repository) in the ABAP system and add them to a transport request. Concerning this there is SAP HANA Transport for ABAP for SAP HANA Deployment Infrastructure (HTA for HDI). The HTA for HDI is the successor of HTA. T-code for HTA is SCTS_HTA.

SCP world:

Lastly when it comes to SAP Could Platform (SCP) there is suite of solution to support change management of either pure could related development artifacts (so called cloud native) and hybrid applications.

Now back to ABAP world. At last year TechEd there was a git-enabled CTS (gCTS) solution presented. This is basically the SAP move towards DevOps thing that is present in non-SAP ecosystems. SAP is trying to leverage state-of-the-art processes and tools that are out there mostly in form of open source project within the SAP change management. It comprises of two main components:

• Git-based versioning like branch and merge support

• Connect ABAP processes with Continuous Integration (CI) tools (e.g. Jenkins, Bamboo, GitLab, etc.)

For me this is still quite a faraway future. These tools are currently not present in SAP system out-of-the-box. It is a usual case that to deploy it they require a significant effort to implement it. There needs to be other non SAP server available to run e.g. CI server etc. Because all of these many customers are not getting all advantages of DevOps. Thus are stuck with old technology, only utilizing what is available out of the box from SAP. As a side note the CI is a complex topic but it is a practice of merging all developers working copies to a shared code line several times a day.

Note that there is also abapGit as open source project. However, SAP is not using it and they came up with their own implementation of the git for purposes of the gCIT.

One more remark on how SAP NetWeaver transports are working. It is an important thing is to understand that in SAP NetWeaver transports only records that a change was made to a particular object. It does not records what the change was about. In other words, the systems always create a kid of a snapshot of the involved object. For the version, management there is a different thing – Version history, build in developer t-codes like SE8/SE38 (going forward all this will be replaced by the git based repositories). Also all the changes done are only stored in original system (so called development system). They are not moved to any other system in the landscape. It means that complete version history of all repository objects are only remain in the development system. This is also in line with SAP strategy that advises customer to always retain the development system. There can be special cases in case the DEV is being replaced (deleted or somehow not planned to be used anymore) and there is a need to get all the version history to the new DEV system. In such a case see SAP Note 130906 - How can versions be transported?. It describes possible workaround to exported the complete version database and import it the other system (e.g. a system copy of “old” DEV system).

The fact that system only records object into which the change was done is important to understand as there may pop up many transport collisions between multiple developers working on same objects. E.g. in case there are several methods being developed in one ABAP class it is not possible to just move the one method and do not include others which are there. Simple just to put an entry like LIMU METH <method_name> into the transport request won’t move the particular method. Along such an entry, also the whole class definition (R3TR CLAS <class_name>) needs to be present in the transport request.

More information:

ABAP: CTS, gCTS

nonABAP: CTS+

HANA: HALM

SCP: Software Logistics for SAP Cloud Platform