For years, companies have invested in adapting their SAP systems (modifications, extensions), adjusted them to their specific business processes and developed custom ABAP applications. Therefore, when converting from an SAP ERP system running on any database to SAP S/4HANA, in order to keep the solutions implemented so far, one of the necessary steps is migration of ABAP extentions to S/4HANA environment.
 

SAP S/4HANA is a comprehensive, next-generation modular ERP software, completely separate from the classic SAP Business Suite (SAP ECC) solutions. Therefore, the term “system conversion" rather than “upgrade" is often used to describe the migration from SAP ERP, running on any database, to S/4HANA. These terms are not unfounded. In this case, the migration is carried out from one SAP product (Business Suite, ECC) to a completely new product (S/4HANA) built using a new architecture and data model, and incorporating modernized applications and new user interface technology (SAP Fiori).

ABAP extensions vs. S/4

When implementing the custom ABAP code in classic SAP ECC, the developer can look into the SAP code, modify or improve it according to specific business requirements, and can use any SAP function module with virtually no restrictions. On the one hand, this is an extremely flexible approach, allowing them to work with the ABAP code in an open source way. On the other hand, however, it creates many dependencies between the customer’s custom code and the original SAP code.

Until now, this has not been a big problem during upgrades due to the compatibility of all new versions of SAP Business Suite and EHP with previous versions. However, with SAP S/4HANA, the situation has changed. A large part of the standard SAP code in SAP S/4HANA has been simplified and in some cases changed in an incompatible manner (e.g. deletion of some fields from database tables or even deletion of entire database tables). This does not mean, of course, that the SAP S/4HANA system has been completely changed. Still a large amount of custom code may work without changes, or with only a few fixes. In addition, as part of the simplifications made, SAP has provided alternative objects (e.g., CDS compliance views when changing the data model) so that the custom code can be adapted in the way transparent to the user.

However, one should be aware that in SAP S/4HANA some of the custom ABAP objects will no longer work properly or as expected, or will cause syntax errors, short dumps, etc. Most likely, some part of the custom ABAP code will have to be adapted.

Adaptation of the custom ABAP code is a very important step on the path of transformation to the SAP S/4HANA system. It can be divided into two main phases:

  • Before conversion of the SAP S/4HANA system – in the preparation phase – it is recommended to get rid of the old, unused custom code, and then analyze the custom ABAP code using the ABAP Test Cockpit (ATC) platform and check which objects need to be adjusted to get the code that is correct from the point of view of SAP HANA and SAP S/4HANA (SAP S/4HANA checks).
  • Before conversion of the SAP S/4HANA system – in the execution phase – the custom ABAP code must be adapted to the new SAP S4/HANA software (functional adaptation), and then the application performance can be optimized using the capabilities of the SAP HANA database (performance tuning).
Migration to S4 SAP development

Stages of adapting the custom ABAP code in the process of migration to SAP S/4HANA

Some of the work can be prepared and done beforehand, in the existing landscape of SAP Business Suite systems. Using standard tools (SCMON and UPL transaction), data on the productively used custom ABAP code can be collected in order to detect and clean the system of any unused custom code before the actual conversion to SAP S/4HANA.

In addition, in order to minimize the scope of adjustments in the S/4 conversion project, it is a good idea to introduce new “S/4HANA ready" solutions beforehand and oblige developers to ensure that the resulting code complies with the requirements of the SAP HANA database as much as possible.

We present recommendations that should be implemented now in the SAP ECC Business Suite environment to prepare the custom ABAP code for a safe journey to SAP S/4HANA.

  • It is a good idea to collect data on productively used custom solutions and SQL queries using SCMON (ABAP Call Monitor) or UPL (Usage Procedure Logging in SAP Solution Manager), and enable SQL Monitor (SQLM transaction).
  • When creating a new S/4HANA ready code, it is recommended to use ATC or SCI (SAP Code Inspector) with the FUNCTIONAL_DB / FUNCTIONAL_DB_ADDITION variants (note 1935918 for SCI).

Checking SAP HANA and SAP S/4HANA

Checking SAP HANA and SAP S/4HANA are the two most important steps in preparing the custom ABAP code during the conversion to S/4. In this phase, the ABAP code is checked for changes related to the migration to the SAP HANA database and changes related to the new system.

SAP S/4HANA is directly linked to the SAP HANA database. The ABAP code runs on the SAP HANA database just as it does on any other supported database. So what needs to be adapted to the SAP HANA database and why? One of the reasons is the ability to use the native SQL elements associated with the previous database. Such specific references and dependencies must be eliminated when migrating to a new database environment.

