ABAP custom code adaptation for SAP HANA – The efficient way

[ThFiedler]

Introduction

Currently many SAP customers plan and evaluate the migration from their classic ERP system running on any DB to Business Suite on SAP HANA or S/4HANA. For both scenarios custom ABAP code needs to be adapted for SAP HANA. This paper shares best practices in order to minimize the adaptation effort. The recommended procedure has already been applied successfully in many different SAP Hana migration projects.

 

Basic facts about the adaptation of ABAP code for SAP HANA

 In general all ABAP code runs on SAP HANA as on any other supported database. Some SQLs are faster on HANA , e.g. when selecting columns without an index. Only ABAP code which relies on specific features or capabilities of the predecessor database must be analyzed and corrected. There are three main aspects for custom ABAP code adaptation for SAP HANA:

Mandatory corrections of your code to avoid functional regression

Target: ABAP code, SQL code or database calls which build on specific features of the predecessor database (e.g. native SQL, ABAP code relying on certain sort order of a SQL result set)

Recommended SQL performance optimizations in order to avoid performance degradations

Target: “Bad” SQLs in custom code playing a dominant role in the runtime profile of productive business processes. Special focus is on SQLs which are executed very frequently (e.g. SELECT in loop).

Exploit SAP HANA Code pushdown techniques by using Core Data Services and SQL script procedures to speed up custom code processes significantly.

This papers focuses on the first two aspects which are part of the SAP HANA migration. The third step normally happens after the migration and is addressed in custom development projects driven by business requirements.

 

Recommended tools

For functional corrections the ABAP platform provides static code check tools like Code Inspector and the ABAP Test Cockpit. In addition, ABAP developers and test engineers can build unit tests and scenario tests in order to ensure functional correctness. For the SAP HANA migration SAP provides new static checks integrated in the code inspector. These checks are bundled in the code inspector variant FUNCTIONAL_DB.

Update: Recommendation is to use a central ATC for all kind of static code checks. See the blog post to read more about it: https://blogs.sap.com/2016/12/12/remote-code-analysis-in-atc-one-central-check-system-for-multiple-s...

Please check the SAP note: http://service.sap.com/sap/support/notes/1935918 in case the variant does not exist in your system. In case you want to check systems of releases older than 7.02 you have to use the remote ATC.

For the S/4HANA conversion projects the recommendation is to use the Custom Code Migration app for the analysis of custom code. The App can also be used for HANA projects. Find more info about it: https://blogs.sap.com/2019/02/27/custom-code-analysis-for-sap-s4hana-with-sap-fiori-app-custom-code-...

In addition to the static checks SAP also provides a new runtime check monitor, transaction SRTCM.

Please check the SAP Note: http://service.sap.com/sap/support/notes/1931870 for more information.

 For performance optimizations the ABAP platform provides runtime tools for tracing and monitoring the performance of the business processes. The main tools are Runtime Analysis, SQL Trace and the workload monitor for runtime monitoring. With NetWeaver 7.40, the new SQL monitor was introduced to analyze SQL statements in your productive system. The SQL Monitor is the recommended tool for optimizing SQLs in custom code during the migration to SAP HANA. The tool runs in the productive system and monitors the business processes without harming your system performance as the overhead of the tool is neglectable (<3%).

A very good introduction of the SQL monitor can be found here: https://www.sap.com/documents/2013/10/92b57ae6-527c-0010-82c7-eda71af511fa.html

Please check the SAP Note http://service.sap.com/sap/support/notes/1885926 to find information how you can get the SQL monitor in lower releases.

Additionally, the developer can use static checks integrated in the code inspector to find and avoid performance bugs in the code. For the SAP HANA migration, some additional static performance checks are available to find performance hints. The static checks are bundled in the code inspector variant PERFORMANCE_DB. But please be aware that these checks should only be used as additional hints when fixing the issues detected by the SQL monitor analysis. Do never fix the static findings without looking in the SQL monitor before.

For condensing the custom code work package during the SAP HANA migration it is recommended to focus the functional corrections on the productively used code. Cleaning up of non-productively used code before the migration is therefore strongly recommended. A very good overview about the usage analysis can be found here: https://blogs.sap.com/2017/04/06/abap-call-monitor-scmon-analyze-usage-of-your-code/

 

Recommended step by step process for the custom code adaptation

Project planning phase

