Purpose
BAPI developers must first supply the ExtensionIn and/or ExtensionOut parameters in the BAPI interface, as well as up to two customer exits in the BAPI function module, according to the requirements of the specific BAPI. This allows the customers to implement all three types of enhancement with this BAPI.
Developers can also support customers further by anticipating which SAP database tables might sensibly be appended with customer fields, and which existing fields from other tables might be included in the BAPI.
Process Flow
The example below explains which actions a BAPI developer would have to perform for a specific case. In this example, we will design an extendable BAPI TravelAgency.CreateFromData and provide for specific enhancements to database table STRAVELAG.
We can divide our activities into the following five steps:
|
The naming convention for the extension parameter is ExtensionIn for import parameter enhancements and ExtensionOut for export parameter enhancements. | |
|
The extension parameters must be defined as table parameters. | |
|
The extension parameters are always based on reference structure BAPIPAREX. | |
|
All the BAPI table extensions used in the BAPI and their assignment to the respective BAPI parameters must be described in the documentation of the extension parameter. |
The section
|
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. | ||
|
Create one BAPI table extension for each table to be extended. 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. | ||
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 table extensions would be called BAPI_TE_STRAVELAG1, BAPI_TE_STRAVELAG2, and so on. | ||
|
The structure of the BAPI table extension must contain all the identified key fields of the table to which the BAPI table extension relates. The table extension does not contain any other fields except the key fields. |
FUNCTION BAPI_ERWEITERUNG_TEST
<program text>
<CUSTOMER_EXIT_1>
<program text>
<read ExtensionIn>
<program text>
<CUSTOMER_EXIT_2>
<program text>
END FUNCTION
Therefore, in the most complex case, BAPI developers must allow customer enhancement to their function modules in three places:
|
All BAPI import parameters and tables are passed on as an import. In particular, the ExtensionIn parameter must be available in the exit. | ||
|
The exit should return the Return parameter as an export, to allow the BAPI to report any errors that occurred in the exit. | ||
|
If required by the application, additional parameters can also be passed on to the exit as import or export. |
a) |
The container format is first converted to the required temporary structure by the corresponding BAPI table extension. Because the values have the same sequence in both the container and the BAPI table extension, this can be implemented with a single MOVE command. | ||
b) |
This structure is then used to fill the additional database fields with MOVE-CORRESPONDING. To do this, the corresponding key value must be used to determine the line in the database where the values will be inserted. |
The entire process can be described in pseudo-coding as follows:
LOOP at ExtensionIn | ||||
IF required table extension exists in ExtensionIn | ||||
THEN MOVE values from ExtensionIn TO table extension END. | ||||
Find correct line in database table. | ||||
END LOOP |
Therefore the table enhancements can only be filled automatically when the fields the customer added to the BAPI table extension correspond exactly with the fields of the extended table, as the MOVE-CORRESPONDING command only works in this case.
Our concrete example results in the following coding:
loop at extensionin. | ||||||
case extensionin-structure. | ||||||
when 'BAPI_TE_STRAVELAG'. | ||||||
move extensionin+c_lenstruc to wa_bapi_te_stravelag. | ||||||
move-corresponding wa_bapi_te_stravelag to t_stravelag. | ||||||
endcatch. |
Exception: |
In the case of Create() BAPIs with internal number assignment, the value of the key is not yet know when the BAPI is called, and therefore cannot be included in the container. As a consequence, the key value generated in the BAPI must be explicitly assigned to the table extension after the container has been extracted. In this case, we would modify the above example as follows: |
loop at extensionin. | ||||||
case extensionin-structure. | ||||||
when 'BAPI_TE_STRAVELAG'. | ||||||
move extensionin+c_lenstruc to wa_bapi_te_stravelag. move agencynumber to wa_bapi_te_stravelag-agencynum. read table t_stravelag with key agencynum = agencynumber. catch system-exceptions conversion_errors = 1. | ||||||
move-corresponding wa_bapi_te_stravelag to t_stravelag. | ||||||
endcatch. |
|
The exit is given all BAPI import parameters, including ExtensionIn, as an import. Table parameters in the BAPI function module remain as tables in the customer exit. | ||
|
The exit should return ExtensionOut and the Return parameter as an export. | ||
|
If required by the application, additional parameters can also be passed on to the exit as import or export. |
The section
A detailed programming example for implementing a BAPI module is available under Examples.