Implementing the BAPI

Prerequisites

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 fails the client system can no longer operate properly.

  • Performance load The interface is frequently used or the interface handles large volumes of data. A synchronous interface cannot be used in this situation 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, see Customer Enhancement and Modification of BAPIs.

Procedure

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 ROLLBACK WORK is executed.

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