BAPI and BAPI Wrapper

[Former Member]

Hi All,

I would like to know the difference between a BAPI and a BAPI Wrapper in detail.

I would also like to know the procedure to create the various types of BAPI Wrappers- Getlist, GetDetail, Create, Modify and Delete.

regards,

Sunil

[Former Member]

Hi,

General Introduction to BAPIs (CA-BFA)

Purpose

BAPIs (Business Application Programming Interfaces) are the standard SAP interfaces. They play an important role in the technical integration and in the exchange of business data between SAP components, and between SAP and non-SAP components. BAPIs enable you to integrate these components and are therefore an important part of developing integration scenarios where multiple components are connected to each other, either on a local network or on the Internet.

BAPIs allow integration at the business level, not the technical level. This provides for greater stability of the linkage and independence from the underlying communication technology.

Integration

BAPIs can be used for the following types of integration:

Connecting SAP Systems to the Internet using the SAP Business Connector or Internet Application Components (IACs)

The standard SAP interfaces and all BAPIs are published centrally in the XML-based Interface Repository (IFR). They are stored as XML schema, which means that they are directly available for use in integration scenarios where multiple components communicate with one another using the Internet. You can access the Interface Repository in the Internet using the following address: http://ifr.sap.com.

Creating true component software, by enabling standardized communication between SAP components. The aim is to encapsulate the functions of the SAP system in independent business components that are integrated through a common interface (the BAPIs).

Connections to third-party software and legacy systems

Implementing distributed scenarios with asynchronous connections using Application Link Enabling (ALE)

Using PC programs as frontends to SAP Systems. These can be developed with Visual Basic (Microsoft), for example, or with Visual Age for Java (IBM)

Workflow applications that extend beyond system boundaries

Workflow applications that communicate with one another using the Internet

Customers’ and partners’ own developments

The diagram below shows how BAPI interfaces enable different types of applications to be linked with the SAP system.

Object-oriented technologies have become standard for communication between different software products. For this reason SAP has introduced business object types that structure the data and processes according to business criteria. Business object types are used to break the SAP system down into smaller, disjunctive units, improving its structure and reducing its complexity.

BAPIs are defined as methods for the business object types. As a result, both the object-oriented structures in SAP Systems and the opportunity for object-oriented access are offered. These object-oriented interfaces allow other components to directly access the application layer of an SAP system without having to know the specific implementation details.

The introduction of business object types and their BAPIs enable object orientation to be used in central information processing in companies. For example, you can reuse existing functions and data, achieve trouble-free technical interoperability, and implement non-SAP components.

The resulting architecture is illustrated in the graphic below. The main parts are:

Business components

SAP business components provide autonomous business functions and consist of business objects. For example, the business object types Employee and Applicant are assigned to business component Human Resources. Business processes are either implemented within a business component or across several components (distributed business processes).

Business object types

The object-oriented structure of the SAP system is based on business object types. A single business object type represents one business entity. It encompasses the functions and the data of this entity.

BAPIs

The Business Application Programming Interfaces allow object-oriented access to the SAP system through methods for the business object types. Together with the business object types, BAPIs define and document the interface standard at the business level.

Application Link Enabling (ALE)

The ALE integration service enables the technical integration of business processes that are carried out in different SAP and non-SAP systems. It involves distributing business object types across the systems using the ALE distribution model.

Integration scenarios

The design of all relevant situations in the Business Framework is based on concrete scenarios. Integration scenarios describe how components, business object types, and BAPIs interact, and integrate the systems by synchronizing business processes at a semantic level.

What is a BAPI Wrapper? | Testing BAPI Wrappers | What is a SyncBO?

BAPI Wrapper Types

In this section, we'll look at general rules for BAPI Wrappers and then examine the specifics of each BAPI Wrapper type (that is: GetList, GetDetail, Create, Change & Delete) separately.

General Rules of BAPI Wrapper

