Best Practices for SAP HANA Application Life Cycle Management

Having worked with multiple customers in the Native HANA application development and analytics space, one challenge I have often seen is with migrating (or transporting – we use these interchangeably in this blog) the development objects to higher environments in the landscape. Before we get into the details of how to transport the objects, let us see how the development objects are organized in HANA.

Development content organization in SAP HANA:

The development content is organized as shown in Figure 1, the most granular element in the hierarchy is an Object – which can be a calculation view, xsjs code, xsodata code, hdbprocedure etc. These objects are grouped into Packages. A Delivery Unit (DU) can consist of multiple packages. Multiple DU’s make up a product.

Figure 1: Organization of Development objects in SAP HANA

Object Migration Options in HANA

SAP have given multiple options to transport objects between various systems:

1. Export and Import the individual objects manually
2. Export and import the Delivery Units
3. Use HANA ALM in Native mode
4. Use HANA ALM with CTS

The decision tree to choose the transport option with HANA is illustrated in Figure 2.

Best Practices for using HALM

While the SAP Help documentation clearly defines the pre-requisites and Do’s & Don’ts for implementing HALM, a few things are often overlooked by developers and administrators resulting in a few issues.

1. As early as possible in your Development life cycle, define the package organization. For eg: if you are developing reports for Finance and Sales teams, would be a good idea to have a FINANCE Package separate from SALES. Keep one package for commonly used objects

2. Similarly determine the number of Delivery Units (DU) required. Will be prudent to consider your delivery timelines while making this call. For example if SALES reports are due to go-live in MARCH and FINANCE reports will go live in JUNE – create DUs for SALES and FINANCE separately. This will avoid transporting untested content to the production environment.

Note: Once a DU is migrated, all the content assigned to that DU will be migrated

When the CTS tool works with HALM, each time you try to attach a newly released change to a transport request, the system computes a list of all Released but Un-transported changes in each DU assigned to the transport route. System uses the Oldest Released time-stamp against all packages assigned to the DU. This could be a very time consuming activity and affects the performance of ALM.

Let me illustrate with an example

DELIVERY UNIT	PACKAGE	LAST TRANSPORT TIMESTAMP
DU_SALES	PACK_MASTERDATA	01-JUNE-2016 1600
	PACK_RECONCILIATION	28-FEB-2017 1700

Let us assume you first migrated the project with all objects on 01-June-2016 and since then testing was underway. All objects under master data have no modifications. Whereas, you are adding or modifying objects in the RECONCILIATION package. When you try to attach a new change in RECONCILIATION package to CTS, the system will try to pull the list of all changes since 01-JUNE-2016 16:00 Hrs – since that is the oldest transported timestamp amongst all packages in that particular DU.

4. Thus with regards to assigning Packages to DUs try to assign those packages that change more frequently to one DU and assign the packages that do not change often to a different DU

5. The maximum size of a DU can be 100 MB, therefore continue to keep an eye on the DU growth from time to time

6. DU dependency viewer, shows the incoming and outgoing dependencies, use this tool to sequence the DU migration so that there are no errors in the target environment

7. Ensure that special characters such as %. @, & etc are not used as part of the change ID description – as in some versions of HANA, these are construed as wild card characters leading to unexpected results

8. To improve the performance of CTS with HALM, perform full DU export whenever the