Before you start the journey towards SAP HANA you should first reflect the current situation of your custom code in your landscape to get an impression about the efforts needed for the migration. Topics like custom code retirement, custom code quality optimization, custom code process optimization and the custom code impact analysis are helpful offerings to refine the custom code strategy in your company. SAP is offering various services to help customers here. You can find more information about these options in the ABAP Testing and Analysis community.
  

Preparation phase before the migration (old system landscape)

Before you start with the migration of the database you have to do some preparation steps in your old landscape in order to be successful with the project. The following steps are recommended:


 Limit work package (optional)

A very important step in such a migration project is to do some housekeeping before the project starts. Get an overview about your custom code and analyze which code is really necessary for your business. Ideally eliminate code that is not used anymore before the migration starts. Use the Usage Procedure Log (UPL) to create a custom code directory containing only the productively used code.

Custom Code Analysis (optional)

You can use a central ABAP Test Cockpit system already before the migration to analyse your custom code and estimate the adaptation efforts.

Custom Code Adaptation (optional)

You can already fix most of the ATC findings (e.g. all ORDER_BY issues) before the migration to HANA.

Performance optimizations

Switch on SQL Monitor in the old productive system for ~ 2 weeks to monitor the performance of your productive business processes. Sort the SQL Monitor results in transaction SQLM by “number of execution” and optimize the 10-20 Top most executed SQLs in your custom code which affect relevant business processes (e.g. SELECT in Loop can be transformed in FOR ALL ENTRIES).

 

During the migration (new system landscape)

Correct functional issues via static checks

In the upgraded development system, run the code inspector with the static checks from the variant FUNCTIONAL_DB for your custom code. Findings of all priorities are relevant for the  analysis.

Correct functional issues via runtime checks

Switch on the runtime check monitor SRTCM in the upgraded test system in order to monitor the tests of your business processes. Correct the additional findings found by runtime check.

After these corrections are done you should now start your standard tests for functional corrections via standard unit tests and scenario tests.

Performance optimizations

Switch on SQL Monitor in the upgraded test system in order to monitor the tests of your business processes.

Sort the SQL Monitor results by “execution time” and optimize the first Top 10 SQLs in in your custom code which affect relevant business processes.

 

After the migration (productive system is live on SAP HANA)

Functional corrections – runtime checks

Switch on the runtime check monitor again in the new productive system and correct the additional findings found by the runtime check.

Performance optimizations

Switch on SQL Monitor in the productive system. Sort the SQL Monitor results by “execution time” and optimize the 10-20 Top SQLs in your custom code which affect relevant business processes. After performance optimizations reached the productive system, this process needs to be repeated 2-3 times in order to achieve the best results.

Optimize your code for SAP HANA

After the successful migration you can now start to think about optimizing your business processes by using code push down techniques of SAP HANA like the Core Data Servcies (CDS) and ABAP managed database procedures (AMDP) implemented with the native HANA language SQL script.

Find more information about these capabilities in the ABAP for SAP HANA document: ABAP for SAP HANA Reference Scenario.

Good starting point for CDS is: Getting Started with ABAP Core Data Services and for AMDP go for: ABAP Managed Database Procedures - Introduction

[Florian]

Hi Thomas,

nice summary and really important recommandations!

Especially do the housekeeping !!!before!!! the migration begins.

I just would add, that it's also important when you move to S/4 HANA don't forget to invest time for the output management. There are some major changes which also need some decisions from the management and which can be also done before starting the journey :wink:

~Florian

[daniel_rothmund]

Hi Thomas ,

Nice blog and a great summary of the Point which you must take care when you do a HANA or S/4 HANA Migration.

We have done our Migration to S/4 HANA exactly whith these Points.

But unfortunately a year a ago we had not such a great summary blog :lol:

BR

Daniel

[ThFiedler]

Hi Florian,

concerning Output Management I found the following Note:

http://service.sap.com/sap/support/notes/2228611

Does this help for the management decisions, what do you think?

Regards,

Thomas.

[Florian]

Hi Thomas,

this helps a lot, additional to that I have finished a long time planned blog about it and just need to add some pictures to visualize the technical concept behind.

Your headerlines filled a gap how to present it and so I'm happy to also include a OSS note next to the whitelist.

Thank you for the research:-)

~Florian

[Peter_Inotai]

>But unfortunately a year a ago we had not such a great summary blog

But we had this cool openSAP course, which covered nicely these topics:

ABAP Development for SAP HANA - Dr. Jasmin Gruschke and Jens Weiler

