Why and How to adopt ABAP Custom code on HANA Database? (2023)

This blog is targeted to ABAP technical team working on S4 HANA conversion OR Suit on HANA migration projects.

As we know in Suit on HANA migration and S/4 HANA conversion projects conventional database is replaced by HANA database. Custom code which was running on non-HANA database earlier will not work as it is since HANA database doesn’t sort the data implicitly, it needs to be sorted explicitly.

Hence it is necessary that customer adapts the custom code with respect to HANA database after migration/conversion.

Let’s us consider that customer has completed the migration and conversion. Activities like Unicode conversion, SUM execution, SPAU/SPDD activities are completed. And next activity is custom code adoption/Remediation.

I will try to cover following questions in this blog post based on my experience working on S/4 HANA conversion and Suit on HANA migration projects.

1. What are the pre-checks be performed before starting the code adoption?
2. How to analyze the impact on custom code impact while migrating to HANA database?
3. Which ATC issues need to be fixed to adapt the custom code with respect to HANA database?
4. What is the solution of the ATC issues?

Pre-checks to be performed before starting the custom code impact analysis.

In Transaction SCI, check if check variant FUNCTIONAL_DB and FUNCTIONAL_DB_ADDITION are available. If not available, check and implement following SAP notes.

Note: FUNCTIONAL_DB_ADDITION check covers additional performance related checks. Execute this check variant to identify and fix the cases where “Unsecure use Of for All Entries is used.”

If customer NetWeaver system is >7.4 and <= 7.5

1912445 – ABAP custom code migration for SAP HANA – recommendations and Code Inspector variants for SAP HANA

1935918 – Downport Code Inspector Check Variants for HANA Migration

If customer NetWeaver system is > 7.5

Open Transaction SCI and check if check variant S4_HANA_READINESS_<release version> is available. If not available, check and implement following SAP notes.

2436688 – Recommended SAP Notes for using S/4HANA custom code checks in ATC or Custom Code Migration app

FUNCTIONAL_DB FUNCTIONAL_DB_ADDITION

Screenshot 3: S4HANA_READINESS

In Screenshot1 and Screenshot 3, Security Check ad Robust programming checks cover the SAP recommended checks to be performed on the custom code.

Note: This blog is not intended to cover the “S4 HANA Custom Code Checks”.

Activities to be performed before codeAdoption/Remediation.

Execute the check variant FUNCTIONAL_DB and FUNCTIONAL_DB_ADDITION on entire custom code using ATC or SCI transaction. You can also include custom namespaces in case those are also required to be remediated.

In case of S/4 HANA conversion, execute S4_HANA_READINESS_<release> check variant. This check variant covers the checks of FUNCTIONAL_DB. Hence it is not required to execute FUNCTIONAL_DB check again.

Execute ATC Transaction

Execute the ATC check on Z* and Y* packages and also on modified objects.

Check Title and Check Message show the various the ATC issues captured.

Now let’s see what the different issues captured in FUNCTIONAL_DB check and how those can be fixed.

1. Syntax Error

For Example: Syntax error in in SAPLXEDF.

This check shows the objects in the Syntax error. Unless these syntax errors are fixed, these objects cannot be analyzed as well. Hence fix all such objects in syntax errors and again execute the ATC checks on such objects.

2. Missing Objects

For Example: Used object Screen 9000 does not exist.

This check shows the missing objects like includes screens etc. Unless these errors are fixed, these objects cannot be analyzed as well. Hence fix all such objects have missing objects and again execute the ATC checks on such objects.

3. Use of Database Hint: %_HINTS

Below is the OPEN SQL statement written with underline database as non-HANA database.

After migration to HANA database, HINTS written in the custom code need to be analyzed and decision need to be taken if those can be retained.

In case of conversion to S/4 HANA, SAP provided HINTs may not be available on new S/4 HANA release. Hence such HINT statements need to be either replaced with new HINT or removed.

4. Use of Native SQL

As per SAP’s recommendations Embedded Native SQL statements betweenEXEC SQLandENDEXEC should no longer be used in the ABAP development though they are supported by SAP. Instead ADBC interface or OPEN SQL to be used to fulfill the requirement.

But even though these SQL statements are not replaced with ADBC or OPEN SQL, functionality is not going to impact.

Refer the SAP Help Native SQL

Hence such issues can either be suppressed using pragma or need to be corrected.

