Defining the Interface 

A BAPI parameter must be defined in the method of the business object type in the BOR as well as in the function module. In both cases the definition must be identical except for the key fields of the business object type.
The key fields of a business object type are used to identify a business object type at a semantic and technical level. The whole key, rather than parts of it is always used (fully defined key). This has semantic reasons (an instance is identified by the key) as well as technical reasons (keys are generated in the BOR and various checks are made against existing key fields).

If a BAPI refers to a specific instance of a business object type, together with other parameters, the key fields of the business object type are transferred to the method in the BOR to identify the instance. In this case the key fields are not listed again under the method parameters in the BOR. This distinction cannot be made in the function module, which is why the key fields must be listed here as parameters.

The following conventions apply to key fields for function module interfaces:

	With instance methods all the BOR key fields are mandatory import parameters in the function module. BOR key fields must not be defined as export parameters in the function module.
	With class methods BOR key fields must not be defined as export parameters in the function module (exception: Create methods) Neither are BOR key fields allowed to be defined as import parameters in the function module.
	With create methods all the BOR key fields of the method are defined as export parameters in the function module. BOR key fields must not be defined as import parameters in the function module (this applies to all class methods). Create methods are classified as instance-independent in the BOR.

If, in accordance with the above guidelines, key fields are defined as parameters in the function module, the conventions below apply:

	The fully defined key is used and not a partial key.
	There is a parameter in the function module for each key field of the business object type. For the function module BAPI_FLIGHT_GETDETAIL (for the instance method Flight.GetDetail), AIRLINEID, CONNECTIONID, and FLIGHTDATE are defined as import parameters and implement the same key fields of the business object Flight.
	The parameter in the function module and the BOR key field have the same name.

In the above explanation a key field means a parameter that is used to identify a runtime instance (in the OO sense) and that has the same name as the key field of the business object type. It is of course possible to use other parameters to display the required business information represented by the key.

The BAPI CreateFromData for the business object type FlightBooking (flight booking: key AirlineID, BookingNumber) must not contain any AIRLINEID or BOOKINGNUMBER import parameters, in accordance with the guidelines above. Instead, the airline ID for the flight booking is transferred as the AIRLINEID field in the parameter BookingData.

 

Function module interfaces must also satisfy the conventions below:

	The structure BAPIPAREX must be used for the parameters ExtensionIn and ExtensionOut.
	The return parameter is based on the structure BAPIRET2.
	The function module must be RFC-enabled.
	Underscores ("_") are not allowed in parameter names in the BOR. The individual components of a parameter name in the BOR are identified by the use of upper and lower case. In the Function Builder, only upper case is allowed. This means that underscores ("_") in parameter names are permitted here and we recommend that you use them to separate words (example: parameter name in the BOR: ExtensionIn; in the Function Builder: EXTENSION_IN).