Peter

[peter_casper]

Good summary. It would have saved me some exploration time having had this before I performed the HANA upgrade in 2014. 😉

However it is still a good online reference for any later migration.

Cheers, Peter

[vonglan]

Hi Thomas,

A question regarding the mandatory corrections to avoid functional regression:

You mention the code inspector variant FUNCTIONAL_DB, as a tool to avoid functional regression when switching to HANA. As an example, this check variant includes the check Robust Programming / Search problematic statements for result of SELECT/OPEN CURSOR without ORDER BY.

The description of the check says that findings can be suppressed with the pseudo comment CI_NOORDER.

Will using this pseudo comment lead to serious but hidden problems when migrating to HANA?

Best regards,

Edo

[ThFiedler]

Hi Edo,

you should use this pragma only when you exactly know that this finding is a false-postive.

Was this your question?

Regards,

Thomas.

[vonglan]

Hi Thomas,

maybe I have seen too many pragmas and pseudo-comments being used out of a kind of lazyness.

Can you confirm the following two statements?

1. In the case of a "true" false positive with checks from FUNCTIONAL_DB, that it is suppressed with a pseudo comment, there won't be any problems with HANA (regarding this piece of code)
2. All FUNCTIONAL_DB-related pseudo-comments and pragmas (for example CI_NOORDER) should be double-checked at the beginning of a HANA migration project.

Best regards,

Edo

[felixklingel]

Hello Thomas,

we have plenty of z-programs which make use of logical databases (e.g. SDF, DDF, etc.). Are logical databases still supported under S/4HANA? In the current ERP they are obsolete but still working. It will be a huge effort to rework all these programs.

Thanks!

Best regards,

Felix

[peter_casper]

Hi Felix,

I strongly assume that logical databases still work with a HANA DB. Logical databases are part of ABAP programming language and designed to make the coding independent from any technical layer, e.g. the DB itself.

However I would take a deeper look at the test results.

In case you want to be 100% sure prior to any upgrade, I would simply open an OSS message with exactly that question.

regards Peter

[felixklingel]

Hi Peter,

Many thanks for your valuable input! I'll do it in that way.

Best regards,

Felix

[vonglan]

Hi Thomas,

Is there a possibility to mark false positives in SRTCM findings, so they can be filtered? Something like a pragma?

Best regards,

Edo

PS: don't know if this is the best place to ask this question - please point me somewhere else if useful.

[ThFiedler]

Hi Edo,

sorry, there is nothing similar planned in SRTCM.

Why do you want to mark a finding as false positive? The check results are defintely related to bugs in your code. Why can't you fix them?    

Regards,

Thomas.

[Ashutosht09]

Hi Thomas,

Great blog, thanks for writing this.

One question. If we are just doing database swap from traditional database to SAP HANA to get the ECC environment running on HANA as the first step towards moving to S/4, is this adaptation of the code necessary?

My understanding was since the application layer remains unchanged there should be no impact.

The system is on EHP7 and I understand that is the right version to migrate to HANA database.

Looking forward to your response.

Regards,

Ashutosh

[joachimrees1]

Hi Ashutosh,

I think, Thomas' introduction allready answers your question:

to Business Suite on SAP HANA or S/4HANA. For both scenarios custom ABAP code needs to be adapted for SAP HANA.

best

Joachim

