Implementing the BAPI


A BAPI method should only be implemented as an asynchronous interface if at least of the following conditions is satisfied:

  • Database changes are consistent in all systems
    Data must be updated consistently in both the local and remote systems.
  • Looser coupling
    With a synchronous interface, the coupling between the client and the server system is too narrow. If the connection is interrupted the client system would not be able to function properly.
  • Performance load
    The interface is frequently used or the interface handles large volumes of data. In this situation a synchronous interface cannot be used because performance would be too low.

If no suitable BAPI is available in the SAP System, you can implement your own BAPI. IBUs, partners, and customers can also modify the BAPIs supplied by SAP. For information on modifying BAPIs, please see Customer Enhancement and Modification of BAPIs.


For more information about implementing BAPIs, see the BAPI Programming Guide. IBUs, partners, and customers have to develop their BAPIs in their own namespace and follow certain guidelines that are defined in the BAPI Programming Guide.

If you implement a BAPI as an asynchronous interface, keep the following information in mind in addition to following the standard programming BAPI guidelines:

  • The BAPI must not issue a COMMIT WORK command.
  • The BAPI return parameter must use reference structure BAPIRET2.
  • All BAPI export parameters with the exception of the return parameter are ignored and are not included in the IDoc that is generated.
  • After the function module which converts the IDoc into the corresponding BAPI call in the receiving system has been called, status records are written for the IDoc in which messages sent in the return parameter are logged.

If, in at least one of the entries of return parameter, the Type field in the return parameter is filled with A (abort) or E (error), this means:

    • Type A:
      Status 51 (error, application document not posted) is written for all status records, after a ROLLBACK WORK has been executed.
    • Type E:
      Status 51 (error, application document not posted) is written for all status records and a COMMIT WORK is executed.

Otherwise status 53 (application document posted) is written and a COMMIT WORK executed.