In this example, a customer wants to use BAPI TravelAgency.CreateFromData. This BAPI is based on database table STRAVELAG, to which the customer wants to add three fields compared to the version supplied by SAP.
The Extended Database Table
To extend the database table supplied by SAP, the customer first creates a data structure that contains the customer-specific fields. In our example, this is structure TRAVELAG, with the three fields PLANETYPE, COMPANY, and SEATSMAX.
This structure is included in both the database table and the BAPI table extension. This ensures that the enhancements to the database table and in the table extension are always identical.
The database table is extended by adding an APPEND structure that contains an INCLUDE with the data structure of the customer-specific fields. We use an APPEND structure to ensure that the enhancements always appear at the end of the table.
The diagram below shows the extended table.
The BAPI Table Extension
As mentioned above, BAPI table extensions are help structures that allow the customer enhancement of BAPIs. They must exist for every SAP database table that is to be used in the customer enhancement concept. These BAPI table extensions are used during the data import to copy the customer enhancements from the container (ExtensionIn) to the BAPI interface, and to fill the additional fields of the database table. During data export, the BAPI table extensions are used to copy data from a customer table extension and to place it in the ExtensionOut parameter. Places where BAPI table extensions are used and how their use must be implemented in detail are described in
Actions by the BAPI Developer.BAPI table extensions are created as data structures in the ABAP Dictionary with transaction SE11. They generally consist of the following components:

When a customer creates a BAPI table extension, he/she must define both the key part and the data part.
The following guidelines have to be observed when working with BAPI table extensions:
|
Exception: |
If a BAPI has two or more parameters that refer to the same database table, then a separate BAPI table extension is created for each of these BAPI parameters. The naming convention in this case is BAPI_TE<table_name><consecutive_number>. In our example, the BAPI table extensions would be called BAPI_TE_STRAVELAG1, BAPI_TE_STRAVELAG2, and so on. |
If customers want to extend a table that does not have a table extension defined by SAP, they will have to define their own table extensions.
The following diagram shows how the BAPI table extension has to look in our example. The important thing is that the INCLUDE structure contained in the APPEND is the same one used to extend the database table. In this case, this is structure TRAVELAG with the fields PLANETYPE, COMPANY, and SEATSMAX.
Extension Parameters and BAPIs
The two extension parameters (ExtensionIn and ExtensionOut) in the BAPI interface are used to pass on the enhancements to the BAPI function module or forward them from the function module to the calling program in container format.
The extension parameters are always based on data structure BAPIPAREX. It determines the format of the data records used to pass the enhancements back and forth between the BAPI and the calling program.
The diagram below shows the BAPIPAREX structure.
The individual fields have the following purpose:
|
Exception: |
It is not possible to pass on the key value(s) in Create() BAPIs with internal number assignment, as these values are generated in the BAPI itself. For information on how to proceed in the case of Create() BAPIs, refer to Actions for Enhancements Based on Existing Database Tables. |
Therefore, the VALUEPART1 through VALUEPART4 fields contain both the key value(s) that identify the table line and the data fields to be inserted into the table. The assignment of key values and data to VALUEPART1 through VALUEPART4 is performed by consecutively filling the VALUEPART fields. VALUEPART1 first saves all the key fields of a data record. If VALUEPART1 still has capacity, then the value of the first customer-specific table field is also saved in VALUEPART1. This is continued with the further table fields until the capacity of VALUEPART1 is exhausted. The process is continued with VALUEPART2 through VALUEPART4, until all the values in the data record have been included in the container.
In situations where the remaining capacity of VALUEPART1 (for example) is less than the maximum length of the next table field to add, then the value of this table field is split between VALUEPART1 and VALUEPART2. As much of the value as fits is saved in VALUEPART 1, and the rest is allocated to VALUEPART2.
The advantage of this type of container structure is that the container data record can be converted to the table extension format with a single MOVE command in the BAPI.
Continuing the above example, the extension container could look like this:
The values "BOEING747", "LUFTHANSA", and "456 SEATS" in the first data record would be written to the additional fields of database table STRAVELAG specified in BAPI_TE_STRAVELAG . The table line in which the values will be inserted is identified by key "4711".
The check and further processing of the data from the import container and the filling of the export container take place subsequently, in customer exits supplied by the BAPI developer.