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.
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.
- DB HINTS
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.
Example – SELECT / DELETE on RFBLG
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.
Example – READ … 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
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.
Example – SELECT on KONV, SELECT on BSEG
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.