Show TOC

Special Handling for API MethodsLocate this document in the navigation structure

BOR methods that are flagged as API methods are used for IDoc processing. The corresponding BAPIs are adapted to the extended field length by adding new parameters. In particular, if key fields or logical key fields are affected, it is required that you explicitly declare the new parameters that refer to the object key.

You can flag BOR methods as API methods in order to provide them as wrappers for BAPI function modules. These function modules contain parameters that refer to:

  • method parameters,
  • object key fields provided that it has not been converted into a technical key, or
  • logical key fields if the object key has been converted into a technical key.

In contrast to the key fields that can be changed incompatibly, new parameters have to be created as BAPI methods instead. As a consequence, it is no longer clear which parameters correspond to the (logical) key fields. It is therefore necessary that you specify this relationship in the object type definition.

Example

The following example illustrates the situation where the key of an object type is replaced by a technical key after the field extension:

The BUS1017 object type has the following key definition:

begin of key,
	material         like ebew-matnr,
	valuationarea    like ebew-bwkey,
	valuationtype    like ebew-bwtar,
	sddocumentnumber like ebew-vbeln,
	sddocumentitem   like ebew-posnr,
end of key.

The PRICECHANGE method has the following parameters:

Parameter Name

Type

PriceDate

importing

PriceChangeDocument

exporting

Prices

importing

Return

exporting

materialEVG

importing

In systems without the extension of the material number length to 40 characters, the BAPI is invoked in the implementation of the method in the following way:

call function 'bapi_salesordstck_price_change'
  exporting
    material            = object-key-material
    valuationarea       = object-key-valuationarea
    valuationtype       = object-key-valuationtype
    sddocumentnumber    = object-key-sddocumentnumber
    sddocumentitem      = object-key-sddocumentitem
    pricedate           = pricedate
    material_evg        = materialevg
  importing
    pricechangedocument = pricechangedocument
  tables
    prices              = prices
    return              = return
  exceptions
    others              = 01.

The first five parameters are supplied by the object key, and the others are taken from the method container. Note that the first five parameter names are identical to the names of the key fields. This is necessary in the context of IDocs.

In systems where the material number was extended, this extension has led to a conversion of the object key into a GUID. This is what the logical key structure looks like:

Logical key structure for the BUS1017_KEY structure
Figure 1: Logical key structure for the BUS1017_KEY structure

The interface of the BAPI has got an additional parameter:

VALUE(MATERIAL_LONG) TYPE  BAPI_MATVAL_KEY-MATERIAL_LONG

The original MATERIAL parameter has remained untouched by the field extension and still refers to an 18-character field.

The object key is now as follows:

begin of key,
  guid32 like bus1017_mapping-id,
end of key.

The BAPI call is performed in the following way:

  • Instead of supplying the former MATERIAL parameter, the new MATERIAL_LONG parameter is used. Note that, in this case, the names of the parameter and key field differ.

  • The values of the key parameters are taken from the logical key.

call function 'BAPI_SALESORDSTCK_PRICE_CHANGE'
  exporting
    material_long       = object-private-key-material
    valuationarea       = object-private-key-valuationarea
    valuationtype       = object-private-key-valuationtype
    sddocumentnumber    = object-private-key-sddocumentnumber
    sddocumentitem      = object-private-key-sddocumentitem
    pricedate           = pricedate
    material_evg        = materialevg
  importing
    pricechangedocument = pricechangedocument
  tables
    prices              = prices
    return              = return
  exceptions
    others              = 01.

The fact that the names of the parameters and the corresponding logical key field names differ is certainly not a problem for the business object itself since the function module call can be altered manually. However, the violation of the naming rule has a negative side effect within the context of IDoc processing. The parameter names of the generated input function are taken from the method signature and from the key definition. The link between the final BAPI call and the parameters of the input module is based on this naming rule as well as on the definitions of the method parameters, which contain the names of the corresponding function module parameters.

Now that the naming rule has been violated, there has to be a way to store the fact that the function module now has a new parameter that corresponds to an extended key field.

In order to achieve this, Key parameters have been introduced.

Related Information