!--a11y-->
General Programming Guidelines for BAPIsTo ensure that BAPIs, as interfaces of SAP business object types, provide access to SAP data and processes in a consistent way, you must follow certain rules when programming BAPIs. This section contains general information and guidelines on programming BAPIs.
It is difficult to formalize the contents and functional scope of a BAPI. Every BAPI has a different functional content, even those that perform similar functions, for example, the standardized BAPIs. The differences are mainly due to the different characteristics of SAP business object types and their contents.
In addition to the general guidelines, you should follow the specific guidelines for programming BAPIs:
Programming
Standardized BAPIs
Using BAPIs in Distributed Systems (ALE)
Keep in mind the following recommendations when developing your BAPI:
Recommendation |
For Further Information See: |
Minimize interface complexity. Supply the BAPI with the minimum of data and group the data from a business perspective. |
|
Structure your BAPI in the most efficient way |
You must follow these rules for all BAPIs:
General Mandatory Rules |
For Further Information See: |
BAPIs must not invoke COMMIT WORK commands. |
|
BAPIs must not contain the following commands: · CALL TRANSACTION · SUBMIT REPORT · SUBMIT REPORT AND RETURN |
|
INCLUDE structures must not be used in BAPI structures. |
|
Database changes can only be made through updates. |
|
The global memory must not be used to transfer values. |
|
Due to transparency it is strongly recommended not to use Set and Get. |
|
If required every BAPI must be able to carry out its own authorization checks. |
|
Values relevant for Customizing are not allowed to be changed. |
|
Language-dependent values cannot be used as interface parameters. |
|
BAPIs must not produce any screen output. This means that lists, queries and dialog boxes must not be returned to the calling program. This is true for the BAPI itself and for any function module that may be indirectly called by the BAPI. BAPIs must not cause program terminations, they can only return a message (type A: termination message) in the return parameter. Messages of type E (error) and A (termination) cannot be output in the program. |
You must follow these rules for BAPI fields and parameters:
Mandatory Rules for Fields and Parameters |
For Further Information See: |
Standardized parameters must be implemented consistently. |
|
Each BAPI must have a return parameter for returning messages to the calling application. |
|
All field and parameter names must be in English |
|
All quantity and
amount fields must be assigned quantity unit fields. |
|
All key fields in GetDetail() and GetList() BAPIs must be displayed as text fields. |
|
Whenever possible, F4 input help for fields in BAPI parameters must be made available |
You must follow these rules for data conversions:
Mandatory Rules for Data Conversion |
For Further Information See: |
Only the internal data format can be used in BAPIs Except for: · Currency amount fields · Quantity fields · ISO codes · Fields that have an internal key · Specific fields in address structures |
|
You must always use a period for the decimal point |
|
Currency amounts with decimal points must be formatted with a decimal point in the interface. For example, the value "10.12" must be formatted as "10.12" and not as "1012". |
You must follow these rules for the documentation:
Mandatory Rules for Documentation |
For Further Information See: |
The business object type must be documented |
Business object type documentation is stored in the Business Object Repository. SAP information developers must follow the latest business object type documentation guidelines. You can get these from your contact person in BAPI development. |
The business object must be documented All interface parameters must be documented. Note the following guidelines: · BAPIs with buffering must be identified as such. · In the case of exceptions: If the BAPI contains a COMMIT WORK command; this must be documented. · The documentation on return parameters must describe all possible return values and messages. · If, for termination messages, a database rollback is executed in the return parameter, this must be explained in the documentation on the return parameter. · Documentation on mandatory parameters must specify which fields must be filled. · All mandatory fields in a parameter must be documented as mandatory parameters. · All available BAPI table extensions must be listed in the documentation on the extension parameter. |
The documentation on the BAPI and the interface parameters is created in the Function Builder for the function module that the BAPI is based on. SAP information developers must follow the latest BAPI documentation guidelines. You can get these from your contact person in BAPI development. |
Data element documentation must be written for all the fields in BAPI parameters. |
|
The documentation must be checked for completeness and comprehensibility. |
|