abap performance and best practices a bible v1 0

ABAP performance and best practices .

- a Bible.

WBEI Engagement OverviewProprietary and confidential © Copyright Capgemini 2007 All Rights Reserved

Symbols used :

Symbol Meaning

Very good performance(recommended).

Forbidden (never use).

Not the best method (to be used only when there is no other way).

A prerequisite (must do activity).

Additional information .


What is it all about ?

Write a program quickly and save time ?

Write a program accurately which will be more performing in its execution time

and would not break in real time?


Goals :

Explore the areas of performance tuning in ABAP .

Write fine tuned new ABAP programs .

Fine tune existing ABAP programs .


Performance – Areas in ABAP .

General Rules.

Selection on a single table .

Selection on many tables .

Commit and Rollback .

Data Dictionary .

Mass treatment – Internal table and data base .

Operations on internal tables .

Special topics .

Tools available to validate source code from performance and standards point of view.

Tools available to measure performance.


General rules : Dos of a good programming .

DO‟S

Maintain standard documentation headers for programs and subprograms (describing author, function,

changes, interface, side-effects)

Document the interfaces of subroutines and functions

Indent the lines of your programs

Modularize your programs

Specify the type of data objects explicitly (if possible)

Use speaking names for variables and fields


General rules : Don’ts of a good programming .

DONT‟S

– Avoid NULL statements (statements without effect)

– Avoid deeply nested loops

– Avoid unreachable program parts

– Avoid side-effects on global variables

– Do not use a variable for multiple purposes (e.g. as counter and as string)

– Avoid spaghetti code .


General rules :

When we use the <SELECT INTO TABLE wt_table> instruction, exchanges between the database

server and the application server are made by packets.

When we use the <SELECT … ENDSELECT> instruction, exchanges between the database

server and the application server are one recording by one recording.

Data loading in Internal table


General rules :

SELECT SINGLE

SELECT UP TO 1 ROWS

…

ENDSELECT

SELECT INTO TABLE wt_table

SELECT INTO TABLE wt_table

… FOR ALL ENTRIES

SELECT …

ENDSELECT.

Logical databases

Nested select

GROUP BY

ORDER BY

[…]CORRESPONDING FIELDS OF […]

DISTINCT


General rules :

Queries are forbidden because programs generated by a Query are not performing

at all. Requests are not optimized, thus execution time is too high.

Queries


Selection on a single table :

SELECT *

FROM table

WHERE field1 = „xxx‟.

Treatment.

EXIT.

ENDSELECT.

SELECT *

FROM table

UP TO 1 ROWS


Treatment.

ENDSELECT.

SELECT SINGLE *

FROM table


IF sy-subrc = 0.

Treatment.

ENDIF.

Use : field1 is not the

primary key.

Use : field1 is the primary

key or a part of the primary

key.

After many compared tests, it is proven that the <SELECT SINGLE> instruction

seems to be more efficient that <UP TO 1 ROWS> one.



When we are on the instruction which follows <ENDSELECT>, we do not know if we have

gone into the <SELECT> instruction or not. This implies that it is always necessary to

test the return code after the <SELECT> instruction.

Except for the particular cases: Use: Selection of a limited number

of fields.

SELECT SINGLE *

FROM table


SELECT SINGLE field1

INTO table-field1

FROM table


8.0tabletheoffieldsofnumber

fieldsselectedofnumber


Selection on a single table : The <where> clause .

The order of the fields in the <WHERE> clause has an impact on the execution time of

the request. SAP works with a positioning pointer on the tables. The first field of the

<WHERE> clause permits the pointer to position itself. Then the table is sequentially

read. Therefore the order of the tests in the <WHERE> clause is very important.

When the developer codes an instruction in order to read in the database, he/she must respect

the following rules by ascending priority:

Put the fields in the same order of the existing index (primary or secondary).

Put the fields in the same order of the key .

Runtime chooses the index based on the fields used in <where> clause.

Order of the fields in <where> clause is very important in deciding index.


Selection on a single table : Index (to speed up data fetch) .

Primary Fields forming the primary key of the table form primary index.

Every table has a primary index by default.

Created automatically when the table is activated .

As far as possible , primary index should be used .

Secondary Consists of fields from non primary keys.

When the primary index cannot be used , secondary indexes

have to be created explicitely .

When the table is client dependent , the secondary index must

contain MANDT as first field .

Slows related SAP transactions .

No Index Fields in the <where> clause doesnot form fields from any index

.


Selection on a single table : <select > statement

SELECT SINGLE *

INTO table

FROM table

WHERE field = „xxxx‟.

SELECT SINGLE *

FROM table

WHERE field = „xxxx‟.


Selection on a single table : Data sorting.

Data sorting

Sorting on the database server. Sorting on the application server.

SELECT *

FROM table

WHERE field1 = „xxxx‟