[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 accelerate the ABAP code customization for HANA, like SCI, ABAP Test Cockpit, SQL Monitoring tool, Run-time check tool etc.

But my questions are:

1. Is there any way to automate the ABAP code customization for HANA ? Does SAP provide any tool for automation ? Or is this something that can be done in-house only ?

2. How the ABAP code remediated for HANA can be tested before the actual migration ? Sandbox testing with HANA DB is the only way ? But how do we test if HANA DB is not already installed ?

3. How do we ensure that the entire data from the original database is copied to the HANA db ? How do we test the data loss (if any) ? Would the testing of all use case scenarios suffice to test the data loss ?

Thanks

Sarves

[andreas_spix2]

Hi,

please read my question regarding ORDER BY.

http://scn.sap.com/thread/3934327,

Regarding for your answers. Thx.

Andi

[KleinM]

Let me answer your question 3:

The Software Update Manager (SUM) performs a row-count at the end of the DB migration. So we compare the row-count from the tables in source DB with the row-count of the tables in the HANA DB. SUM will throw an error message if there is a difference in the row-count and names the table with the wrong row-count.

Furthermore SUM can also create CRC checksums on the table content (all tables or only on selected tables). With that you can even check that the content of the tables is still the same. But please keep in mind that this is a quite time consuming process. As a rule of thumb: it takes almost the same time like the migration of the table itself. So I would only use it if really required.

[ThFiedler]

Hi Andi,

focus on Prio 1 + 2 findings. Most likely these are issues needs to be fixed.

Regards,

Thomas.

[Former Member]

Small correction: I believe transaction should be SRTCM instead of SRCTM.

[ThFiedler]

Thanks

[se_ostermann]

Hi,

is it possible to implement code inspector variants FUNCTIONAL_DB and FUNCTIONAL_DB_ADDITION (see note 1912445) in a BW system running 7.31 SP08?
I tried to implement the downport note 1935918, but unfortunately I get the message that the "note does not contain valid correction instructions".

Thx in advance
Sebastian

[Former Member]

How can I find all the custom code in my SAP system before starting the migration.
Do we have any tool/report for the same?
How do we know the complexity for those custom code conversion.


Thanks
Sam

[srinivasb8583]

Hi Thomas - Thank for your very informative Blog. Appreciate you taking time in detailing out every topic.

Thanks

Srinivas

[MPS4HANA]

You can use Custom-Code Analyzer.

[former_member191728]

Hi Thomas,

I am little bit confused about the time of usage.

In the blog it was mentioned as

"In the upgraded development system, run the code inspector with the static checks from the variant FUNCTIONAL_DB for your custom code"

I am assuming we can use ATC or SCI tools with custom variants before actual migrating to HANA database i.e we can use it on our current non-HANA Database?

What will be best option to fix the Performance and Functional issues .

Is it on our current Non HANA database or after migrating to HANA database?

Thanks

Kumar

[ThFiedler]

Hi Kumar,

you can adapt your code concerning functional correctness also in your old system on anyDB. We recommend to use the remote ATC infrastructure for that which is new with AS ABAP 7.51. Please find more details in that blog : https://blogs.sap.com/2016/04/22/abap-custom-code-adaption-for-sap-hana-the-efficient-way/comment-pa...

Concerning performance optimizations we recommend to look on very often executed SQL already in your old productive landscape by monitoring the SQLM Monitor. For example single selects in LOOP statements need to be optimized even without HANA as this is "bad" coding. After migrating to HANA you can focus than on long running SQLs and look if you can optimize this coding via new database capabilities in the new ABAP stack CDS, AMDP or by just optimizing your SQL via new SQL features in the ABAP language.

Does this help?

Regards,

Thomas.

 

[Former Member]

Hi Thomas, with respect to the ATC checks do you have to specify a target release (e.g. S/4HANA or Suite on HANA) when executing the checks, or do functional correctness checks apply across the board regardless of target release?

[ThFiedler]

Hi Bret,

the functional correctness checks concerning HANA are the same for every ABAP (S/4 or SoH) Release.

 

Regards,

Thomas.

 

 

[former_member259859]

I start migration to hana (7.51) and perform a hana_readiness check in ATC, but I have false positive error in some function .

Than a create a z function e put the adapted code example in sap note 2215852 and perform a atc check in this code, a think that not errors is reported because is the sap example of adaption code for material number, but my surprise is that the code is showed like error.

I believe that my version of sap hana_readiness is wrong, beside I get the last version.

Any guy pass for the same issues, there are any sap note or sp that resolve this false positive ?

thanks

[cordialsarthak]

Hi thomasfiedler , in the performance optimisation section of phase “Preparation phase before the migration” you have mentioned an example to transform ‘SELECT in Loop’ to ‘FOR ALL ENTRIES’.

But in SAP course HA400 (ABAP Programming for SAP HANA), they recommend to replace ‘SELECT statements with FOR ALL ENTRIES’ with ‘SELECT statement with a join’. SAP also mentions that performance of existing ABAP code will change after HANA DB migration:

1. Some code immediately runs faster


2. Some code might be negatively impacted and should be revisited

 

Then what is the point of doing performance optimisation BEFORE the migration and increasing total effort?

[ThFiedler]

Hi Gupta,

the benefit is that you can analyse the SQLs monitored by SQLM in your productive system before the conversion. So this is more a general recommendation to regularly monitor this independent of move to HANA. The experience shows that most of the findings can be fixed already before the move to HANA.

Regards,

Thomas.