Brief Overview:
We all are aware of the code pushdown paradigm shift in SAP HANA. What happens to the old custom code that was developed for the old/classical architecture? This article tries to answer this by answering a few set of questions.
Why HANA Ready?
When you are migrating to SAP HANA, all the ABAP Custom code is to be made in line to HANA so that the code runs in an efficient manner.
But, why adjust the custom code? Is it not true that all coding should be backward compatible?
As discussed many times in earlier articles/blogs SAP HANA Database is not just a database but a hardware and software that achieves faster data access, in other words, it’s an “Appliance“. Now the legacy/old way of ABAP programming guidelines no longer hold good.
Yes, all the custom code is backward compatible but it does not necessarily utilize the capabilities of HANA.
Also, note that SAP HANA complies with SQL-92 standards and RDMS Principles. There are few statements in ABAP which were suited to the earlier architecture of classical DB. In the classical DB/legacy way of ABAP Programming where the heavy data operations were performed at the application layer due to the inherent limitation of classical DB.
Now thing are totally different/opposite for SAP HANA i.e. all the data-heavy operations are pushed down to the database layer
How to identify what code can be HANA Optimized?
Yes good OLD ATC check, not kidding.
According to SAP, ABAP Test Cockpit (ATC) is a Holistic Tool for Quality Assurance of ABAP code.
- It is the single point of entry for all static code check tools (like Code Inspector..)
- Verdicts are reported with priorities
- It supports quality management processes
- Available from ABAP 7.02 SP12 and above
- It is fully integrated with development environment and transport tools
In other words, ATC is a framework for running static checks on ABAP objects to find: functional, usability, performance, security .. bugs. ATC is based on Code Inspector and adds new quality gates, quality processes, and better usability
Go the ABAP Object select the ATC Check with the variant namely FUNCTIONAL_DB and PERFORMANCE_DB to name a few. The output of the ATC check will give you the line no and what is to be modified.
Apart from these variants, we can also have new variants where the rules/violations can be picked or chosen as per the need.
Heard a lot about HANA-tization. What does it actually mean?
HANA-tization is the word used typically by IBM. It proposes the steps/processes that are to be put in place of the old(non-HANA) code to make it compatible to HANA.
Typically there are three parts:
1) BASIS
2) Functional
3) Technical. (We would share more in subsequent articles).
HANA-tization is the first step after migration to HANA database. It ensures the custom codes run properly on new HANA database adopting the paradigm shift in underlying architecture from the traditional relational database to in-memory database. This is considered the mandatory phase for any ABAP custom developments for any Suite on HANA migration project.
Technically speaking, it includes checks and actions to be taken, post HANA migration. Please note it is after HANA migration in Custom developments (as for standard codes, SAP has taken care themselves) to ensure the custom developments run without any disruption and hence confirm Functional correctness of Customer Business.
Pre-requisite for HANA-tization:
Typical Flow chart of a HANA-tization Project:
This is one of the most sought after questions: What is the Role of an ABAP Technical Consultant in any HANA migration project?
- The foremost job of the ABAP practitioner is to collect the inventory of custom objects for HANA-tization
- Identification of development objects targeted for modification
- Technical transformation of custom developments
- Verification through the HANA-tization checklist
- Technical specification update
- Analysis and resolution of reported Test-defects
What do we do to technically transform the custom developments?
9 Golden Steps (mentioned below) steps are identified which is mapped with checks in t-code SCII. We would describe them in more details in our next articles.
1. Search for problematic SELECT * statements
2. Search SELECT with the DELETE statement. SELECT statements with subsequent CHECK
3. Table Buffer Bypassing: Search ABAP statement patterns via SELECT * BYPASSING BUFFER*
4. Native SQL – During DB migration the Native SQL constructs have to be adjusted or removed.
Recommended approach is to replace the Native SQL with Open SQL. If that is not possible ie required actions cannot be achieved through Open SQL, adopt the Native SQL so that it works on HANA.
Use of ADBC interface/CL_SQL_STATEMENT 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.
5. DB-Hints: Search ABAP statement patterns and CALL FUNCTION ‘DB_EXISTS_INDEX‘
6. De-pooling/De-clustering: Search SELECT for Pool/Cluster Tables without ORDER BY clause
All cluster and some pooled tables are converted to transparent tables in HANA. Hence queries on Cluster/pooled tables returns results sorted by primary keys is no more true here. Any custom coding which accesses physical table cluster/pool has to be changed so that the program reads from tables directly.
7. DELETE ADJACENT DUPLICATES FROM internal_table COMPARING field1 field2 .. fieldn.
8. READ TABLE internal_table .. BINARY SEARCH.
9. Explicit Transparent tables SORTing
Please note: ABAP based Adobe Form Interface, ABAP Webdynpro and code inside Smartforms cannot be checked using SCI. These are pure manual activities to be performed by the ABAPers.
What is HANA Plus?
Like HANAtization is the term coined by IBM, similarly, HANA+ is a Cognizant Tool. It is Cognizant proprietary tools for effort estimations during HANA database migration/upgrade and automation of code review process. In short, it is HANA Code optimization Tool sets.
