CTS+: some specific upgrade issues

Introduction

We have few options available for moving the development objects in the native SAP HANA landscape, in a customer environment.

They are manual export import (not recommended), Native HANA transport or the Enhanced Change and Transport System (Enhanced CTS or CTS+).

In comparison, CTS is mainly for ABAP and non-HANA environment, where Enhanced CTS or CTS+ can support non-ABAP SAP environment’s promotion management (HALM and CTS work together; which is like a handover of development objects still managed by HALM are transferred to CTS).

There were few issues faced while implementing the Enhanced CTS solution in an already existing production landscape. This basically means, that the Enhanced CTS implementation is done with the previous promotions happened using some other option(s).

Enhanced CTS transport methodology also uses the native SAP HANA’s HALM (HANA Application Lifecycle Management) tool to collect the changed objects either as Delivery Units (DU) or as individual (released) Changelist within a DU. If you want to understand more on HALM, please refer to the following blog Transport of HANA objects with HALM

Once the objects are collected they are handed over to the CTS+ transport system so that the changes can be imported as normal SAP transport requests in the target systems.

One major difference between the Native HANA transport and Enhanced CTS is, with native SAP HANA transport, performing an import means that you are on the target system and you pull an export from the source system using a configured transport route. Therefore, each import in a production system triggers a separate export from the test system.

Now, if you have multiple production systems, you must ensure that the test system remains unchanged while you are performing imports in the production systems.

Unlike this, with Enhanced CTS, you have a transport created that is available for import into multiple target systems. So, with Enhanced CTS, other than helping the non-ABAP objects transport support, you go with the proven CTS mechanism which has the changes captured and available in a transport request for multiple imports, if needed.

Fig: General ABAP and Non-ABAP objects transport mechanism in CTS+

Fig: Enhanced CTS, high level process overview

First issue:

We faced few issues at the customer implementing Enhanced CTS, because, like many other initial customer environments, the plan was to keep the system open with no change tracking in place, till the best methodology is decided for the transport mechanism. So, when the decision time came up with the customer need to implement Enhanced CTS, many development objects were already in the production with business relying on them. We have to take that into consideration while implementing the change methodology, as we do not want to send a FULL re-transport of the development objects into Production as we have version differences between the two systems because of continued development. Question is, how to make sure the production objects (versions) are not overwritten by the current development objects, at the same time bring the landscape under CTS+?

Second issue:

This was due to the upgrade of the SAP HANA environment from HANA 1.0 SPS 12 to HANA 2.0 SPS 03, meaning that also moved the system from Single Database Container to Multi-database Container. This causes few issues, as there two sets of tables available for managing the CTS+. First is the Repository tables like CHANGES, CHANGE_ENTRIES, CHANGE_CONTRIBUTORS, PACKAGE_CATALOG etc., and HALM table TRANSPORTED_CHANGE. As the source system name (ID) changes from what it was in SDC to what it is at MDC, this will affect how the objects are transported from the source to the target system.

How do we make sure, we do not send the Full DU again, considering two things. First, the objects that are already sent to the target system; Second, the source system name has changed.

Below I have provided how we handled both the issues at our customer project.

Issue:

Implementation of Enhanced CTS in an existing SAP HANA production landscape

When you have different version of development objects between the systems in a production landscape, where the objects were managed manually before using export and import of the HANA development objects, it is not easy to implement Enhanced CTS, with the standard process.

Normal process, after the change tracking is enabled with the Enhanced CTS implementation, the base Changelist created for the first time, contains all the objects in a delivery unit (mapped to package(s) in the HANA content) though the user has selected only one object for the change. This is the base Changelist creation as this is the first time a change is being sent to the target system known to HALM. (ignoring all the export and import that happened before). If transported, all the changes in the target system will be wiped out and will be replaced with the current version of the source system (probably, the development system is the source system).

Our landscape is in production already, and some of the objects are in newer versions in development in comparison to what is already moved to Test or in Production. Of course, no one wants to wipe those out and replace with the current version of the objects that are in the development system.

Here is how we handled that scenario.

Resolution:

The objective is to make the source and target systems sync up at the DU level, and at the same time, not lose the objects in their current versions as they are in the target systems. The sync up is needed because once that happens by bringing the base Changelist from the source to the target the next transports will bring only the differential or delta changes since the last transport (with the required predecessors included, if there is any).

First backup all the objects in the target system to a local backup in SAP HANA. Secondly, In the source system HALM, create and release the Changelist, attach the Changelist to a transport request (Need better care here, in general, if you select DU instead of “Released Changelist” it would always overwrite the target system’s package with Full transport of the DU), and import that transport in the target system. You would see the “Released Changelist” as well as the “Base Changelist” as expected for the first time.

Having overwritten whole package in the target system (assuming you are assigning one package to one DU in the CTS+ DU configuration), now, staying in the target system, delete all the imported objects under that package. And restore from the local backup done before for the relevant package.

This creates the record in the source system, that from now on, it will only send the delta changes during the next Changelist release, even though the earlier sent objects are overwritten by our local backup to maintain the correct version of the production objects.

Note:

One can see the tar zipped (tgz) files in the Transport object list, if there is only a Changelist, there will be only one tgz file with the Changelist number included in the name of this file. But, if this is the first time a Changelist is sent for a DU, there will be another tgz file with no reference to the Changelist that is being sent, which contains the base Changelist objects.

Issue:

Upgrade and conversion to MDC and its effect on Enhanced CTS

There is a specific change management table “sap.hana.xs.lm.db::TRANSPORTED_CHANGE”, which does not get updated for the the SRC_SYSTEM to change from SID (which was SDC) to SID@TENANTDB (which is now MDC).

This table maintains the Change pointers for the transports.

Because the source system is having a new name after the upgrade and conversion to MDC, the development systems assume that it is sending all the changes for the first time now. Since the target system has already received many of these objects (which might possibly be older tested versions of the source system objects), we do not want to overwrite all the target system objects with the Full DU.

Now the question is:

How this can be fixed so it brings only the delta changes instead of the full DU because of the source system name change?

Resolution

There is an OSS Note provided for this, but it is not completely helping at this time. (a correction was planned to this note, at the time, we were talking to the support).

For the table “sap.hana.xs.lm.db::TRANSPORTED_CHANGE” at the Source system alone, we ran the update command for the source system.

update “SAP_XS_LM”.”sap.hana.xs.lm.db::TRANSPORTED_CHANGE” set SRC_SYSTEM = ‘<NEW VALUE>’ where SRC_SYSTEM = ‘<OLD VALUE’>

After running this command, the system recognized that there were some changes already sent to the target system so, now it correctly sends only the delta changes.

Additional pointer:

Similar to this issue, if you are getting a warning during the views editing (warning: editing objects under package with different source system is not recommended), most probably there is a mismatch between the source system name in the package_catalog repository table and the actual system name.