For an ABAP function module to be a BAPI wrapper, certain rules (interface and behavior) need to be followed by each function module. Basically, any BAPI wrapper needs to cover the BAPI development rules (please see service.sap.com/bapi for detailed information on BAPI development rules); however, there are some BAPI wrapper specific development rules, that all types of BAPI wrappers must comply with:

Rules for BAPI Wrappers

Processing type of a function module must be remote-enabled module.

Parameter named “RETURN” where the type is BAPIRET2 structure needs to be defined as either Export or Tables parameter

Parameters can only refer to either a structure or a field of a structure (<structure>-<field>)

Changing parameter can NOT be used

Exceptions can NOT be used

Parameters can NOT refer to structures that include other structures within: the reference structure needs to be a flat structure, and fields in the structure can NOT refer to types

Consistency within the business object must be ensured by defining Export/Import/Tables parameters of 5 types of BAPI wrappers appropriately

“Commit Work and Wait” needs to be executed in the update BAPI wrappers (Create/Change/Delete)

Please also observe the following:

Whether “RETURN” parameter is defined as an Export or Tables parameter is typically determined by the “RETURN” parameter of the BAPI called in the BAPI wrapper.

The rule that BAPI wrapper parameters cannot refer to structures including other structures within is equivalent to the following rule in “BAPI Programming Guide”:

You must not use APPENDs and INCLUDEs in BAPI data structures.

The structures of Tables parameters in GetList and GetDetail functions will be the HEADER and ITEM structures of the SyncBO. Some of the fields in the table can be mapped to be the fields synchronized with the clients, while some other fields can be mapped to be the default fields, which will not be synchronized with the clients. There can be also fields that will not be mapped. Such fields will not be used either for data synchronization with clients or for BAPI wrapper function calls by Smart Synchronization. (For more information, refer to Defining SyncBO)

“Commit Work and Wait” is always required after the update logic is executed successfully within a Create, Change or Delete BAPI wrapper. Otherwise, “Rollback Work” is necessary. “Wait” is required because Smart Synchronization assumes that the updated values are already available when the function call is ended. (For additional information, refer to More about Commit Work and Wait)

The following diagram describes the interface requirements for each type of BAPI wrappers. The details are covered in the sections below.

BAPI wrappers required for a business object depend on the synchronization type of the SyncBO. For more information, refer to Synchronization Types of SyncBO.

GetList function

This function is used to populate a list of business object header data from the backend system, based on the selection criteria specified in the import parameters.

The function module must have the following parameters defined:

Import – Selection criteria

Tables – Table to hold a list of BO header data

“RETURN” as Export or Tables parameter

Make sure Import parameters refer to a field of a structure (<structure>-<field>).

The Export parameter of GetDetail function and the Import parameter of Create/Change need to refer to the same structure as that of the Tables parameter of GetList function, with an exception of Create BAPI wrapper used for a SyncBO where the synchronization type is upload. Similarly, the reference type of the object key Import/Export parameters of GetDetail/Create/Delete must be the corresponding object key field name of the structure in the Tables parameter of GetList function (for example, <header_structure_name>-<key_field_name>).

The SyncBO will call the function based on the following SyncBO mapping:

Import: Default values of the SyncBO mapped to the import parameter of GetList function are used, which will be the selection criteria for the HEADER data

Tables: Structure of the header table in Tables parameter is mapped as the HEADER structure of SyncBO

When a SyncBO has a GetList function mapped, the HEADER structure of the SyncBO will be the structure of the Tables parameter of the GetList BAPI wrapper function. Then, the client view of the HEADER of the SyncBO will be the subset of the HEADER structure of the SyncBO.

Example

Look at the sample GetList function module MEREP_COUNTRY_GETLIST in your Web AS.

This function module contains one Import parameter for selection criteria. “RETURN” parameter is defined as Export parameter. The header table structure in Tables parameter has 4 fields.

Look at the sample GetList function module MEREP_CONTACT_GETLIST in your Web AS.

This function module contains no Import parameter for selection criteria. “RETURN” parameter is defined as Export parameter. The header table structure in Tables parameter has 17 fields.