5. Use of ADBC Interface

As motioned in point No 3. ADBC classes can still be used in the development. Hence these classes can be replaced with OPEN SQL or can be continued to be used as it is.

In below example Method EXECUTE of ADBC class CL_SQL_STATTEMENT is used to execute the native SQL.

*&---------------------------------------------------------------------**& Report Z_ADBC*&---------------------------------------------------------------------**&*&---------------------------------------------------------------------*REPORT z_adbc.CLASS demo DEFINITION. PUBLIC SECTION. CLASS-METHODS main. PRIVATE SECTION. CLASS-DATA: BEGIN OF result_line, carrid TYPE sflight-carrid, connid TYPE sflight-connid, fldate TYPE sflight-fldate, END OF result_line, result_tab LIKE TABLE OF result_line.ENDCLASS.CLASS demo IMPLEMENTATION. METHOD main. DATA carrid TYPE sflight-carrid. DATA cols TYPE adbc_column_tab. cols = VALUE #( ( CONV adbc_name( 'CARRID' ) ) ( CONV adbc_name( 'CONNID' ) ) ( CONV adbc_name( 'FLDATE' ) ) ). cl_demo_input=>request( CHANGING field = carrid ). TRY. DATA(result) = NEW cl_sql_statement( )->execute_query( `SELECT carrid, connid, fldate ` && `FROM sflight ` && `WHERE mandt = ` && `'` && sy-mandt && `' AND` && ` carrid = ` && cl_abap_dyn_prg=>quote( to_upper( carrid ) ) ). result->set_param_table( itab_ref = REF #( result_tab ) corresponding_fields = cols ). IF result->next_package( ) > 0. SORT result_tab BY carrid connid fldate. cl_demo_output=>display( result_tab ). ENDIF. CATCH cx_sql_exception INTO DATA(err). cl_demo_output=>display( err->get_text( ) ). ENDTRY. ENDMETHOD.ENDCLASS.START-OF-SELECTION. demo=>main( ).

Hence such issues can either be suppressed using pragma or need to be corrected.

6. SELECT SINGLE is possibly not unique

Here is a code which is running on non-HANA database and using SELECT SINGLE statement.

This code is supposed to SELECT the Document no 0000000005.

The output of the program is 0000000005.

Now let’s execute similar SEELCT SINGLE statement on HANA database.

Expected Output is 00000018.

However Actual output is 00000021.

As we discussed in the beginning of this blog, explicit Sorting of data is required on HANA database.

Since Explicit sorting is missing in code written on HANA database incorrect result was obtained.

How to correct this issue? Code needs to be adjusted as below.

After making these changes output is

The explicit SORTING by Primary key is required when ALL Key Fields are not passed to SELECT statement written on Transparent table and Views. If the output of such incorrect select statements are used for further processing like validation, calculation etc. the functionality will be impacted.

This might work in cases where SELECTs are written to validate the existence of at least one record in the table. But it is recommended to adjust all such issues before handing over code for functional testing.

Similarly, for all below ATC errors do the explicit sorting after SELECT statement, before READ statement, before DELETE adjacent, before LOOP..ENDLOOP.

7. READ .. BINARY SEARCH for result of statement

8. DELETE … FROM/TO for result of statement

9. DELETE … INDEX for result of SELECT statement.

10. LOOP AT itab. AT … ENDAT

11. LOOP AT itab. AT FIRST/LAST… ENDAT

12. LOOP AT itab. EXIT/RETURN/LEAVE

13. LOOP AT itab FROM/TO for result of statement

14. READ TABLE … INDEX for result of SELECT statement

15. READ TABLE … INDEX 1 for result of statement

16. READ TABLE … INDEX C_CONST for result of statement

17. SELECT … FOR (former) cluster table

18.SELECT … FOR (former) pool table

19. DELETE ADJACENT DUPLICATES for result of statement

Summary

We learned.

1. Custom code adaptation must be done with respect to HANA database in Suit on HANA Migration and S/4 HANA conversion projects.
2. Use FUNCTIONAL_DB and FUNCTIONAL_DB_ADDITION check variant in ATC to perform custom code analysis.
3. FUNCTIONAL_DB_ADDITION is not mandatory though since it covers performance related checks.
4. Explicit sorting of the data must be done for various statements we discussed in the blog.

In next blog I will try to cover some unique scenarios of custom code adaptation.