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