ORDER BY field2.

Treatment.

EXIT.

ENDSELECT.

SELECT *

INTO TABLE wt_table

FROM table

WHERE field1 = „xxxx‟.

IF sy-dbcnt NE 0.

SORT wt_table BY field2.

LOOP AT wt_table.

Treatment.

ENDLOOP.

ENDIF.


Selection on a single table : <into> option

Treatment without storing the data into a

table.

SELECT SINGLE *

INTO table

FROM table


IF sy-dbcnt NE 0.

wv_field2 = table-field2.

Treatment.

ENDIF.

SELECT SINGLE field2

INTO wv_field2

FROM table

WHERE field1 = „xxxx‟

IF sy-dbcnt NE 0.

Treatment.

ENDIF.



<INTO TABLE> option :

This option permits to stock many records in an internal table.

It is not necessary to carry out a <REFRESH> of the internal table because it is automatically made

by this option. Furthermore, the <APPEND> of the internal table is implicit.

There is no <ENDSELECT> instruction because it is not a loop treatment. The storage of the table

is carried out at one go.

<APPENDING TABLE> option :

This option permits to add further records to an internal specified table.

The <APPEND> instruction is included is the <APPENDING TABLE> instruction. If the internal table

is refreshed (<REFRESH>) just before using the <APPENDING TABLE> instruction, it is the same

as using the <INTO TABLE> instruction. Therefore if the internal table is empty, the <APPENDING

TABLE> instruction must not be used.

There is no <ENDSELECT> instruction because it is not a loop treatment. The updating of the table

is carried out at one go.



<[…] CORRESPONDING FIELDS OF […]> options

If we want to stock the contents of the chosen fields in another field (different of the buffer), it must have the

same structure as the chosen fields.

The <INTO CORRESPONDING FIELDS OF> instruction is equivalent to a <MOVE-CORRESPONDING> one

between the selected columns and the stocking fields.

Indeed, this option is used when there is a difference between the structure consisted of the fields of the

<SELECT> and the target (in the <INTO>). In this case, the SAP process researches one after one the fields

which have the same names and then make the allocation.

But it is better to put the fields of the <SELECT> instruction in the same order of the

structure declaration or the internal table in order to be quicker.



Not recommended use of <INTO CORRESPONDING FIELDS OF…>

Direct storage into a table or a structure, without using the fields.

SELECT SINGLE *

INTO CORRESPONDING FIELDS OF table

FROM table

WHERE key = „xxxx‟.

SELECT SINGLE *

FROM table

WHERE key = „xxx‟.

DATA: BEGIN OF ws_struct,

field1 LIKE table-field1,



END OF ws_struct.

SELECT SINGLE *

INTO CORRESPONDING FIELDS OF

ws_struct

FROM table


DATA : BEGIN OF ws_struct,




END OF ws_struct.

SELECT SINGLE field1 field2 field3

INTO ws_struct

FROM table




Not recommended use of <INTO CORRESPONDING FIELDS OF…>

Direct storage into a table or a structure, without using the fields.

DATA : BEGIN OF wt_table OCCURS 0,




END OF wt_table.

SELECT *


wt_table

FROM table


APPEND wt_table.

ENDSELECT.

DATA : BEGIN OF wt_table OCCURS 0,




END OF wt_table.

SELECT field1 field2 field3

INTO TABLE wt_table

FROM table


SELECT *


TABLE wt_table FROM table WHERE field1

= „xxxx‟.

SELECT field1 field2 field3

INTO TABLE wt_table

FROM table WHERE field1 = „xxxx‟.


Selection on a single table : <FOR ALL ENTRIES IN>

To use the <FOR ALL ENTRIES IN> option:

The internal table must not be empty.

The recordings must be sorted in order to

delete the duplicates.

The <WHERE> clause must consist of equalities.

If the internal table is empty, the <SELECT> instruction loops on all of the data of the selected

table.

The deletion of the duplicates is compulsory for two reasons:

It enables to accelerate the execution of the <SELECT… FOR ALL ENTRIES> instruction since

the volume of the internal table is smaller.

It avoids some dumps of the programs because of a lack of memory in the table2 table (See the

following example)

If we know that the internal table has duplicates, we have to copy the internal table, sort it and

delete its duplicates.


Selection on a single table : <For all entries>

- test the number of recordings

- sort the recordings

- delete the duplicates

SELECT *

INTO TABLE wt_table1

FROM table1

WHERE field1 IN s_field1.

SELECT *


FROM table2

FOR ALL ENTRIES IN wt_table1

WHERE field1 = wt_table1-field1

AND field2 = „xxxx‟.

Treatment.

SELECT *


FROM table

WHERE field1 IN s_field1.

IF sy-dbcnt NE 0.

SORT wt_table1 BY field1.

DELETE ADJACENT DUPLICATES FROM