GetDetail function

This function is used to extract one business object header data and list(s) of associated item data from the backend system.

If a SyncBO has Create/Change/Delete BAPI wrappers, the GetDetail function for the SyncBO needs to be specified, even if no item data is required (for example, with no Tables parameter).

The function module must have the following parameters defined:

Import – Object key(s) to uniquely specify the header data

Export – Structure to hold the selected BO header data

Tables – Table(s) to hold the list(s) of associated item data, each item data needs unique key(s) to be uniquely identified in each item list

“RETURN” as Export or Tables parameter

It is important that each item data is uniquely identifiable within the item table. Some BAPIs do not specify key(s) to uniquely identify item data. In such a case, the key field(s) needs to be added to the structure of the corresponding Tables parameter, and the corresponding logic needs to be added in the BAPI wrapper (for example, assigning values to key fields).

If the type of a key field is NUMC and the field does not allow external numbering, a special handling is required.

The Export parameter needs to refer to the same structure as that of the Table parameter of GetList function. Similarly, the reference type of the object key Import parameters must be the corresponding object key field name of the structure in the Tables parameter of GetList function (for example, <header_structure_name>-<key_field_name>).

If a GetDetail function is intended for a SyncBO where the synchronization type is download, the Export parameter to return the header data is not mandatory. However, it is recommended to always define the Export parameter to return the header data, in case that it is reused for 2-way or timed 2-way SyncBO (For more information on the synchronization type, refer to Synchronization Type).

The SyncBO will call the function based on the following SyncBO mapping:

Import: Field value(s) specified as the HEADER structure object key(s) of the SyncBO are used, which will uniquely identify the business object

Tables: Structure(s) of Tables parameter(s) is mapped as the 0n0 structure of the SyncBO, where n=1,2,3… Item key field(s) needs to be specified in the SyncBO.

Example

Look at the sample GetDetail function module MEREP_CONTACT_GETDETAIL in any SAP system with mySAP Technology 6.20 or higher.

This function module contains one Import parameter to uniquely specify the HEADER. Note that the parameter refers to PERSNUMBER structure field in PERSON Tables parameter in MEREP_CONTACT_GETLIST.

It has 2 Export parameters: one of which is “RETURN” parameter and the other is the header structure to hold the header data. Note that the structure is the same as that of the Tables parameter in “MEREP_CONTACT_GETLIST”.

It has 2 Tables parameters, which are ADDRESS and E_MAIL. They are the item tables for the business object. Note that each item can be uniquely identified in each item table by the 3 fields defined as keys.

Create function

This function is used to create single business object (header data and multiple item data associated with the header data) in the backend system.

The function module must have the following parameters defined:

Import – Structure to hold the new BO header data

Export – Object key(s) assigned when the creation is successful

Tables – Table(s) to hold the list(s) of associated new item data, which are used to create item data.

“RETURN” as Export or Tables parameter

The structures in Import and Tables parameters (header and item(s)) need to refer to the corresponding structures defined in GetList and GetDetail functions. Similarly, the reference type of the object key Export parameters must be the corresponding object key field name of the structure in the Tables parameter of GetList function (for example, <header_structure_name>-<key_field_name>). However, this is not applicable if the synchronization type is upload. (For more information about the synchronization type, refer to Synchronization Type).

The function module needs to perform “commit and wait” (For more information, refer to General Rules of BAPI Wrapper).

Although BAPI development guideline states that a Create BAPI must return the created object, this is not necessary in the case of Create BAPI wrapper. In the runtime, Smart Synchronization calls GetDetail BAPI wrapper to obtain the created object using the object key(s) returned in the Export parameter of Create BAPI wrapper function.

The SyncBO will call the function based on the following SyncBO mapping:

Import: Mapped to the fields of the HEADER structure or default values, and they are imported to the BAPI wrapper

Export: Mapped to the HEADER structure object key(s) of the SyncBO

Tables: Mapped to the ITEM structure(s) or default values

