ABAP Custom Code remediation

The migration of the ABAP custom code for SAP HANA can be split into two main areas:

• Modification of classical ABAP coding practice where data extensive logic is written in application layer. This step only deals with ABAP at statement level. We usually call it as HANAtization.
• Modification of ABAP logic using more advanced ABAP feature like AMDP, CDS or even HANA modelling and trying to push more ABAP layer logic to DB layer to take advantage of HANA db.

In the current document we discuss about the step 1 where we try to capture ABAP code places where modification is required as per HANA DB platform. Sometimes this modification is absolutely required and sometimes it is only recommended.

Tool Used,

The static code analysis provides insight about the part of ABAP code which are potential candidate for HANAtization. The SAP Code Inspector (SCI) or ABAP Test Cockpit (ATC) are the standard tools for this kind of analysis. This can provide set of checks that can be grouped into check variant.

Code Inspector performs a code analysis based on a checklist that comprises a defined set of development objects. The check variant contains the settings to configure the list of checks to be performed.  The objects set is required to define the different ABAP objects on which the inspection needs to be performed.

We use FUNCTIONAL_DB as SAP Code Inspector (SCI) check variant. This check variant is delivered with SAP Note 1935918 by SAP and is stepping stone for HANAtization process.

This check variant FUNCTIONAL_DB contains checks that are regarded as mandatory for the analysis of ABAP custom code as part of an SAP HANA migration. This checks primarily relate to the following areas: ROBUST PROGRAMMING, SECURITY CHECKS AND SEARCH FUNCTIONS for any ABAP patterns which we want to check.

Relevant Checks when migrating to SAP HANA suggested by FUNCTIONAL_DB:

Native SQL and database (DB) hints:

This will help us to locate parts of program where database dependent implementation of the past.  The ADBC interface is the critical part of the program where careful attention is needed as part of HANAtization. In some cases where HANA DB also supports the native SQL and which are unique SQL statement e.g. “truncate” in terms of performance etc. can be left without modifying. This unique SQL statement has no suitable Open SQL statement. These are exceptions to the most of the cases where we should be relying on Open SQL only.

• Native SQL example:

• DB (Oracle) hint example:

• Truncate statement example:

• ADBC (ABAP Database Connectivity) example:

• Database indexes check example

Depooling/declustering:

Pool/Cluster tables are converted to transparent tables in HANA db. This does not require any change to application. However, in the case of pool/cluster tables the database interface always supplements the ORDER BY PRIMARY KEY and any dependency in the old code needs to be adjusted by explicit sort of ORDER BY statement after the migration. Also any ABAP statement which might be affected by the order of internal table needs to be reviewed and modified accordingly.

ABAP code not captured by Static Code check tools:

There might be some ABAP code which cannot be captured by static code checks performed by Code Inspector. We need to manually check those codes to ensure those codes should be align with checks performed by these tools. The example of this type of code could be in form ABAP code of SMARTFORMS or SAP Scripts.

SAP index tables modification related ABAP Statement:

In S4 HANA due to the introduction of simple finance or simple logistics some index tables (e.g. BSIS, BSIK etc.) are being replaced by CDS views and any ABAP statements which are trying to modify these tables will not work in new framework. We needed to find solution to replace these modification statements.

SAP ABAP Pseudo code used to suppress Static Code check error or warning messages:

During HANAtization there could be scenarios where it is not possible to put code fixes to remove static code errors or warnings. In this situation one should provide document the reason for not having such code fixes and suppress the static code error or warning messages by putting pseudo code beside the appropriate code.

SOLUTION:

The Solution to the issues discussed in the above segment can be achieved by changing the code as per SAP HANA requirements, so that the existing custom ABAP code runs on the SAP HANA Platform without any glitches.

The solution to the above SAP Code Inspector issues can be resolved in the following way.

• For use of native SQL and database (DB) hints we will need to remove native SQL by replacing the existing code with OPEN SQL statements and need to remove (DB) hints from the existing code by commenting the (DB) hint statement from the code.
• For use of ADBC (ABAP Database Connectivity) should be restricted in HANA. When removing such uses developer should take care of object instantiation etc. which also need to be removed as part of it.
• For usages of special ABAP Dictionary function modules that check/provide the existence or technical properties of certain database indexes should be replaced by appropriate Open SQL queries.
• For accesses to technical use of pools/clusters table we must remember that SAP HANA no longer uses Pool/Cluster tables. Traditional use of pool/cluster table have been replaced by corresponding transparent tables in the SAP HANA DB. Hence queries on Cluster/pooled tables returns results sorted by primary keys is no more true here. Any customer coding which accesses physical table cluster/pool have to change with explicit use of ORDER BY clause so that the program reads from tables correctly
• For non-robust ABAP code that relies on a non-guaranteed/implicit sorting of certain SQL queries, even though no ORDER BY clause is used, must be replaced by adding proper Order By clause wherever necessary.
• For yes and SAPSCRIPTS code in the form itself, all forms are to be reviewed for potential errors or warning as found in Code Inspector for other regular programs. All code discrepancies need to be removed by putting the fix.
• For DB views which were secondary index tables previously need to be reviewed properly. These DB views are based on some transparent tables which are the key source for all main fields in the corresponding DB views e.g. BSIS DB view is based on transparent table BSIS_BCK, BSAD DB view is based on transparent table BSAD_BCK etc. The transparent tables can be used to modify in the ABAP code instead of the corresponding views.

I hope for the Custom code conversation to S4 HANA stage ,we can ensure that our custom code can utilize the benefits provided by SAP HANA environment and we can remove the previous dependency on application layer and can more rely on database layer as SAP HANA’s in memory architecture provides much greater advantage than the conventional databases.