wt_table1

COMPARING field1.

SELECT *


FROM table2

FOR ALL ENTRIES IN wt_table1

WHERE field1 = wt_table1-field1

AND field2 = „xxxx‟.

Treatment.

ENDIF.


Selection on many tables : Logical database (LDB)

Advantages :

Directory structure of related tables.

Reusability .

Selection screen .

Performance :

This method is forbidden because in SAP R/3 it is far from being the most performing

method for reading data in the databases.


Selection on many tables : Nested select.

SELECT *

FROM table1

WHERE … .

Treatment.

SELECT *

FROM table2

WHERE table1-field1 = table2-field1 AND … .

Treatment.

ENDSELECT.

Treatment.

Considering the important number of accesses to the database, this method is not

very performing from the point of view of the execution duration. Therefore it is

forbidden to use it.


Selection on many tables : Sub-query

A sub-query solicits the database sever. So, it is not recommended.

SELECT * FROM table

INTO TABLE wt_table

WHERE field IN ( SELECT… FROM … WHERE…).


Selection on many tables : Joins

Principle :

Instead of carrying out the selections in many tables from the database, the join permits to

carry out dynamically in memory only one access to the different tables. The join can be

assimilated to a view but the difference is that the join is not defined in the dictionary.

SELECT mkpf~mblnr mkpf~mjahr mseg~zeile mseg~…


FROM mkpf INNER JOIN mseg ON mseg~mblnr = mkpf~mblnr

AND mseg~mjahr = mkpf~mjahr

WHERE mkpf~… = …

AND mseg~… = ….

Treatment.


Selection on many tables : Joins

Advantage

The developer maintains that he makes only one access because the code can be

interpreted like a <SELECT* FROM table WHERE …… Treatment ENDSELECT>.

This is a lot quicker than the method of nested SELECT because there are fewer

accesses to the database.

Drawback

The system needs a lot of memory space because it dynamically creates a pseudo table

of pointers in order to optimize the different accesses to different tables of the join.

The performance problem comes from the fact that the code generated by SAP is

interpreted by an internal layer at SAP and not by the database server itself.

The inner join can be only used in the case of a 1 to n relation on the key of type header

data <-> item data.

In the other cases, it is forbidden.


Selection on many tables : <For all entries>

* Selection of data at the top

of the table

SELECT * INTO TABLE

wt_mkpf FROM mkpf

WHERE …

AND ….

IF sy-dbcnt NE 0.

SORT wt_mkpf BY mblnr

mjahr.

* Selection of data from the

table lines

SELECT * INTO TABLE

wt_mseg FROM mseg

FOR ALL ENTRIES IN

wt_mkpf

WHERE mblnr =

wt_mkpf-mblnr

AND mjahr = wt_mkpf-

mjahr

AND lgort = wc_lgort.

IF sy-dbcnt NE 0.

SORT wt_mseg BY mblnr mjahr zeile.

* Treatment of the selected data

LOOP AT wt_mseg.

Treatment.

AT NEW mjahr.

CLEAR wt_mkpf.

READ TABLE wt_mkpf WITH KEY mblnr = wt_mseg-mblnr

mjahr = wt_mseg-mjahr

BINARY SEARCH.

Treatment.

ENDAT.

Treatment.

AT END OF mjahr.

Treatment.

ENDAT.

Treatment.

ENDLOOP.

ENDIF.

ENDIF.


<For all entries> : Pros and Cons .

1. It is important to test the number of records returned during the stocking in an internal table

from the first transparent table and to read the second transparent table, only if the internal table

contains at least one record. Indeed, if the test is not done and if the first table is empty, the access

to the second table will provide ALL the records of this table.

2. If there are several identical records, the result given by the clause <for all entries in> will keep

only the first occurrence. To avoid this major inconvenience, it is compulsory to quote the complete

key in the list of fields to be selected.

Advantage :

This reduces the number of accesses to the database not only from the data selection but also

from the data processing in the body of the program.

Drawback :

In some cases we can choose more data than necessary in reality. Furthermore if there are many

tables to stock it will request a large quantity of memory.


Selection on many tables : Views

Principle :

A view is a virtual table which does not have a physical existence and which is composed of

columns belonging to one or many tables. During the first call of the view, the system loads all

the data into a memory table corresponding to the view.

Advantage : There are very few accesses to the database for choosing many

records which are in different tables.

Drawback : If we want to optimize all the programs by this method, it should be

necessary to create at least as many views as that of the programs. But it takes a

lot of memory space. Furthermore, if there are many tables in the view, the relation

between them must point on a key or on an index so that the view may be the most

performing.

Many views have been created by SAP. So we must use them in priority (instead of

using a inner join). We must avoid creating new specific views because of the

memory space.


Using recommendations :

Type of selection on

many tables

Using

