Appending Customer Fields

In this example, a customer wants to use BAPI TravelAgency.CreateFromData. This BAPI is based on database table STRAVELAG, and the customer wants to add three fields 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 to use them exactly 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:

  • A key part predefined by SAP. This is/are the key field(s) of the database table to which the BAPI table extension refers. Accordingly, SAP supplies BAPI table extensions that only have a key part, and do not have a data part.
  • A data part that the customer determines through the APPEND technique and which contains the additional fields. If customers want to add additional table fields to the SAP table, these table fields are inserted in the APPEND as an INCLUDE. Therefore, the customer subsequently adds the data part to the "initial" table extension supplied by SAP.

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:

  • The naming convention for BAPI table extensions is BAPI_TE_<table_name>. If you cannot follow this naming convention due to the length restriction for structure names, then you must specify this explicitly in the documentation of the table extension and the BAPI.
  • A separate BAPI table extension must be created for every database table that the BAPI developer thinks could be enhanced. Please note, however, that each table can only have one table extension. Therefore, if several BAPIs use the same table, they will have to share the table extension.


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 structure of the BAPI table extension must contain all the identified fields (key fields) of the table to which the BAPI table extension relates. This is the only way to determine which line of the extended database table will save the extensions in the BAPI.
  • The data structure that is included in the APPEND must be the same one used for the extension of the database. This is the only way to make sure that the additional table fields are filled automatically.
  • Customers can use only fields of data type CHAR and similar data types in BAPI table extensions. This restriction is due to the reference structure BAPIPAREX of the extension parameters. Customers cannot use fields from the standard table in the APPEND of the BAPI table extension because a 'move corresponding' would overwrite the SAP field.
  • The data part of a BAPI table extension can have a maximum length of 960 characters.

The following diagram shows how the BAPI table extension has to look in our example. For the data part it is important 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:

    The STRUCTURE field contains the name of the BAPI table extension to which the respective data record refers. In turn, because a table extension is allocated to exactly one database table, the program can determine the extended table in which to save the data record.
    Each data record of the extension container contains – in addition to the name of the table extension – the key values and the values that will be inserted in the additional table fields. The key values have to be passed on in order to determine the line in the database table where the data in the data record will be written.


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 more information on how to proceed in the case of Create() BAPIs, see 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 (length 240) 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. The rest is then assigned 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 BAdIs supplied by the BAPI developer.