Implementing the Function Module

Use

When programming the function module a range of BAPI-specific requirements must be met.

Transaction Model Requirements

  • 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.

Requirements of the Remote Capability of BAPIs

  • 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.

Error Handling Requirements

  • 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. A relevant message (message type A, termination message) can only be returned in the return parameter. It is not permitted in the program to display messages of type E (error message) and A (termination message) directly.

  • 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.

Performance Requirements

  • 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.

  • 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.