recommendat

ions (1=high,

6=low)

Commentary

For all entries 1 Always use it except in the case of a 1 to n

relation. Test if the table is empty, sort the

table and delete duplicates.

Join 2 Use it when there is a 1 to n relation on the

key.

View 3 Use the views created by SAP.

Avoid creating new specifics views.

Sub-query 4 Not recommended.

Nested select 5 Forbidden.

Logical database 6 Forbidden.


Commit and Rollback: Best practices

DELETE FROM y9nav WHERE zznom NE space

OR zzpavillon NE space.

IF sy-subrc NE 0.

ROLLBACK WORK.

EXIT.

ENDIF.

By extension, after each database correction, it is important to keep the database in

a stable statement. To do this, test the return code of the correction instruction to

make a rollback if the sy-subrc is not equal to zero.

It is forbidden to use the <COMMIT> instruction in the case of a program that

updates tables by carrying out many treatments to do it (in User-Exit for example).

It is also forbidden to use the <COMMIT> instruction in loop structure.


Data dictionary: Table creation

Summary of the parameters for a specific table

Question Yes No

Delivery class Do we wish to update the table in

production only by transport?

Delivery class “C” Delivery class

“A”

Does the modification of the table

need obligatory integration tests?

Table maintenance Must the table be manually

modified?

Is it possible to use the SM30/SM31

transaction to maintain it?

Tick “authorized

SM30/SM31” box and

generate the table

maintenance

Specific

program

Data Type Is the table of delivery class “C”? Data type “APPL2” See the

following

question.

Is the table often modified? Data type “APPL1” Data type

“APPL0”

Table category Is the size of the table in production

uncertain?

Choose a category

with a size greater

than those of the

forecast

Key the

corresponding

size category

between 0 and

4.


Data dictionary: Table creation

Summary of the parameters for a specific table

Question Yes No

Buffering Is the table often read by transactions?

Is the table rarely modified ?

It is possible to buffer

the table.

It is forbidden to

buffer the table.

Is the table use buffering?

Is the table small?

Is the number of readings high?

Is the number of writings small?

Complete buffering See the following

question.

Is the table large?

Are few different recordings read?

Individual buffering See the following

question.

Is the table always read with the same

beginning of key (language code,

company, analytical perimeter, country

code…)?

Generic buffering No buffering

Log data

changes

Is the volume of creations/modifications

is small?

Log Data Changes No Log Data

Changes

Is it important to know who and when a

table has been modified?

Is it important to be able to restitute the

table contents at a given date?


Data dictionary: Buffering .

Buffering a table is forbidden in most of the cases. However, in some cases and when a good

optimization is important, we can use it.

The particular case is the following one:

transparent or pool table,

AND access to the table by reading,

AND a lot of queries to the table,

AND access by primary key (or a part of it),

AND few data updating.


Mass treatment – Deletion .

Internal table : If we want to delete many records from an internal table satisfying a condition, it is

recommended to carry out a large suppression instead of a suppression record by record.

Deletion record by record. Large deletion.

LOOP AT wt_table


DELETE wt_table.

ENDLOOP.

DELETE FROM wt_table


Transparent table : The mass deletion is good when we want to delete records from a transparent

table. Instead of erasing the records one by one, it is advised to stock the records for deletion (only

the key fields) in an internal table with the format of the complete key (even <mandt> field) of the

transparent table and afterwards to use the instruction <DELETE table FROM TABLE wt_table>.


Mass treatment – Deletion

Case 1: The comparison in the <WHERE> clause is made with a constant

Deletion record by record. Mass deletion

SELECT *

FROM table

WHERE field1 = wc_const.

IF sy-subrc = 0.

DELETE table.

ENDIF.

ENDSELECT.

DELETE FROM table



Mass treatment – Deletion .

Case 2: The comparison in the <WHERE> clause is made with a variable (a field of wt_table)

Deletion record by record. - Storage of the data for deletion in an internal table.

- Deletion of the data of the transparent table thanks to the

internal table.

LOOP AT wt_table.

SELECT *

FROM table

WHERE field1 = wt_table-field1.

IF sy-subrc = 0.

DELETE table.

ENDIF.

ENDSELECT.

ENDLOOP.

DATA: BEGIN OF wt_table OCCURS 0,

mandt LIKE table-mandt,

key1 LIKE table-key1,

key2 LIKE table-key2,

… (all the keys of the table)

END OF wt_table.

SORT wt_table_tmp BY field1.

DELETE ADJACENT DUPLICATES FROM wt_table_tmp

COMPARING field1.

SELECT mandt key1 key2 … (all the keys)

INTO TABLE wt_table

FROM table

FOR ALL ENTRIES IN wt_table_tmp

WHERE field1 = wt_table_tmp-field1.

IF sy-dbcnt NE 0.

DELETE table FROM TABLE wt_table.

