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 and FUNCTIONAL_DB_ADDITION.

Please check the SAP note: http://service.sap.com/sap/support/notes/1935918 in case the variant does not exist in your system.

 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: http://scn.sap.com/docs/DOC-47444

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 additonal 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 use the Usage Procedure Logging (UPL) in order 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 good overview about the UPL can be found here: http://scn.sap.com/docs/DOC-54826

 

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 prepartion steps in your old landscape in order to be succuessful 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.

 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

To report this post you need to login first.

28 Comments

You must be Logged on to comment or reply to a post.

  1. Florian Henninger

    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 😉

    ~Florian

    (1) 
      1. Florian Henninger

        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

        (0) 
  2. 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 😆

    BR

    Daniel

    (0) 
  3. 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

    (0) 
  4. Edo von Glan

    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

    (0) 
    1. Thomas Fiedler Post author

      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.

      (0) 
      1. Edo von Glan

        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

        (0) 
  5. Felix Klingel

    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

    (0) 
    1. 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

      (0) 
  6. Edo von Glan

    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.

    (0) 
    1. Thomas Fiedler Post author

      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.

      (0) 
  7. Ashutosh Tripathi

    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

    (0) 
    1. Joachim Rees

      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

      (1) 
  8. Sarves Peddibhotla

    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

    (0) 
    1. Mathias Klein

      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.

      (0) 
  9. Sebastian 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

    (0) 
  10. Sandeep Rawat

    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

    (1) 
  11. Pawan Akella

    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

    (0) 
    1. Thomas Fiedler Post author

      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-page-1

      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.

       

      (0) 

Leave a Reply