Overview
This Article will help SAP Application Consultants who have passion for ABAP coding. It will cover followings:
1. S/4HANA Conversion & Custom Code
2. Changes in ABAP Dictionary Objects
3. Essential ABAP Code Review
4. Performance Booster ABAP Code Review
5. Tools for ABAP Code Review
This article has been made with the help of SAP ABAP Training and Training Material. Thanks to SAP for this.
S/4HANA Conversion & Custom Code
When a customer migrates an existing SAP system to S/4HANA, the standard ABAP code is migrated, and if necessary, adjusted automatically by the migration tools in order to run optimally on SAP HANA.
Although the migration tools move custom code to the new S/4HANA target system, there is no automatic adjustment of the code.
The good news is that, in most cases, the code will run as expected. However, an important task in a migration to an S/4HANA project should be the detailed review of custom ABAP code in order to ensure the following:
◈ That the custom code still functions as expected – there are a few coding techniques and database objects that simply do not work in S/4HANA and must be replaced.
◈ That the custom code runs optimally with SAP HANA. Although the code may run, there are easy adjustments to the code that can make a huge impact on performance.
Changes in ABAP Dictionary Objects
In the past, special types of ABAP tables were used in order to overcome limitations of the underlying databases that powered SAP applications.
The tables shown in the figure are called pool and cluster tables and are found in standard and custom ABAP code. One of the key reasons for using special tables was to overcome design limitations of tables in certain databases. The special tables sit in the ABAP layer on top of the physical database and act as a logical layer to the ABAP code.
SAP S/4HANA does not need these special tables, and uses only one type of table, called a transparent table, with no loss in performance or function. A transparent table has a one-to-one relationship with a physical table.
During migration, the special tables are converted to transparent tables. SAP standard code is automatically adjusted to switch from calling the special tables to calling the transparent tables. Secondary indexes are dropped during migration. Indexes are usually not required by SAP HANA. If your code refers to them, you must make adjustments.
Customers and partners need to make their own checks and adjust their code where necessary.
However, if your custom code refers to a standard table that has now been removed, SAP provides views for all removed tables. This means your code still works and just uses the view.
Essential ABAP Code Review
Issues to watch for with the ABAP code that mean the application may not function as expected are as follows:
◈ Review of native SQL: For example, functions that only work with MS SQL Server, and database hints to override the SQL execution plan (for example, use this aggregate if it exists).
◈ Avoid SELECT *: This is another way of asking for all columns in a record. SAP HANA’s column-based database works better when you ask for only columns you need.
◈ Do not assume a sort sequence of the results: Sort sequences were usually implied by the primary key, and SAP HANA does not pre-sort the data. You must explicitly code this sort request, if needed.
Performance Booster ABAP Code Review
Look out for the following items in your existing ABAP code in order to improve the performance:
◈ Avoid SELECT *
SAP HANA’s column-based database works better when you ask for only columns you need, and avoid filling memory with unwanted columns.
◈ Try to Send a WHERE Clause to the SAP HANA Database
Often, developers request all data (they do not use WHERE), and then they filter the data in the application code.
◈ Push Down all Data-Intensive Functions to the SAP HANA Database
Examples include aggregation, filters, and sorts. You do this by calling native SAP HANA database functions.
Tools for ABAP Code Review
SAP provides tools to speed up and automate the code review phase and ensure nothing is missed.
ABAP Code Inspector allows developers to choose the type of checks they want to make. For example, the following:
Code Checks
◈ Show me where I refer to pool and cluster tables
◈ Show me where I use SELECT *
◈ SQL Monitor identifies bottlenecks, so developers can focus on improving the most problematic code. For example, it takes a long time to read a table: maybe table partitioning could help?
Usage and Procedure Logging (UPL) identifies dead code, or code that is rarely used. Do not waste time to improve this if nobody uses it.
No comments:
Post a Comment