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).
|IMPORTANT NOTE: This custom code adaptation process including all following recommendations, processes and the tools is not a “one-time procedure” and has to be carried out on a permanent basis especially before the SAP S/4HANA system conversion and before upgrade within the SAP S/4HANA product family and is to be considered as the regular best practice also for SAP Business Suite and generally all other ABAP-based products.|
Custom code scoping
A typical ERP customer system contains a large amount of custom development objects (Z-Objects, enhancements and modifications) that are not used productively. 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. This procedure is very important and will significantly minimize your custom code adaptation efforts.
For this purpose, we recommend to turn on the ABAP Call Monitor (SCMON) or Usage Procedure Log (UPL) in your production 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 SCMON or UPL has no impact on the performance of your production system.
The advantage of the SCMON compared to the UPL is that using this tool you not only collect the usage data (how often a specific ABAP object was called), but also the information about the calling business process. See ABAP Call Monitor (SCMON) – Analyze usage of your code for more details.
The recommended procedure for usage data collection is ABAP Call Monitor with aggregation of the collected usage data using the SUSG transaction. See Aggregate usage data in your production system with SUSG transaction for more details.
Usage data collected in the SAP Solution Manager 7.2/CCLM can be also used for custom code scoping. Generally, the Solution Manager 7.2 collects either SCMON or UPL data depending whether the connected system is capable of SCMON or UPL.
NOTE: You should collect usage data for a longer period of time (at least one year) to get really reliable results for not productively used code.
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. 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. Therefore, 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 from 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 1809.
SAP S/4HANA Checks in SAP NetWeaver AS ABAP 7.51/7.52
The Field Extension check finds length conflicts in your coding for material number fields (can be suppressed with pseudo comment CI_FLDEXT_OK[note_number])
The Search DB Operations check finds write operations on specific database tables (can be suppressed with pseudo comment CI_DB_OPERATION_OK[note_number])
The Search for usages of simplified objects check finds usages of objects stored in Simplification Database (can be suppressed with pseudo comment CI_USAGE_OK[note_number])
The Search for ABAP Dictionary enhancements finds extensions in the data dictionary (like appends)
The Search for base table of ABAP Dictionary views finds usages of database tables in views
The Search for S/4HANA related Syntax errors tries to map syntax errors to simplification items
In SAP NetWeaver AS ABAP 7.52 the coverage of checked custom code was significantly improved. Custom code checks now scan all custom code in Enhancements, Modifications, Customer EXITs, Smart Forms and ignore findings in SAP includes and generated code. Additionally simplification item information (e.g. OSS note) is displayed in ATC result list including filtering and sorting capabilities.
Technical infrastructure for custom code analysis
The tool of choice for SAP S/4HANA and SAP HANA checks is the ABAP Test Cockpit (ATC) with remote code analysis. You set up only one central ATC check system for all static checks of your custom ABAP code in your system landscape, which needs to be migrated to SAP S/4HANA. More details in the blog series Remote Code Analysis in ATC.
The recommended procedure is the following:
|Setup ATC as (see Remote Code Analysis in ATC – Technical Setup step by step) and implement the SAP Note 2436688 – Recommended SAP Notes for using ATC checks “S/4HANA Readiness”|
|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).|
Custom code analysis options
The ABAP Test Cockpit comes along with its classic SAP GUI based user interfaces to administer the tool and maintain the necessary configuration steps in order to check the custom code.
With ABAP platform 1809 we simplified the whole custom code adaptation process by providing a new SAP Fiori App Custom Code Migration that allows you to execute SAP S/4HANA checks just with a few clicks.
Remote ATC with SAP GUI
The prerequisites for this option are the remote ATC infrastructure and ATC central check system (SAP_BASIS 7.52). Run ATC transaction with the check variant S4HANA_READINESS_REMOTE containing SAP S/4HANA and SAP HANA checks and analyze the ATC result list. ATC offers you best support for detailed analysis of SAP S/4HANA findings using Statistics View, simplification information in ATC result and various navigation capabilities. See also the blog Remote Code Analysis in ATC – Working efficiently with ATC Result List.
For live demonstration of end-to-end custom code adaptation process in SAP GUI check also the Video on YouTube:
Remote ATC with SAP Fiori App Custom Code Migration
The prerequisites for this option are the remote ATC infrastructure, central ATC check system (SAP S/4HANA 1809) and the SAP Fiori App Custom Code Migration.
The App performs SAP S/4HANA checks on your custom code based on remote ATC infrastructure and provides the analytical presentation of the SAP S/4HANA check results with comprehensive aggregation, filtering and navigation capabilities. Beyond this the App identifies the unused custom code based on your collected usage data, and this enables you to remove it automatically via SUM during a system conversion to SAP S/4HANA.
Using the visual predefined filters above you can group your ATC findings to get a quick overview on for example:
- How many findings are in your used custom code (exclude unused code)
- In which SAP S/4HANA simplification areas do you get the most findings
- What are the most urgent findings (by priority)
- For which findings there are Quick Fixes available and which findings you need to fix manually
From the App you can drill-down to ATC results and display affected source code of your ERP system directly in the browser.
For more details on this custom code analysis option see the blog:
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 and SAP S/4HANA findings
Second, you need to fix SAP HANA and SAP S/4HANA findings. Adapt your custom ABAP code, using the findings of the SAP HANA and SAP S/4HANA checks (ATC results).Findings of SAP S/4HANA checks are related to S/4HANA Simplifications. Each simplification requires a different approach to solve findings. Therefore, findings of SAP S/4HANA checks refer to a SAP Note which describes how you can solve them.
SAP HANA finding 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
SAP S/4HANA finding example: 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|
No doubt it is substantial manual effort to look at every ATC finding and adjust your custom code. Besides this very often the most ATC findings are the SAP S/4HANA standard known issues, which could be fixed quickly in the automated way.
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).
Currently the Quick Fixes for the most prominent SAP S/4HANA simplification use cases like MATNR extension, accesses to database tables VBFA, VBUK, VBUP, KONV, BSEG, usage of VBTYPE data elements in source code are available. Beyond this the mass-enabled Quick Fixes make it possible to adapt full packages or software components in one shot and in this way drastically reduce your custom code adaptation efforts. Check also the blog:
Naturally after functional adaptation you need to test your business processes (using automated testing like eCATT).
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:
For further details check the Custom Code Migration Guide for SAP S/4HANA 1809.