Dear ABAPers this post helps to create ABAP coding in efficient manner, when you are creating ABAP applications than just remember these rules to create SAP ABAP coding in a efficient manner.
1) Processing Database Tables
Reading through a set of related tables:
When reading through a set of related tables, use a logical database whenever possible. The combination of defining a logical database (a program that reads a table and its dependant table entries) and using the logical database-related event keywords (e.g. GET) is more efficient than a set of nested SELECT ... ENDSELECT statements.
2) Checking SELECT-OPTIONS when reading via a Logical Database
When using the GET event keyword to retrieve records via a logical database, selection can be restricted by using the CHECK statement (using either CHECK select-option(s) or CHECK condition).
In this case, a CHECK statement that returns a negative result terminates the processing of GET events for subordinate database tables and the associated data is not read. For efficiency reasons, you should therefore always perform the CHECK at the highest possible level of the database hierarchy.
For example:
SELECT-OPTIONS: S_CNTRY FOR KNA1-LAND1,
S_COY FOR KNB1-BUKRS.
...
GET KNA1.
CHECK S_CNTRY.
GET KNB1.
CHECK S_COY.
...
is more efficient than:
SELECT-OPTIONS: S_CNTRY FOR KNA1-LAND1,
S_COY FOR KNB1-BUKRS.
...
GET KNB1.
CHECK SELECT-OPTIONS.
3) SELECT SINGLE vs. SELECT *
SELECT SINGLE * is more efficient than SELECT * … ENDSELECT.
Whenever the full key of a table is known,
use: SELECT SINGLE * FROM dbtab WHERE …. (full key).
rather than:
SELECT db_field1 db_field2 db_field3 FROM dbtab
WHERE …. (full key).
...
ENDSELECT.
UP TO 1 ROW can be used to retrieve one record when the full key is not known.
Whenever the full key is not known you will need to use the SELECT * ... ENDSELECT version of the SELECT statement.
In this case, specifying values for as many of the table’s key fields in a WHERE clause will make the SELECT statement more efficient than checking values after the select.
4) Selecting via non-key fields or non-key partial fields
When selecting records from a database table when only part of a field (on which selection is based) is known, use the LIKE option as part of the WHERE clause.
For example:
SELECT * FROM T001G
WHERE BUKRS EQ ‘US01’
AND TXTKO LIKE ‘__PERS%’.
....
ENDSELECT.
is more efficient than:
SELECT * FROM T001G
WHERE BUKRS EQ ‘US01’.
CHECK T001G-TXTKO+2(4) = ‘PERS’.
....
ENDSELECT.
SELECT <field1>, <field2> …
If you only need a few fields of a table, it is much more efficient to only retrieve exactly those fields from the database than to select all of them (SELECT * …).
Example: if you only need the fields order number, order type and customer from the sales document table, code as follows:
SELECT VBELN AUART KUNNR FROM VBAK
INTO (VBAK-VBELN, VBAK-AUART, VBAK-KUNNR)
WHERE …
WRITE: / …
ENDSELECT.
5) SELECT … UP TO n ROWS
If you only need a certain number of records specify this in your select- statement:
SELECT … FROM … UP TO 10 ROWS.
This is much faster than issuing a SELECT without the UP TO clause and then checking for the system variable SY-DBCNT.
SELECT INTO TABLE
Reading an internal table is faster than reading a database table.
Therefore, use internal tables to store information that must be accessed multiple times throughout a program.
Also, use internal tables when you have to read a header - item structure for which you would otherwise use nested SELECTs Instead of processing a
SELECT … INTO <itab-fields>
APPEND ITAB
ENDSELECT.
statement it is far more efficient to select the fields straight into the internal table and process the data from the internal table:
SELECT … FROM … INTO TABLE ITAB WHERE …
LOOP AT ITAB.
…
ENDLOOP.
5) SELECT FROM … ORDER BY
In most cases it is preferable to do the sorting within the ABAP program instead of on the database server, that means: fill the internal table via a SELECT statement and then sort via the SORT statement instead of coding a SELECT … ORDER BY.
The sorting of large amounts of data on the database server affects the performance of all users on the system, whereas the sorting within the ABAP program ‘only’ affects the
application server. However, if an index exists on the table that can be used for the sorting then the SELECT … ORDER BY doesn’t cause any undue strains on the system.
6) Aggregate Functions
Instead of using ABAP, some calculations can be done by using
aggregate functions for the SELECT. These are: SUM, AVG, MIN and MAX.
Example:
SELECT MATNR SUM( KWMENG ) MEINS FROM VBAP INTO TABLE T_VBAP WHERE … GROUP BY MATNR MEINS
This example will select the cumulative sales quantities grouped by material number and quantity unit.
7) SELECT without WHERE
Coding a SELECT statement without a WHERE condition is only allowed for very small tables (e.g. customizing settings). For all other tables this is not permitted as performance problems will occur within a short period of time.
8) UPDATE
Instead of updating records within a SELECT … ENDSELECT construct
e.g. SELECT * FROM ZVBAK WHERE VBELN IN S_VBELN.
ZVBAK-VKBUR = W_VKBUR.
UPDATE ZVBAK.
ENDSELECT.
define your record selection in the UPDATE statement.
UPDATE ZVBAK SET VKBUR = W_VKBUR WHERE VBELN
IN S_VBELN.
9) DELETE
The same consideration as for the UPDATE is true for the DELETE:
Instead of deleting records within a SELECT … ENDSELECT construct
e.g. SELECT * FROM ZVBAK WHERE VBELN IN S_VBELN.
DELETE ZVBAK.
ENDSELECT.
define your record selection in the DELETE statement.
DELETE FROM ZVBAK WHERE VBELN IN S_VBELN.
10) COMMIT
ABAP reports that issue INSERT, UPDATE or DELETE commands have to issue COMMIT WORK statements after a logical unit of work is completed. Missing COMMITs can lead to bottlenecks on the database side because the system has to keep track of the table changes via rollback segments (in order to enable a rollback of all changes since the last commit). Rollback segments are kept in memory and missing COMMITs can lead to overflows of the rollback segment areas. Also the database system holds locks on the changed records that are not released until COMMIT time.
11) Processing Internal Tables
Filling
To load an internal table from a database table where the structure of the internal table is at least as wide as the structure of the database table use:
SELECT * FROM dbtab INTO TABLE itab.
rather than:
SELECT * FROM dbtab.
MOVE dbtab TO itab.
APPEND itab.
ENDSELECT.
To fill an internal table without creating duplicate entries and add up the Packed, Integer, and Floating Point fields at the same time,
use:
COLLECT itab.
12) Sequential Reads
If you are reading through an internal table sequentially using the LOOP at itab ... ENDLOOP method, but are only interested in certain entries, use a WHERE clause and specify a condition for selection. Note that the performance of a LOOP AT ... WHERE statement is improved greatly if all fields being compared in the WHERE clause are of the same data type.
Therefore, you should try defining the ‘compare’ fields as follows:
DATA: compare_field LIKE itab-field1.
BEGIN OF itab OCCURS 100,
field1(5), field2(5),
END OF itab.
compare_field = <value to compare>.
LOOP AT itab WHERE field1 = compare_field.
ENDLOOP.
13) Direct Reads
If you are not processing the entire internal table, use:
READ TABLE itab WITH KEY key BINARY SEARCH.
rather than:
READ TABLE itab WITH KEY key
The second method performs a sequential read from the first record until if finds a match.
The first method performs a binary search to find a matching record, but the table must be sorted first.
14) Sorting
Wherever possible, identify the fields to be sorted.
The format:
SORT itab BY field1 field2.
is more efficient than:
SORT itab.
SORT itab without fields specified attempts to sort the table by all fields other than Packed, Integer, and Floating Point fields.
15) Counting Entries
To count up the number of entries in an internal table,
use:
DESCRIBE TABLE itab LINES field.
where field is a work field of type ‘I’ (integer).
rather than:
LOOP AT itab.
W_COUNT = W_COUNT + 1.
ENDLOOP.
16) Reading large internal tables
If you have to retrieve selected records from a large internal table, keep this table sorted. In this way, you can access the table via the
READ TABLE T_VBAK WITH KEY VBELN = W_VBELN BINARY SEARCH statement.
If you only want to verify the existence of a record but don’t need any of the fields from the record then use the addition
17) TRANSPORTING NO FIELDS
If you only need a few fields from the internal table for processing then use the addition
TRANSPORTING <field1> <field2> …
Moving data from internal table 1 to internal table 2
If you need to move all entries from one internal table to another one which has the same structure you can simply do it via the following statement:
ITAB2[] = ITAB1[].
Appending data from internal table 1 to internal table 2
If you need to append records from one internal table to another one which has the same structure you can simply do it via the following statement:
APPEND LINES OF ITAB1 TO ITAB2.
18) Looping at internal tables
If you are looping at an internal table just to count the number of records that fulfill certain criteria then use the following variant of the loop statement:
LOOP AT T_VBAK TRANSPORTING NO FIELDS
WHERE …
ADD 1 TO COUNTER.
ENDLOOP.
The same applies if you only want to verify that at least one record exists that satisfies a certain condition:
LOOP AT T_VBAK TRANSPORTING NO FIELDS
WHERE …
EXIT.
ENDLOOP.
IF SY-SUBRC = 0.
* Record found …
ENDIF.
19) DELETING DATA FROM INTERNAL TABLES
If you need to delete a subset of records from an internal table use the following:
DELETE T_VBAK WHERE …
DELETING DUPLICATE ENTRIES FROM AN
INTERNAL TABLE
To delete duplicate entries from an internal table the table has to be sorted by the fields used in the comparing condition. If there is no comparing condition the table should be sorted by all fields.
DELETE ADJACENT DUPLICATES FROM T_VBAK
[COMPARING field1 field2 …]
20) Miscellaneous
Moving data from one table work area/structure to another one with an identical structure.
Use:
MOVE structure1 TO structure2.
rather than:
MOVE-CORRESPONDING structure1 TO
structure2.
Determining the length of a string.
Use:
fieldlength = STRLEN( field ).
rather than:
IF field CP ‘#’.
ENDIF.
fieldlength = SY-FDPOS.
21) ASSIGN statement
If assigning the contants of a field belonging to a Dictionary defined table/data structure which itself contains a name of a field to a field symbol, use the ASSIGN TABLE FIELD syntax of the ASSIGN statement.
For example:
ASSIGN TABLE FIELD (KNA1-NAME1) TO <fs>.
is more efficient than:
ASSIGN (KNA1-NAME1) TO <FS>.
This is because the search for the field (in this case KNA1-NAME1) is carried out only in the Data Dictionary and not in the symbol table. The field must then be a component field of a database table declared with the TABLES statement. This improves the performance of this statement considerably. In contrast to the second method above, the performance
does not depend on the number of fields used within the program.
22) Testing for Initial Value
The use of the IF statement for checking whether a field is empty (i.e. equal to the initial value for its data type) can be made more efficient by comparing the field with another of the same data type.
For example:
IF MARA-IDNRA = SPACE.
....
ENDIF.
is more efficient than:
IF MARA-IDNRA IS INITIAL.
....
ENDIF.
23) Testing one field for multiple values
When testing an individual field for multiple values, you can use:
IF field = value1.
....
ELSEIF field = value2.
....
ENDIF.
or:
CASE field.
WHEN value1.
....
WHEN value2.
....
WHEN value3.
....
WHEN valuen.
....
ENDCASE.
The first method is more efficient when checking a field for up to about five values. But the improved readability of the program code associated with the CASE statement dictates that its use should be applied for levels of three or greater.
24) Optimizing IF and CASE structures
To optimize IF and CASE structures, always test values in order of the likelihood of each value occuring. For example, fieldx can have values ‘A’, ‘B’, or ‘C’. A value of ‘B’ is the most likely value to occur, followed by ‘C’, then ‘A’. To optimize a CASE statement for fieldx, code the CASE statement as follows:
CASE fieldx.
WHEN ‘B’. “Most likely value
WHEN ‘C’. “Next most likely value
....
WHEN ‘A’. “Least likely value
ENDCASE.
25) Subroutine / function performance
Because of the added overhead of calling subroutines, functions, etc., you should avoid the following style of coding:
Use:
IF field NE 0.
PERFORM SUB1.
ENDIF.
FORM SUB1.
....
ENDFORM.
rather than:
PERFORM SUB1.
FORM SUB1.
IF field NE 0.
....
ENDIF.
ENDFORM.
26) Hard-coding Text (messages, report output, etc..)
DON’T ! Wherever possible, all text to be passed to messages, or to be written to a report should be created as Text Symbols. This allows text to be more easily maintained and supports the maintenance of these texts in other languages.
Checking Return Code
The return code should always be checked after any database table read/update statements.
For SELECT ... ENDSELECT processing loops, the return code should be checked after the ENDSELECT statement to check for the success of the SELECT statement.
For LOOP AT ... ENDLOOP processing loops, the return code should be checked after the ENDLOOP statement to check for the success of the LOOP statement.
27) String manipulations
Special operators
Use the special operators CO, CA etc. instead of programming the operation yourself. Especially on long strings, ABAP statements per character can cause high CPU consumption.
28) CONCATENATE
Instead of programming a string concatenation of your own, use the CONCATENATE statement. Also, make use of the SPLIT statement or the STRLEN function whenever you need to split a string into several components or have to determine the length of a string.
29) Deleting leading spaces
If you want to delete the leading spaces in a string, use the ABAP statement
SHIFT … LEFT DELETING LEADING …
Avoid in any case using SHIFT inside a WHILE loop.
"You found the information helpful and want to say thanks? Your donation is enough to inspire us to do more. Thanks a bunch!"
1 comments:
Really Helpful
Post a Comment
Note: Only a member of this blog may post a comment.