Improving Performance (SAP Library)

Improving Performance

Use

In order to improve the performance of your BAPI, you should follow the standard ABAP programming guidelines:

Use only complete WHERE conditions to minimize the amount of data to be transferred.
Avoid unnecessary database access.
Do use of arrays.
Buffer data, for example in the local memory of the function module. Note that you must not buffer data in the global memory.
The locking granularity must correspond to the instance granularity in the object model.
Do not generate programs at runtime.

See the internal SAPnet for further notes about effective programming in the R/3 environment.

Additional Guidelines for BAPI Programming

The function module on which a BAPI is based can be accessed by external programs using RFC. For this reason, you should follow these additional guidelines when programming BAPIs:

Large amounts of data

Mass data is treated differently in ABAP programs, which use the SAPgui (graphical user interface) as a front end, and in programs developed on external development platforms such as Visual Basic.

If large amounts of data are read in the R/3 System, for example a list containing many entries, the majority of the data remains on the application server. Only the data that is actually displayed is sent to the front end. In contrast, if you are programming with Visual Basic, all the data will be sent from the application server to the client system. This increases the load on the network and the amount of memory required in the client system.

You need to cover the situation when your BAPI has to read mass data. For example, you could specify a limit so that only the first n data records are read. Alternatively your BAPI could return a message to the calling program indicating that the amount of data has exceeded a certain limit and that a new selection should be made.

Do not define parallel processes.
If no COMMIT WORK is triggered after a BAPI is called, a lock that has been set has to be explicitly deleted.
To reduce the duration of database locks, you should not assign numbers to them individually. Instead make use of the buffers. Read the numbers to a buffer and assign the numbers directly from the buffer.
Lock periods can be minimized by making database updates as close as possible to the COMMIT WORK command. This reduces the duration of database locks and the risk of blocking other processes.
The less specific the (partial) key of a modified data record is, the more likely it is that the data record will be accessed by multiple BAPIs, causing the record to be locked. For example, running a statistic on plant level will have a negative impact on the performance of the BAPI, whereas a statistic based on plant and material will cause fewer locks because it will apply to fewer BAPIs.
Minimize the use of read transactions which depend on a previous database COMMIT (committed read). These read transactions have to wait for the COMMIT WORK command of the update transaction to be processed.
All tables that are not protected by SAP internal locks must always be updated in the same order to prevent a deadlock.