If the synchronization type of the SyncBO is upload, mapping for Create BAPI wrapper determines the HEADER and ITEM structures.

Example

Look at the sample Create function module MEREP_CONTACT_CREATE in any SAP system with mySAP Technology 6.20 or higher.

This function module contains one Import parameter to hold the header data. Note that the structure refers to the structure of PERSON Tables parameter in MEREP_CONTACT_GETLIST.

It has 2 Export parameters: one of which is “RETURN” parameter and the other is the parameter to hold the newly assigned key by the backend system. Note that the parameter refers to PERSNUMBER field in the structure of PERSON Tables parameter in “MEREP_CONTACT_GETLIST”.

It has 2 Tables parameters, which are ADDRESS and E_MAIL. They are the item tables for the business object and refer to the corresponding structures of Tables parameters in MEREP_CONTACT_GETDETAIL.

Change function

This function is used to modify single business object (header data and multiple associated item data) in the backend system.

This BAPI wrapper needs to handle all the update operations (Add/Change/Create) of item data. Smart Synchronization calls the function with the entire set of item data (entries of the Tables parameter), and the function may need to determine which item is newly added, which is modified and which is deleted.

Depending on the BAPI called inside the function, the logic required in the function will be different. Some BAPIs, for example, update the item data automatically (determines which is added, changed and/or deleted within BAPI) if the entire set of item data is passed. Some other BAPIs, on the other hand, request to specify which entry is added, changed and/or deleted. In such a case, the BAPI wrapper function needs to identify them, for example, by calling GetDetail function and comparing them.

The function module must have the following parameters defined:

Import – Structure to hold the BO header data being modified

Tables – Table(s) to hold the list(s) of associated item data, which are used to replace (add/modify/delete) the item data

“RETURN” as Export or Tables parameter

The structures in Import and Tables parameters (header and item) need to refer to the corresponding structures defined in GetList and GetDetail functions. Similarly, the reference type of the object key Import parameters must be the corresponding object key field name of the structure in the Tables parameter of GetList function (i.e. <header_structure_name>-<key_field_name>).

The function module needs to perform “commit and wait” (For more information, refer to General Rules of BAPI Wrapper).

The SyncBO will call the function based on the following SyncBO mapping:

Import: Mapped to the fields of the HEADER structure or default values, and they are imported to the BAPI wrapper

Tables: Mapped to the ITEM structure(s) or default values

Example

Look at the sample Change function module MEREP_CONTACT_MODIFY in any Basis 6.20 system.

This function module contains one Import parameter to hold the header data. Note that the structure refers to the structure of PERSON Tables parameter in MEREP_CONTACT_GETLIST. “RETURN” parameter is defined as Export parameter.

It has 2 Tables parameters, which are ADDRESS and E_MAIL. They are the item tables for the business object and refer to the corresponding structures of Tables parameters in MEREP_CONTACT_GETDETAIL.

Delete function

This function is used to delete one existing business object (header data and all associated item data) in the backend system.

The function module must have the following parameters defined:

Import – Object key(s) to uniquely specify the header data to be deleted

“RETURN” as Export or Tables parameter

The Import parameter needs to refer to the corresponding key field in the structure of the Tables parameter of GetList function. Similarly, the reference type of the object key Import parameters must be the corresponding object key field name of the structure in the Tables parameter of GetList function (for example, <header_structure_name>-<key_field_name>).

The function module needs to perform “commit and wait” (For more information, refer to General Rules of BAPI Wrapper).

The SyncBO will call the function based on the following SyncBO mapping:

Import: Field value(s) specified as the header structure object key(s) of the SyncBO are mapped and used, which will uniquely identify the business object

Example

Look at the sample Delete function module MEREP_CONTACT_DELETE in any Basis 6.20 system.

This function module contains one import parameter to uniquely specify the header data. Note that the parameter refers to PERSNUMBER field in the structure of PERSON Tables parameter in MEREP_CONTACT_GETLIST. “RETURN” parameter is defined as Export parameter.