ENDIF.


Mass treatment – Modification.

Correction record by record Mass correction

LOOP AT wt_table


wt_table-field2 = „aaa‟.

wt_table-field3 = „bbb‟.

MODIFY wt_table.

ENDLOOP.

CLEAR wt_table.

wt_table-field2 = „aaa‟.

wt_table-field3 = „bbb‟.

MODIFY wt_table

TRANSPORTING field2 field3

WHERE field1 = ‘xxx’.



Case 1: Use of the <UPDATE> instruction

Modification record by record The <UPDATE> instruction does not

make any check.

SELECT * FROM table

WHERE field3 = wc_const

field1 = wc_const1.

field2 = wc_const2.

MODIFY table.

ENSELECT.

UPDATE table

SET field1 = wc_const1

Field2 = wc_const2


Update Modify

1. Faster.

2. Doesnot make any check before

update .

3. Results into dump if record to be

modified is not found in DB.

1. Slow.

2. Makes a check before update.

3. If record doesnot exist in DB , it will insert a

record .



Case 2: Use of the <MODIFY table FROM TABLE wt_table> instruction

Correction record by record - Storage of the data for correction in an internal

table

- Modifications of the data of the transparent table

thanks to the internal table.

LOOP AT wt_table.

table-field1 = wt_table-field4.

table-field2 = wt_table-field5.

MODIFY table.

ENDLOOP.

LOOP AT wt_table_tmp.

CLEAR wt_table.

wt_table-field1 = wt_table_tmp-field4.

wt_table-field2 = wt_table_tmp-field5.

APPEND wt_table.

ENDLOOP.

DESCRIBE TABLE wt_table.

IF sy-tfill NE 0.


DELETE ADJACENT DUPLICATES FROM

wt_table

COMPARING field1.

MODIFY table FROM TABLE wt_table.

ENDIF.


Mass treatment – Insert.

Internal tables

LOOP AT wt_table1.

MOVE wt_table1 TO wt_table2.

APPEND wt_table2.

ENDLOOP.

APPEND LINES OF wt_table1

TO wt_table2.

The wt_table1 table must have the same structure as the wt_table2 table.

Performance

This method of appending lines of one table to another is about 3 to 4 times faster than

appending them line by line in a loop.


Mass treatment – Insert.

Insertion record by record - Storage of the data for insertion in an

internal table

- Insertion of the data into the transparent

table thanks to the internal table.

LOOP treatment.

table-field1 = … .

table-field2 = … .

INSERT table.

ENDLOOP.

LOOP treatment.

wt_table-field1 = … .

wt_table-field2 = … .

APPEND wt_table.

ENDLOOP.

SORT wt_table BY field1 ….

DELETE ADJACENT DUPLICATES FROM wt_table

COMPARING field1.

INSERT table FROM TABLE wt_table.


Operations on internal tables : Read table binary search

To use the <READ TABLE> instruction:

The <BINARY SEARCH> option is compulsory.

The recordings must be sorted before the reading

The sort must be ascending and on the reading key.

This instruction positions itself on the first record in the table that contains the value.

To carry out a direct reading on an internal table, it is better to make a <READ TABLE

wt_table WITH KEY field1 = wv_field1 BINARY SEARCH> because the data research will

be performed by dichotomy and not sequentially.

The ASCENDING sort on the reading key is compulsory. Otherwise, the <READ TABLE

wt_table WITH KEY field1 = wv_field1 BINARY SEARCH> will give a bad result.

Sequential data research.

Forbidden except in the case of a

small internal table

Binary search – most prefferred

READ TABLE wt_table

WITH KEY field1 = wv_field1.


READ TABLE wt_table

WITH KEY field1 = wv_field1

BINARY SEARCH.


Tips to use the <read table> instruction inside a loop.

<READ TABLE> without

<BINARY SEARCH>

Sort inside a loop.

LOOP AT wt_table1.

(or loop from index, loop where, do…)

Treatment.

READ TABLE wt_table2

WITH KEY key.

IF sy-subrc = 0.

Treatment1.

MODIFY wt_table2

INDEX sy-tabix.

ELSE.

Treatment2.

APPEND wt_table2.

ENDIF.

Treatment.

ENDLOOP.

LOOP AT wt_table1.

(or loop from index, loop where, do…)

Treatment.

SORT wt_table2 BY key.


WITH KEY key BINARY SEARCH.

IF sy-subrc = 0.

Treatment1.

MODIFY wt_table2

INDEX sy-tabix.

ELSE.

Treatment2.

APPEND wt_table2.

ENDIF.

Treatment.

ENDLOOP.


Tips to use the <read table> instruction inside a loop.

A good solution

SORT wt_table2 BY key. (if wt_table2 is not empty)

LOOP AT wt_table1. (or loop from index, loop where, do…)

