Why do you need to adapt your custom code during system conversion from the classic SAP ERP system running on any DB to SAP S/4HANA? The blog SAP S/4HANA System Conversion – Challenge for your custom code gives you the answer to this question.
Considering SAP S/4HANA system conversion (more on this in SAP S/4HANA System Conversion – At a glance) we focus in this blog on the custom code related process, which consists basically of two major phases. Before SAP S/4HANA system conversion – during preparation phase – we recommend to get rid of your old unused custom code (custom code evaluation) and then analyze your custom ABAP code with the Simplification Database and find out which objects need to be changed to get adapted to the SAP HANA and SAP S/4HANA (SAP S/4HANA checks). After SAP S/4HANA system conversion – during the realization phase – you need to adapt your custom ABAP code to the new SAP S4/HANA software (functional adaptation) and optimize performance for SAP HANA database (performance tuning).
Custom code evaluation
Traditionally SAP customers developed over years so much custom ABAP code that it is not clear, which parts of it are still really productively used. Therefore it is recommended to monitor your system landscape for a longer period of time in order to do some housekeeping and eliminate the code, which is not used anymore within your productive business applications.
For this purpose we recommend to turn on the Usage Procedure Log (UPL) in your productive system to find out, which custom ABAP objects are really used within your running business processes. You can also use this step for prioritization: to find out which objects are more important as the others. The UPL has no impact on the performance of your productive system. Refer to the Monitor usage of your custom code via Usage and Procedure Logging (UPL) for more details.
The Solution Manager tool Custom Code Lifecycle Management (CCLM) can retrieve the usage data from your productive system and visualize them for your convenience. Based on the graphical presentation you get better transparency of the usage of your custom ABAP code and can easier analyze it then using only UPL technical data.
You should monitor your business processes with the UPL for a longer period of time to get really reliable results for not productively used code. Only after that longer period of monitoring you can remove unused custom ABAP code using CCLM decommissioning cockpit. For more details please refer to the Custom Code Management Decommissioning.
SAP HANA and SAP S/4HANA checks
This step is the most important one for your custom ABAP code on the way to the system conversion to SAP S/4HANA. Here you check your custom ABAP code for SAP HANA and SAP S/4HANA related changes.
The SAP S/4HANA is based on the SAP HANA database. Generally the ABAP code runs on SAP HANA as on any other supported database. So why do you need to adapt it to SAP HANA?
One reason is, that you possibly used native SQL of the predecessor database and these database vendor specific dependencies must be eliminated. Another reason is, that in some custom code implementations the SELECT statement without ORDER BY is used assuming that the data in a database table was already sorted (for example by key). According to the SQL specification when using SELECT statement without ORDER BY, you cannot rely on the sort order because it depends on the respective implementation of the DB vendor and therefore can cause unexpected behavior when the database changes (for example to SAP HANA) because the results of SELECT without ORDER BY return in a different order.
Thus you need to check your SQL SELECTs without ORDER BY statement if they are still correct. Beyond this pool/cluster tables were removed with SAP HANA, therefore the database operations on these tables also need to be removed in your custom ABAP code.
To prepare your custom ABAP code for the actual SAP S/4HANA conversion, you need to compare it with the Simplification Database. For more information on Simplification Database please refer to the blogs Upcoming tools for SAP S/4HANA migration – the simplification database, Simplification List SAP S/4HANA 1610.
The result is the work list of the incompatible findings, which you would need to process one by one. At this step you can estimate the required custom ABAP code adaptations efforts to migrate your code to the SAP S/4HANA.
The tool of choice for SAP HANA and SAP S/4HANA checks is the ABAP Test Cockpit (ATC) with Remote Code Analysis. You set up only one ATC central system (SAP_BASIS 7.51) for all static checks of your custom ABAP code in your system landscape, which needs to be migrated to SAP S/4HANA. More details on ATC Remote Code Analysis in the blog Remote Code Analysis in ATC – One central check system for multiple systems on various releases.
The recommended procedure is the following:
- Setup ATC as (see Remote Code Analysis in ATC – Technical Setup step by step)
- Download the newest version of the Simplification Database content from SAP Service Marketplace (see SAP Note 2241080)
- Install the Simplification Database content on the central ATC check system (use transaction SYCM).
- Execute SAP HANA and SAP S/4HANA checks: Run the ABAP Test Cockpit with variants FUNCTIONAL_DB and S4HANA_READINESS_REMOTE.
- Analyze the ATC result list
|SAP S/4HANA Checks in SAP NetWeaver AS ABAP 7.51
After you did the system conversion to SAP S/4HANA with Software Update Manager (SUM) (you don’t need first to migrate the database to SAP HANA and then update the software to the SAP S/4HANA, the SUM does it in one step) we recommend to run ATC with SAP HANA and SAP S/4HANA checks. After that you need to carry out functional adaptation based on the ATC results.
Adjust modifications and enhancements
First you need to adapt the modifications and enhancements using the standard transactions SPDD, SPAU and SPAU_ENH. This is the same process as in previous upgrades within the SAP Business Suite product portfolio, only the tools SPDD and SPAU have been renewed. Especially when moving the very old system to SAP S/4HANA many modifications and enhancements can be removed or set to SAP standard. For this purpose the new UI was invented for SPAU, which supports mass activities in order to adjust modifications and enhancements or reset objects to SAP standard more easily.
New UI in SPAU
Recommendation: Reset as many objects as possible to SAP standard.
Fix SAP HANA findings
Second, you need to fix SAP HANA findings. You adapt your custom ABAP code, using the findings of the SAP HANA checks. Adapt findings as described in the referenced SAP Notes.
For example if you selected from the table without any order and execute binary search, it will return the wrong entries, therefore you need to fix your SELECT by either providing ORDER BY statement or sort the internal table before the statement READ TABLE … BINARY SEARCH.
Fix ORDER BY
Fix SAP S/4HANA findings
Third you need to fix the SAP S/4HANA findings. You adapt your custom ABAP code, using the findings of the SAP S/4HANA checks (ATC results). Adapt findings as described in the referenced SAP Notes.
For example you replace your own defined material number with the SAP data type MATNR:
The TOP 10 Simplification Items
|2215424||Material number field length extension|
|2198647||Data model changes in SD|
|1976487||Data model changes in SAP S/4HANA Finance|
|2220005||Data model changes in Pricing and Condition Technique|
|2214585||Sales support is not available|
|2223144||Foreign Trade is not available|
|2206980||Data model changes in Material Inventory Management|
|2227579||Storage Location MRP|
|2226131||Public Sector specific fields in Business Partner|
|2296016||Removal of orphaned objects|
After you did the system conversion to SAP S/4HANA and the system is up and running, you need to look which business processes can to be optimized on SAP HANA database, since you can now make use of full power of SAP HANA regarding performance. Therefore you need to look which SQL statements can be optimized. The SQL Monitor (ABAP SQL Monitor – Implementation Guide and Best Practices) allows you to get performance data for all SQL statements executed in your productive system. You can run it for a longer time period directly in your productive system (transaction SQLM) without major performance impact on your business processes (performance overhead < 3%). SQL Monitor helps you to understand, what are the most expensive and most frequently executed SQL statements, which SQLs read/write millions of records and provides the transparent SQL profile. SQL Monitor allows you to link the monitored SQL statements to the corresponding business processes including various aggregation and drill-down options.
As shown on the screenshot you can use for example transaction as the entry point and drill down the collected SQL runtime information to optimize SQL statements (e.g. by pushing the application logic to the SAP HANA database).
SQL Monitor Example: