Skip to Content
Author's profile photo Former Member

Suite on HANA implementation overview – Part 2

I’ve participated in the internal implementation of ERP on HANA for SAP IT, as well as done architecture assessments, and discussion with customers on the journey to Suite on HANA. I haven’t seen a lot of details externally on the implementation, and figured I’d go through the steps in my mind, and see how they look. This is not an SAP approved communication, these are instead the ramblings of someone expressing their experience through the process.

Suite on HANA implementation overview – Part 1

Custom Code Remediation –

We need to do an assessment of the customers custom code to determine how much of it needs to be changed during the migration process. There are two main groupings we can consider the issues as

Functional Correctness – Issues where the custom code will not provide the same output as it would have from the current database. The output from HANA would be different due to architectural differences between the database, and technical changes to some of the table types that result in different assumptions made about the code.

Accelerating the Custom Code – This is where we address actually utilizing the HANA database, and rewriting certain custom code to benefit from the speed HANA enables. Previously developers would avoid the database because it was slow, and instead process on the application server. Now that we no longer have a slow database, we can actually do processing against it and benefit from the speed.

I will start by focusing on Critical Statements that involve Functional Correctness. In another post I will cover accelerating the Custom Code.

Critical Statements –

  • Native SQL

Native SQL is where you want to make use of specific features of the underlying DB. Native SQL bypasses the synchronization of the SAP table buffers, and can cause data inconsistencies when moving it to a different database

Example – EXEC SQL ….. END EXEC

TODO – Native SQL must be rewritten as OPEN SQL in ABAP. This can be done before the migration to SAP HANA.


A database hint is an indication to a particular database that it should perform in a particular way, like a customization. Considering these DB Hints are database specific, they are unnecessary and non-functional when moving to HANA.

Example – %_HINTS …

TODO – DB Hints can be commented out, and the SQL will perform as normal without the DB Hint.

  • DB Operation on table clusters and table pools

Table clusters and Table pools are no longer used with HANA, and depooling/declustering occurs. The logical table is converted to a transparent table. This will cause hard errors if not corrected.


TODO – DB operations have to be avoided on these physical tables. Code needs to be refactored avoiding these DB operations. The correction can be done prior to the HANA migration.

  • Sort/Order by Statements

Statements that use the results of SELECT or OPEN CURSOR without an explicit ORDER BY clause or a SORT are potentially problematic. They could depend on the order of the entries in an internal table, and that order is no longer dependable within HANA.

ExampleREAD … BINARY SEARCH (Binary Search is used, but the internal table may not be sorted)

DELETE ADJACENT DUPLICATES …. (Internal table that this statement uses will not be sorted)

TODO – Add an order by clause to the select statement, or Add a sort statement for the internal table. You can do this before the migration to SAP HANA

  • Depooling/Declustering

Statements that contain SELECT and OPEN CURSOR statements for pool or cluster tables without an ORDER BY clause need to be analyzed. After the migration to SAP HANA, the majority of POOL and CLUSTER tables will be converted to TRANSPARENT tables and the result set will no longer be sorted by the primary key.


Before the move to HANA, the result set would have come sorted by the primary key. After the move to HANA, BSEG becomes a TRANSPARENT table and the result set will not be sorted by the primary key.

TODO – Add an ORDER BY with primary key fields, or Add a SORT statement for the internal table. This correction can be done before the SAP HANA migration.

— In the next part I’ll dive into accelerating custom code, and give some examples to improve the performance of custom code with HANA.



Assigned Tags

      1 Comment
      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member

      Can someone please explain how the ABAP code remediated for HANA can be tested before the actual migration ?

      I know there are tools available, to speed up the ABAP code customization for HANA, like SCI, ABAP Test Cockpit, SQL Monitoring tool, Run-time check tool etc.

      So, my questions are:


      1. Is there any way to automate the ABAP code customization for HANA ? Does SAP provide any tool for automation ?

      2. How the ABAP code remediated for HANA can be tested before the actual migration ?