Treatment.

READ TABLE wt_table2 WITH KEY key BINARY SEARCH.

IF sy-subrc = 0.

Treatment1.

MODIFY wt_table2 INDEX sy-tabix.

ELSE.

Treatment2.

INSERT wt_table2 INDEX sy-tabix.

ENDIF.

Treatment.

ENDLOOP.


Working with internal tables.

Declaration of an internal table:

During the declaration of the internal table the <OCCURS> perimeter must usually be equal to 0 except

if we know the total number of records of the internal table. If this amount multiplied by the record size is

less than 8000, it is advised to take the value of the total number of records.

Loop : Control break statement.

Control breaks The instructions between <AT …> and <ENDAT> are executed only:

AT FIRST In the first pass within the <LOOP>.

AT LAST At the end of the treatment for the last record on the internal table.

AT NEW At the beginning of each control break on the specified zone after the word

<NEW>.

AT END OF At the end of each control break on the specified zone after the word <END

OF>.


Loop : Control break statement.

The tables must be sorted before using <AT NEW> and <AT END OF> instructions.

For SAP, the <AT NEW / AT END OF> instructions are executed only if there is at least a

byte which changes its value between the first byte of the buffer in the table and the last

byte of the specified zone in the <AT NEW/AT END OF>.


Nested loops.

Basic nested LOOP

LOOP AT wt_table1.

LOOP AT wt_table

Treatment.

ENDLOOP.

ENDLOOP.

Nested LOOP with the WHERE clause

LOOP AT wt_table1.

LOOP AT wt_table2

WHERE field = wt_table1-field.

Treatment.

ENDLOOP.

ENDLOOP.


Nested LOOP FROM index with a key-field (Parallel cursor).

Nested LOOP FROM index with one key field

Principle : Donot read the entire second itab .

Remember the last position read .

DATA: BEGIN OF wt_table1 OCCURS 0,

field1 LIKE wt_table1_key,

field4 LIKE table4-field4,


END OF wt_table1.


field1 LIKE wt_table1_key,




END OF wt_table2.



wv_index = 1.

LOOP AT wt_table1.

Treatment.

LOOP AT wt_table2 FROM wv_index.

IF wt_table2-field1 > wt_table1-field1.

wv_index = sy-tabix.

EXIT.

ELSE IF wt_table2-field1 = wt_table1-field1.

Treatment.

ENDIF.

ENDLOOP.

Treatment.

ENDLOOP.

Must condition : Sort on

itab1 and itab2 should be on

same fields .


Nested LOOP FROM index with several key-fields(Parallel cursor). Use1 : ws_struct1 and ws_struct2 form the key for search

and there are unique entries with this combination in itab2.

Nested LOOP FROM index with several key fields .

Principle : Donot read the entire second itab . Remember the last position read . Must

condition : Sort on itab1 and itab2 should be on same fields .

DATA: BEGIN OF wt_table1,

field1 LIKE … ,

field2 LIKE … ,

field3 LIKE … ,

field4 LIKE … ,

field5 LIKE … ,

field6 LIKE … ,

END OF wt_table1.

DATA: BEGIN OF wt_table2,

field1 LIKE … ,

field2 LIKE … ,

field3 LIKE … ,

field4 LIKE … ,

field5 LIKE … ,

field6 LIKE … ,

END OF wt_table2.

SORT wt_table1 BY field2 field4 field6.

SORT wt_table2 BY field2 field4 field6.

wv_index = 1.

LOOP AT wt_table1.

ws_struct1-field1 = field2.







IF ws_struct1 = ws_struct2.

Treatment.

ELSEIF ws_struct2 > ws_struct1.

wv_index = sy-tabix.

Exit.

ENDIF.

ENDLOOP.

ENDLOOP.

DATA: BEGIN OF ws_struct1,

field1 LIKE wt_table1-field2,



END OF ws_struct1.

DATA: BEGIN OF ws_struct2,




END OF ws_struct2.


Nested LOOP FROM index with several key fields.

Use2 : Refering to last slide , ws_struct1 (and ws_struct2) must be the key of the table. But, if several records can

have the same value for the field of the FROM clause, we must write:

Nested LOOP FROM index with several key fields.

Must condition : Sort on itab1 and itab2 should be on same fields .

DATA: BEGIN OF wt_table1_key,




END OF wt_table1_key.

DATA: BEGIN OF wt_table1

OCCURS 0,

tab1_key LIKE wt_table1_key,



END OF wt_table1.

DATA: BEGIN OF wt_table2

OCCURS 0,

tab1_key LIKE wt_table1_key,




END OF wt_table2.

SORT wt_table1 BY tab1_key.

SORT wt_table2 BY tab1_key.

wv_index = 1.

LOOP AT wt_table1.

Treatment.


IF wt_table2-tab1_key = wt_table1-tab1_key.

