As of Release 4.0 BAPIs must not execute 'COMMIT WORK' commands.

Reason: The caller should have control of the transaction. Several BAPIs should be able to be combined within one LUW. For more information see Transaction Model for Developing BAPIs.

The following commands must not be used:

·         CALL TRANSACTION

·         SUBMIT REPORT

·         SUBMIT REPORT AND RETURN

Database changes can only be made through updates.

Reason: The RFC executes an implicit database commit.

The global memory must not be used to transfer values.

Reason: This should avoid any side effects and support the encapsulation of the functionality.

If a COMMIT WORK is not executed after a BAPI has been called, you have to delete the lock that has been set.

All tables that are not protected by SAP internal locks must always be updated in the same order to prevent a deadlock.

BAPIs must not produce any screen output. This means that lists, queries and dialog boxes must not be created. This is true for the BAPI itself and for all function modules that may be indirectly called by the BAPI.

Reason: An external client cannot respond to output on the screen. In the worst possible case, the connection in the client program could be broken.

If required every BAPI must be able to carry out its own authorization checks. Input help in particular should contain authorization checks.

The S_FLBOOK authorization object (activity 03, display) is checked in the BAPI function module BAPI_FLBOOKING_GETLIST (FlightBooking.GetList method, determine list of flight bookings). The S_FLBOOK authorization object (activity 01, create) is checked in the BAPI function module BAPI_FLBOOKING_CREATEFROMDATA (FlightBooking.CreateFromData method, create flight booking).

No exceptions are used in BAPIs. Instead all error messages are reported back to the calling program in the standardized parameter return.

BAPIs must not cause the program to terminate. An abort message (message type A) can be reported back only in the return parameter Messages of type E (error) and A (abort) cannot be output in the program.

Error handling plays a more important role here than it does with normal function modules:

The meaning of error numbers that are used must not be changed.

Error messages must be able to be understood by users in external applications. For example, they should not contain table names.

The error message must specify whether the cause of the error is business (content) related or due to missing import data.

Example of an inappropriate error message: "Required entry field not filled". The error message must specify which mandatory fields have not been filled.

Example of an appropriate error message: See documentation about the Return parameter in the FlightBooking.GetList method. The error message "Airline &1 unknown" (BC_IBF 050) specifies exactly which field was not transferred correctly when the method was called.

The BAPI must perform well. The following guidelines should be followed:

·         Use only complete WHERE conditions to minimize the amount of data to be transferred.

·         Avoid unnecessary database access.

·         Do use ARRAYs.

·         The locking granularity must correspond to the instance granularity in the object model.

·         Do not generate programs at runtime.

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

Handling Large Data Volumes

Mass data is treated differently in ABAP programs, which use the SAPGUI as a front end, and in programs developed on external development platforms such as Visual Basic.
If large volumes of data are read in the SAP 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.

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 updating the database 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.

Write-enabled BAPI methods must make all the necessary consistency checks to ensure that the modified or newly created instance is consistent.

In particular, the methods need to check whether the date is correct. The function module DATE_CHECK_PLAUSIBILITY can be used to do this.

You must carry out a refresh for tables for which no input is expected.

Do not use get and set parameters.

Reason: This should avoid any side effects and support the encapsulation of the functionality.

BAPIs should be independent from Customizing settings. In particular, values relevant for Customizing are not allowed to be changed.

As part of the customer enhancement concept, Business Add-Ins (BAdIs) have to be included so that customers can enhance BAPI functions:

Each BAPI function module must contain two extra BAdIs in addition to the exits provided by the application.
The first BAdI must enable customers to check all the data that is transferred to the BAPI. In particular, check the content of the ExtensionIn parameter before it is written to the table extensions.
The second BAdI is provided so that the customer can make enhancements (e.g. writing additional tables). If the customer has enhanced the export parameter of the BAPI, the second BAdI should be used to fill the ExtensionOut parameter.

See also: Customer Enhancement of BAPIs.

See also: Business Add-Ins.