Skip to Content

If you are involved in a SAP HANA system conversion project and take care of the custom code (see also the blog SAP S/4HANA System Conversion – Custom code adaptation process) at a time you will reach the point, where you will need to do functional adaptation for your custom code on your brand new SAP S/4HANA system.

For this purpose, you will run ABAP Test Cockpit with the S4HANA_READINESS check variant on your SAP S/4HANA system and will get a long list of ATC findings which you need to fix.

No doubt, it as a substantial manual effort to look at every ATC finding and adjust your custom code. Besides this, often the most ATC findings are the SAP S/4HANA standard known issues, which could be fixed quickly without dipping into source code analysis, reading SAP Notes for adaptation guidance and so on.

Therefore, in order to minimize your adaptation efforts, we started to offer automatic code adaptations using the Quick Fixes (or Ctrl +1 shortcut) feature of ABAP Development Tools in Eclipse (ADT).

 

Prerequisites

Client: ABAP Development Tools (ADT) 2.96

Backend: ABAP platform 1809 (AS ABAP 7.53 SP00)

 

First Quick Fixes for SAP HANA related issues (SELECT without ORDER BY)

One of the typical functional adaptation use cases during SAP HANA migration is the missing ORDER BY clause in SELECTs before the READ statement. According to the SQL specification, you can not rely on the sort order in SELECT without ORDER BY. This can lead to unexpected behavior when the database is changed (for example to SAP HANA) because the results return in a different order without ORDER BY.

When you check your ABAP code containing such issues with ABAP Test Cockpit in ABAP Development Tools (ADT), you will most probably get a long list of ATC findings in your ATC Problems View at READ.. BINARY SEARCH statements, which were caused by the missing ORDER BY clauses in the previous SELECTs.

Now you can correct such issues automatically via ADT Quick Fixes.

Note: ATC findings that can be fixed with a Quick Fix are displayed with a lightbulb icon  

There are two possibilities for applying Quick Fixes.

You can select an ATC finding and choose Quick Fix (or Ctrl + 1 shortcut) in the context menu:

Then select the displayed Quick Fix in the popup and press Finish button:

Recommendation: If there is more than one Quick Fix available for an ATC finding, we recommend to select the first Quick Fix displayed.

Alternatively, you can jump to the affected source code line by double clicking the corresponding ATC finding and choose Quick Fix in the context menu (or Ctrl + 1 shortcut). Double-click the Quick Fix in the popup to apply it to the affected source code line.

That’s it. You can save and activate your source code and rerun ATC.

What’s next

Currently we plan to deliver further Quick Fixes for the most prominent SAP S/4HANA simplification use cases which are suitable for automatic adaptations such as e.g. changes in KONV, MATNR, VBUK, VBTYP, BSEG.

Beyond this the mass-enabled Quick Fixes will follow, which will make it possible to adapt full packages or software components in one shot and in this way drastically reduce your custom code adaptation efforts.

Stay tuned!

To report this post you need to login first.

7 Comments

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

  1. Matthew Billingham

    “Relying on the implicit sort order of the database vendor leads to functional incorrectness when you switch the database e.g. to SAP HANA.”

    This is not a HANA specific behaviour.

    As I’ve often had to point out on questions on the ABAP tag “my data isn’t being returned in the correct ord”, while observed behaviour might initially mislead you, there is no implicit sort order on relational databases. The order in which you get records back is simply undefined – whether you’re using Oracle, HANA or whatever.

     

    (0) 
    1. Olga Dolinskaja Post author

      Hi Matthew,

      it is indeed so, that many implementations of SELECTs without ORDER BY relied on the presumable “sort order” in the underlying database. It was the motive of using SELECTs without an explicit sorting clause. The applications were programmed using the “expected” order in the result set returned by such SELECTs, and switching the DB vendor (SAP HANA is only the example) caused functional incorrectness.

      I agree with you, that actually DB vendors don’t sort data in tables, they rather implement the way, how the data is fetched by SELECTs on their DBMS, and it can vary from DB vendor to DB vendor.

      I changed the text in the blog so it will become more clear.

      Regards,

      Olga.

      (1) 
  2. Matthew Billingham

    I would like to suggest an improvement for this quick fix. You see, about 20 years ago, HASHED and SORTED tables were introduced into the ABAP language. Since then, BINARY SEARCH is rarely (if ever) required. Sadly, many programmers are firmly stuck in the last millenium and don’t use these “new” constructs.

    It would be nice if your quick fix, or the ATC finding, pointed out that better results might be obtained by simply defining the table as HASHED or SORTED. Of course, you are fixing a programmatic issue in a quick way, but the danger is that you’re applying a bandaid to a gaping wound…

     

    (0) 
    1. Thomas Fiedler

      Hi Matthew,

      thanks for the Feedback.

      You can be sure that the Quick fix described in the blog is only the start of our roadmap. Besides the fixes for functional correctness after S/4HANA conversion we also have Quick fixes for security, performance and other code quality aspects in mind. And we also keep an eye on the modern ABAP and how we can get rid of the old ABAP stuff by using Quick fixes.

      I’m sure this blog will help to collect proposals from you ABAPers.

       

      Regards,

      Thomas.

      (1) 
  3. Renaud VAN DEN DAELE

    Hi colleagues,

    I understand from the prerequisites the quick fixes can only be used once the conversion occured (ie backend is  SAP S/4HANA 1809)  although, if I am not wrong, these are the fixes which could be done on ERP as a pre-project activity.

    If I am right on both statement above, do you foresee a possibility to have those nice tools available  with ERP as a backend so that code can be corrected before the SAP S/4HANA project starts?

    Best regards

    Renaud

    (1) 
  4. Deepti Dhingra

    Hi Olga,

    It’s a helpful feature for developers, hope to see such features, not only for conversion but for regular development of codes and looking forward to see more features in it.

    Regards,

    Deepti

    (0) 

Leave a Reply