Treatment.

ELSEIF wt_table2-tab1_key > wt_table1-tab1_key.

wv_index_tmp = sy-tabix.

EXIT.

ENDIF.

ENDLOOP.

AT END OF tab1_key.

wv_index = wv_index_tmp.

ENDAT.

Treatment.

ENDLOOP. The index is here memorized in a

temporary variable. The variable

index is only updated when all the

records having the same value for

the field tab1-tab1_key have been

processed.


Nested LOOP with READ TABLE BINARY SEARCH:

Nested LOOP FROM …

READ TABLE BINARY SEARCH . Use: wt_table1 is not sorted by field1.

SORT wt_table2 BY field.

LOOP AT wt_table1.

Treatment.


WITH KEY field = wt_table1-field1

BINARY SEARCH TRANSPORTING NO FIELDS.

IF sy-subrc = 0.

LOOP AT wt_table2 FROM sy-tabix.

IF wt_table2-field = wt_table1-field1.

Treatment.

ELSE.

EXIT.

ENDIF.

ENDLOOP.

ENDIF.

Treatment.

ENDLOOP.


Nested LOOP with a table of <sorted> Type (only up from 4.0 Release)

This method is similar to the previous one. The wt_table2 table being defined as sorted by field1 and field2

fields, the <LOOP WHERE> instruction is optimized in the same way as the <READ BINARY SEARCH>

method. In this case, the coding is easier to read and SAP generates an error if the table is not correctly

sorted.

Performance Deletions and modifications on a table of type <SORTED> are good in term of

performance (as a <READ TABLE BINARY SEARCH>).

But, insertions are very costly because the new records must be correctly positioned so

that the table remains sorted.

So it is not recommended to use this type of table. It is better to use a standard table

with a <READ TABLE BINARY SEARCH> statement for example.

It is necessary to use the instruction <INSERT TABLE wt_table2> to keep the table

sorted and not to have a duplicate key. Append table can lead to short dump.


LOOP AT wt_table ASSIGNING <fs> (only up from 4.6 Release)

Up from the 4.6 release it is possible to use the <LOOP AT itab ASSIGNING <fs> instruction. In this

case, the field symbol directly points to the line of the table. It is therefore possible to directly modify a

record without copying it in the header line and update it afterwards.

Up from the 4.6 release.






END OF wt_table1.

FIELD-SYMBOLS: <fs_tab1> LIKE wt_table1.

LOOP AT wt_table1 ASSIGNING <fs_tab1>.

<fs_tab1>-field1 = value1.

<fs_tab1>-field2 = value2.

Treatment.

ENDLOOP.

This instruction is more costly than a classical

<LOOP … MODIFY … ENDLOOP> because it

requires a time to maintain the table. This solution

is good to use only if lots of data must be updated

in the table.

The READ instruction has a similar coding: READ

TABLE wt_table … ASSIGNING <fs>.


Comparative study of performance :

Type of loop Performance

(1=high,

7=low)

Commentary

Nested LOOP FROM index

with one key field

1 The execution time is proportional to the

number of records processed. Use: one

field composes the common key of the

tables.

Nested LOOP with several

key fields

2 Use: several fields compose the common

key of the two tables.

Nested LOOP with READ

TABLE BINARY SEARCH

3 Use: A table cannot be sorted.

LOOP … AT NEW … READ

TABLE BINARY SEARCH

4 Use: no common fields to sort the tables.

Nested LOOP WHERE with

SORTED TABLE

5 The table is defined as a sorted table. Not

recommended.

Nested LOOP … WHERE 6 The execution time is exponential to the

number of records processed. Forbidden.

Basic Nested LOOP 7 Forbidden.


Form/ Perform:

The use of <FORM> enables to organize the program to make it more readable, easier to maintain,

with appropriate names easier to understand. The <FORM> instruction permits to add on parameters

during the function call. A parameter is a variable. Therefore the conversion is important. That is why, if

a <FORM> is used and has parameters, it is advised to standardize the different parameters as often

as possible in order to avoid the conversions that are very costly in time for the SAP processor. The

<ANY> type is not a real type.

DATA: wv_var TYPE i.

LOOP AT wt_table.

PERFORM add1 USING wv_var.

ENDLOOP.

FORM add1 USING param.

ADD 1 TO param.

Treatment.

ENDFORM.

DATA: wv_var TYPE i.

LOOP AT wt_table.

PERFORM add1 USING wv_var.

ENDLOOP.

FORM add1 USING param TYPE i.

ADD 1 TO param.

Treatment.

ENDFORM.


Exception in function modules:

Mechanism to handle error situations and discontinue further processing.

-> Define sufficient exceptions in function modules and raise them as needed.

-> In the calling program handle all the exceptions .

->If no exceptions are available in function module , still handle the others exception .

