7.3ABAP Code Analysis
Because the Code Inspector has very extensive functions, we can’t cover them in detail here. If you’re interested in learning more about the Code Inspector, we recommend ABAP Performance Tuning by Hermann Gahm (SAP PRESS, 2009). Here, we’ll describe the new and revised Code Inspector checks that are relevant for SAP HANA. You’ll learn how to perform checks in the development environment and how to check the entire system.
7.3.1Checks and Check Variants
When the Code Inspector performs a code analysis, it executes a checklist that comprises a defined set of development objects. Here, you can use check variants to configure the list of checks to be performed and their settings.
In this section, we’ll introduce those checks that can support you in migrating to or optimizing SAP HANA. These checks primarily relate to the following areas: robust programming, security checks, and performance checks. The Code Inspector also contains a large number of additional checks that we won’t discuss here in detail. Accurate technical documentation on all checks is available in Transaction SCI, which is used to configure the check variants that you’ll learn about in this section.
Relevant Checks when Migrating to SAP HANA
During migration, the main priority is to ensure that you don’t experience any functional setbacks, including program terminations and unwanted changes to the behavior of an application. In general, thanks to the compatibility and portability of ABAP code, no adjustments are required.
An exception here is any part of a program where you used database-dependent implementations in the past. These include the use of Native SQL and database hints. The following two check options can help you locate such parts within a program: Use of ADBC Interface and Critical Statements.
The sorting behavior may also require adaptations, particularly if no explicit sorting is specified in the program code, for example, using ORDER BY or SORT. If no ORDER BY clause is specified, the database returns the data in an unsorted sequence. In classic databases, the sequence might involve a database index if it was used for the query. The ABAP program frequently received the data in the desired sequence. However, this was rather coincidental, and there was no guarantee for this sorting. For stable programming, you had to specify the ORDER BY addition here.
In SAP HANA, there are considerably fewer database indexes, and most of them differ from those of classic databases. To receive the read data in the desired sequence, you must use the ORDER BY addition or subsequently sort in the ABAP program using SORT as was the case for classic databases. You can use the check option Search problematic Statements for Result of SELECT/OPEN CURSOR Without ORDER BY to find those parts of the program for which a result set that requires a sorting (e.g., in a binary search) is processed using an ABAP command and for which a sorting can’t be determined in the program via ORDER BY or SORT.
A further example involves pool/cluster tables, which, when migrated to SAP HANA, are converted into transparent tables (discussed in Chapter 3, Section 3.2.1). This doesn’t require any change to the application. However, you must consider that when data is selected in Open SQL without any specified sorting, the documentation states that the user can’t rely on sorting (e.g., according to the primary key). For pool/cluster tables, however, the database interface always supplements the ORDER BY PRIMARY KEY addition internally. If you’ve relied on this behavior (i.e., you chose not to specify a particular sorting), you may have to add an ORDER BY statement after the migration. In the Robust Programming category, a check is available to help you find the relevant parts within the program. SAP recommends that you adjust these parts of the program irrespective of a migration to SAP HANA because this is a programming error. In Chapter 14, we’ll give further recommendations for existing ABAP code when migrating to SAP HANA.
Relevant Checks during Optimization for SAP HANA
To identify optimization potential in the context of database accesses, you have a range of checks at your disposal. These checks essentially reflect the performance recommendations for Open SQL, which are explained in detail in Chapter 14. In the next section, we’ll introduce some important checks, including some key enhancements and improvements in AS ABAP 7.4.
Unsecure Use of FOR ALL ENTRIES
The performance optimization in which you convert a nested SELECT statement into a FOR ALL ENTRIES statement or a join is frequently successful. For a FOR ALL ENTRIES expression, the driver table must never be empty. Otherwise, all the data records are read from the database, which generally isn’t desired. Therefore, a check to determine whether the driver table is empty must always be performed before a FOR ALL ENTRIES statement is executed. The check to detect unsecure use of FOR ALL ENTRIES searches for parts of the program in which the driver table doesn’t appear to be checked.
Searching FOR ALL ENTRIES Clauses to Be Transformed
In many situations, a join offers additional performance advantages over a FOR ALL ENTRIES clause. For this reason, the system performs a check on those FOR ALL ENTRIES clauses to be transformed and finds clauses that can be converted to joins. This is only the case if a database access was used to determine the driver table for the FOR ALL ENTRIES expression.
SELECT Statements that Bypass the Table Buffer
The ABAP table buffer still plays an important role when using SAP HANA as a database. To avoid an increased database load, you shouldn’t bypass this buffer if buffering has been switched on for a table. To this end, a check is performed on SELECT statements that ignore the buffer. Note that this check can’t support you in finding the right buffer setting for a table.
Problematic SELECT* Statements
You should avoid reading database columns that you don’t need. To this end, a check is available to find SELECT statements for which too many fields are selected. Frequently, this concerns pure existence checks—where all fields are selected, even though the return code for the SELECT statement is sufficient. However, there are also scenarios in which only a small part of the fields is actually used. With AS ABAP 7.4, these checks are also able to identify usage in another modularization unit (e.g., in another ABAP class or another function module). Therefore, the entire call sequence is analyzed, which means you can set the depth of search when configuring this check.
Searching SELECTs in Loops in Modularization Units
Usually, performance problems aren’t caused by a single database access but rather a large number of accesses in succession. For example, problems can occur with accesses that are executed in loops. Consequently, there is a range of checks that can find such loops. In particular, they include a check that finds SELECT statements that are executed in loops. As of AS ABAP 7.4, searches can also extend beyond modularization units. Consequently, the triggering part of the program for a SELECT statement can also be determined for complex implementations.
Change Database Accesses in Loops
For change operations, you should also favor array processing (see also Chapter 3, Section 3.2.2) over individual operations at all times, if possible. To this end, a check is available to find individual INSERT, UPDATE, or DELETE statements that are executed in loops.
EXIT/CHECK in SELECT… ENDSELECT loop
If you use EXIT to exit a SELECT… ENDSELECT loop, a large number of data records may be read unnecessarily because the data are transferred in blocks. A CHECK statement that immediately follows a SELECT statement indicates that a filter isn’t used until the data has been read. Frequently, these two expressions can be converted into a suitable WHERE condition.
Configuring Check Variants
You can configure check variants in Transaction SCI or in the ABAP Test Cockpit. SAP provides a range of default variants. Figure 7.2 shows the PERFORMANCE_DB check variant, which is available in AS ABAP 7.4. It provides a useful default configuration and contains the checks introduced in this section.
Figure 7.2Code Inspector: Performance_DB Check Variant
However, you can also define custom check variants by selecting and configuring suitable checks from the directory tree. Furthermore, you can define check variants specifically for one system user or globally for all system users.
7.3.2Checks in the Development Infrastructure
In this section, we’ll explain how you, as the developer, can check individual objects. This enables you to perform a static code analysis before you release a new development or change to find errors before they are transported to a test system.
In the ABAP Workbench (Transaction SE80), you can use the context menu option, Check • ABAP Test Cockpit, to perform a check on a development object or package. The results are displayed in a list. From here, you can navigate to the relevant parts of the program (see Figure 7.3).
Figure 7.3Code Check in Transaction SE80
The checks are also natively integrated into the ABAP Development Tools in Eclipse, which offers some advantages. Here, you use the context menu option, Run As • ABAP Test Cockpit, to start the check. Figure 7.4 shows the result of a check performed using the example from Listing 3.9 in Chapter 3, Section 3.2.2. The relevant parts of the program are highlighted clearly, and it’s easy to navigate via the found locations.
Figure 7.4Code Check in Eclipse
The system default check variant is used first. However, you can use the project setting in Eclipse to replace the default variant with a custom variant, as shown in Figure 7.5.
Figure 7.5Selecting a Check Variant in Eclipse
7.3.3Global Check Runs in the System
In the previous section, you learned how to check individual development objects or an entire development package. To ensure systematic use of such checks within a quality management process, it makes sense to perform the checks automatically at certain times for all developments (or selected parts) and to analyze the results.
In this section, we’ll show you how to perform code checks in the ABAP Test Cockpit, which offers considerable advantages over the Code Inspector. You can manage the results of check runs, replicate them to other systems, manage exceptions, and automatically send results by email. Furthermore, the ABAP Test Cockpit is integrated into the ABAP Workbench (by means of a special browser) and into SAP Solution Manager.
To start the ABAP Test Cockpit, call Transaction ATC. Here, you can configure the cockpit, schedule check runs, and analyze results. Figure 7.6 shows the initial screen for the transaction. You can use the Schedule Runs option to configure a check run. To do this, select a Code Inspector check variant and a set of objects. Figure 7.7 shows a configuration for the PERFORMANCE_DB variant (introduced in Section 7.3.1) checking the TEST_A4H_BOOK* packages, which contain examples from this book.
Figure 7.6ABAP Test Cockpit: Initial Screen
Figure 7.7Configuring a Check Run
You can now schedule such a check run (either once or at specific times), which is then executed asynchronously in the background. You can then view the result under Analyze and Activate Results in the ABAP Test Cockpit or in the ATC Result Browser in the ABAP Workbench (see Figure 7.8). To do this, you may first have to activate this browser in the workbench settings for your user.
Figure 7.8Result of an ABAP Test Cockpit Check Run in Transaction SE80
In Section 7.6, we’ll show you how to merge the results of an ABAP Test Cockpit run with runtime data from the SQL Monitor for performance optimization.