Using BAPIs in Distributed Systems (ALE)


Since Release 3.0 ALE (Application Link Enabling) technology has enabled data to be exchanged between individual distributed SAP Systems and non-SAP systems.

BAPI Development Even if one of the systems fails, or a communications link is interrupted, the remaining systems must be able to continue to function. Loose coupling means that the individual systems for the most part communicate asynchronously, (with a time delay) with each other. For these reasons messaging is used for data communication between the participating systems in ALE distribution scenarios.

As of Release 4.0 you can implement an asynchronous BAPI interface by generating an ALE IDoc interface for the BAPI and using it in an appropriate ALE distribution scenario.

For further information on ALE technology and using BAPIs in the context of ALE, see ALE Programming Guide. This section provides a general overview of points you should keep in mind when implementing a BAPI to exchange data asynchronously.

Process Flow

When you use BAPIs for asynchronous messaging, the application in the sending system calls the generated ALE IDoc interface instead of the BAPI. The ALE IDoc interface performs the following tasks:

  • Creates an IDoc from the BAPI data
  • Sends the IDoc to the target system
  • Receives the IDoc in the target system, creates the BAPI data from the IDoc and calls the BAPI

You can use Transaction BDBG to create the additional objects required for the BAPI in this process, that is, the associated IDoc and the required function modules. This transaction is described in detail in the ALE Programming Guide.


Before you can implement a BAPI used to transfer data asynchronously in ALE, make sure that a BAPI of this type is actually required for the task in hand. If at least one of the conditions below applies, you should implement your BAPI as an asynchronous interface:

  • Consistent database changes in several systems

Data must be updated consistently on both the local system and on the remote system.

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

The interface has a large volume of data or database operations to be carried on the server system will take a long time. In this situation a synchronous interface cannot be used because performance would be too low.

Additional Guidelines

If you are sure you want to implement your BAPI as an asynchronous interface you should keep in mind the following points in addition to the general BAPI programming guidelines:

  • The BAPI must not issue a COMMIT WORK command.
  • The BAPI return parameter must use the 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 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 the field type is filled with E (error) or A (abort) in at least one of the transferred return parameter entries, the status 51 (application document has not been posted) is assigned to all the status records of the IDoc after a ROLLBACK WORK has been executed. If the field type is filled with E (error) in at least one of the transferred return parameter entries, the status 51 (error, application document has not been posted) is assigned to all the status records of the IDoc and a COMMIT WORK is executed. Otherwise status 53 (application document posted) is written and a COMMIT WORK executed.