->Exceptions when raised , if not handled in calling program result in short dump .


Special topics:

1. Hashed tables.

2. Buffering.

3. Indexing.

4. PERFORM.

5. Parallel processing.

6. Aggregate functions.


Hashed tables:

Principle :

The access to a hashed table is only made by a unique key thanks to a hashed algorithm.

Advantage :

The time required to read a hashed table is independent of the number of read records. Therefore

hashed tables are very useful for voluminous tables which are often accessed for reading.

Sorting a hashed table is impossible.

The key must be complete when we do a research.

The reading of a hashed table is carried out by the <READ TABLE wt_table WITH

TABLE KEY>.

A hashed table is quick in reading; otherwise there is a not lot of uses.

It is impossible to read/ insert/ modify a record in a hashed table by using an index.

Example DATA wt_table TYPE HASHED TABLE OF ws_struct

WITH UNIQUE KEY key

[INITIAL SIZE n] [WITH HEADER LINE]

The cost of a <SELECT INTO TABLE> is the same with a standard internal table or a

hashed table. But the time for reading a hashed table is less than or equal to the time

required for a standard table.


Buffering :

Buffering : Buffering a table is forbidden in most of the cases. However, in some cases and when a

good optimization is important, we can use it. The particular case is the following one:

pool table,

AND access to the table by reading,

AND a lot of queries to the table,

AND access by primary key (or a part of it),

AND few data updating.

-> Usually customizing tables are buffered. Transparent tables are prone to frequent changes and

master data tables are huge in size to be buffered.

-> Should not be buffered if secondary index exists on the table.

-> Table should not appear in a view if buffering is allowed.


Indexing & Perform:

Indexing : In most of the cases, the creation of an index is not recommended because we must

be very careful. An index can be created when there is no more solution. Each creation must be

studied individually.

PERFORM : The use of <PERFORM> is very important for the program structure. But it is costly.

Therefore, if there are big performance problems, it is advised to avoid using <PERFORM>. In

general PERFORM increases readability of source code and is good to use.


Parallel processing :

Concept Call function STARTING NEW TASK DESTINATION IN GROUP allocates the

processing to a new Dialog task.

So the entire data processing can be split into different dialog tasks .

Messages received back from task could be processed via a subroutine in calling

program.

Advantages Faster processing compared to serial processing as it uses asynchronous processing .

Disadvantages As the processing happens in a dialog work process which has a auto logout time

limitation.

Will cause problem if there is a dependency between the data which is processed in two

different dialog tasks.

Prerequisites FM should be RFC enabled.

The calling program should not change to a new internal session after making an

asynchronous RFC call. That is, you should not use SUBMIT or CALL TRANSACTION

in such a report after using CALL FUNCTION STARTING NEW TASK.

Server must have atleast 3 dialog work processes. Dispatcher queue less than 10%

full, at least one dialog work process free for processing tasks from the parallel job.


Parallel processing : Example

data: functioncall1(1) type c,

cstgdetail1 type bapicustomer_kna1.

constants: done(1) type c value 'X'.

start-of-selection.

call function

'BAPI_CUSTOMER_GETDETAIL2'

starting new task 'FUNC1'

destination 'NONE'

performing set_function1_done on

end of task

exporting

customerno = p_kunnr.

*Receive remaining asynchronous replies

wait until functioncall1 = done.

write:/ cstgdetail1.

****************************************************

****

* FORM FUNCTION1_DONE

****************************************************

****

form set_function1_done using taskname.

receive results from function

'BAPI_CUSTOMER_GETDETAIL2'

importing

customergeneraldetail = cstgdetail1.

functioncall1 = done.

endform.


Aggregate functions: SUM , AVG , COUNT , MIN , MAX

To be avoided when data records that are worked upon in aggregate functions are big

in number.

Can be used in aggregate functions involving small number of data records .

Advantage Data fetched from database to ABAP layer is less .

Aggregation is done on Database level. So no further treatment is necessary on ABAP

layer. Reduces coding effort .

Disadvantage Reduces performance as aggregation is done at database level.


Tools available to validate source code: SLIN

Extended syntax check : Tcode – SLIN

Does advanced syntax check and lists out all potential coding errors that can lead to runtime breakage of

program


Tools available to validate source code: SLIN


Tools available to validate source code: SCII

Code Inspector : Tcode – SCII

Code inspector lists potential flaws in the program that can affect the performance of the program. Naming

conventions used for objects can be checked against standards. You can create your own project specific

variants or can use a temporary definition .


Tools available to validate source code: SCII


Tools available to measure performance :

Run time analysis : SE30 (ABAP V/S Database)


Run time analysis : SE30 ( Costly database statements ).


SQL trace tool : ST05 .


SQL trace tool : ST05


ABAP performance and best practices .

- The End.

abap performance and best practices a bible v1 0

Documents