Another reason, perhaps the most common one, is the use of SELECT syntax without the ORDER BY element in the custom ABAP code. Calling queries in this way can lead to unexpected results when the database is changed. This is because the results may be returned in a different order when ORDER BY is omitted. Until now, developers have been accustomed to having query results returned in the default order according to the primary key in the database table. With SAP HANA, its architecture and query optimization mechanism, the order of query results is different. Therefore, it is necessary to verify whether SQL SELECT statements without the ORDER BY element are still correct.

Another reason for adaptations is that Pool/Cluster tables have been removed in SAP HANA. Therefore, the database operations on these tables should also be removed from the custom ABAP code.

To prepare the custom ABAP code for the actual conversion to SAP S/4HANA, you should compare your code with the so-called Simplifications Database.

The key SAP S/4HANA checks:

  • Field Extension – checks for length conflict for fields with a material number;
  • Search DB operations – searches for write operations on specific database tables;
  • Search for usages of simplified objects – finds uses of objects from the Simplification Database;
  • Search for ABAP Dictionary enhancements – checks extensions in the data dictionary (e.g. Appends);
  • Search for a base table of ABAP Dictionary views – searches for the use of database tables in views;
  • Search for S/4HANA related syntax errors – tries to find syntax errors in relation to objects on the simplifications list.

The preferred tool for checking the code for compliance with SAP S/4HANA and SAP HANA is ATC – ABAP Test Cockpit, with the option of remote code analysis.  All you need to do is configure one central ATC system for all static checks of the custom ABAP code across the entire system landscape. The code is checked for compliance with SAP S/4HANA and SAP HANA by performing a code check using the S4HANA_READINESS variant. In ATC, the total possible scope of checks includes the custom code in extensions, modifications, exits, SmartForms and Adobe Forms, excluding SAP includes and generated code.

As a result of ATC operation with the given variant, you get a list of incompatibilities of individual custom ABAP objects per code line. In the case of incompatibilities related to SAP S/4HANA simplifications, the result shows a reference to the corresponding SAP note describing the incompatibility of a given element with SAP S/4HANA, and a reason for a specific change. Often, the note also contains information on how SAP approached the adaptation of the standard code in a given case, and thus what options the developer has to adapt their code. Many notes also contain direct suggestions for solving the problems of the current ABAP code incompatibility with the target SAP S/4HANA system.

The output of ATC operation is a list of necessary adaptations. SAP assigns objects to the priorities 1, 2, 3, which mean:

  • Prio 1 – a short dump, a syntax error, an error during migration;
  • Prio 2 – a problem that cannot be strictly linked to the category of error;
  • Prio 3 – performance issues.
Migration to S/4 SAP development

A sample list of necessary ABAP code adaptations generated as a result of ATC check

ATC can be run with a standard SAP GUI interface – then the requirements of the system on which it is run (central check system), namely SAP_Basis 7.52.

The SAP Fiori Custom Code Migration application is also available along with the ABAP 1809 platform (SAP S/4HANA >=1809). It can also be run in an SAP BTP ABAP environment (in the cloud).

ATC with SAP GUI offers the same options as the SAP Fiori Custom Code Migration application. The difference is that the application allows you to filter the results according to the availability of Quick Fixes, define the scope of code checking by usage and remove unused code during migration.

Quick Fixes

Often, the result of ATC operation is a list of items incompatible with SAP HANA and SAP S/4HANA having several thousand items. It takes a lot of effort to review and adjust each indicated line of code. Most of the ATC findings are known SAP S/4HANA standard issues that can be quickly fixed in an automated manner. Therefore, to minimize the code adaptation effort, SAP offers automatic code adaptation using Quick Fixes as one of the ABAP Development Tools in Eclipse (ADT).

Quick Fixes includes fixes for the most important SAP S/4HANA simplifications use cases, such as increasing the number of characters available for the MATNR field, accessing VBFA, VBUK, VBUP, KONV, BSEG database tables, using the VBTYP data element in the source code. Quick Fixes is not a perfect tool, but it often suggests the developer the way in which a specific piece of code can be adapted.

Old solutions in a new system

The decision to migrate to S/4 does not have to mean stopping the use of custom solutions that the company has developed over the years to optimize its business processes and meet specific needs. On the contrary. The conversion should be used as a good time to review and organize the custom ABAP code.