General Programming Guidelines for BAPIs

Use

To ensure that BAPIs, as interfaces of SAP business object types, provide access to R/3 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.

Guidelines Specific to BAPIs

In addition to the general guidelines, you should follow the specific guidelines for programming BAPIs:

Programming Standardized BAPIs

Using BAPIs in Distributed Systems (ALE)

 

General Recommendations

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

Improving Performance

 

Mandatory Rules

You must follow these rules for all BAPIs:

General Mandatory Rules

For Further Information See:

BAPIs must not invoke COMMIT WORK commands.

Transaction Model for Developing BAPIs

BAPIs must not contain the following commands:

  • CALL TRANSACTION
  • SUBMIT REPORT
  • SUBMIT REPORT AND RETURN

Transaction Model for Developing BAPIs

INCLUDE structures must not be used in BAPI structures.

Specifying Development Objects in the Dictionary

Database changes can only be made through updates.

Transaction Model for BAPIs Without Commit

The global memory must not be used to transfer values.

Transaction Model for Developing BAPIs

Due to transparency it is strongly recommended not to use Set and Get.

Transaction Model for Developing BAPIs

If required every BAPI must be able to carry out its own authorization checks.

  

Values relevant for Customizing are not allowed to be changed.

Programming Create() BAPIs and Programming Change() BAPIs

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.

Return Parameters (Reporting Errors)

 

Fields and Parameters

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.

Programming Standardized Parameters

Each BAPI must have a return parameter for returning messages to the calling application.

Return Parameters (Reporting Errors)

All field and parameter names must be in English

Naming Parameters in the Function Module

Specifying Development Objects in the Dictionary

All quantity and amount fields must be assigned quantity unit fields.
All currency amount fields must be assigned currency IDs.

Internal and External Data Formats

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

Providing Input Help (F4 Help)

 

Data conversion

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

Internal and External Data Formats

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".

Internal and External Data Formats

Documentation

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. « <0}
  • 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.

Providing Interface Descriptions

The documentation must be checked for completeness and comprehensibility.