HOW TO CREATE OWN BAPI’S

Topics covered under this are:

•What is BAPI?
•Some Conventions about BAPI
•Example showing How to Create a BAPI

What is BAPI?
BAPI is an abbreviation used for Business Application Programming Interface. These are interfaces within the business framework to link SAP components to one another and SAP components with third-party components.

The SAP Business Objects are an essential part of the Business Framework and the prerequisites for interoperability. SAP Business Objects cover a broad range of R/3 business data and processes and can be accessed using BAPIs. The SAP Business Objects and their BAPIs thus provide an object-oriented view of R/3 business functionality.

The SAP Business Object types are defined by the following:

Object type
The object type describes the features common to all instances of that object type. This includes information such as the unique name of the object type, its classification, and the data model.

Key fields
The key fields determine the structure of an identifying key, which allows an application to access a specific instance of the object type. The object type "Employee" and the key field "Employee.Number" are examples of an object type and a corresponding key field.

Attributes
An attribute contains data about a Business Object, thus describing a particular object property. For example, "EMPLOYEE.NAME" is an attribute of the "EMPLOYEE" object type.

Events
An event indicates the occurrence of a status change of a Business Object.

Interfaces
Interfaces are groups of related methods associated with an object type.

SOME CONVENTIONS ABOUT BAPI
•Methods
•Parameters
•Standardized BAPIs
•Standardized Parameters
•Guidelines for BAPI development
•BAPI/ALE Integration

Methods
A method is an operation that can be performed on a Business Object and that provides access to the object data. A method is defined by a name and a set of parameters and exceptions, which can or must be provided by the calling program in order to use the method. BAPIs are examples of such methods.
•If the BAPI to be implemented is a standardized BAPI then make use of generic names Like CheckExistence, GetList etc.
•The method name can be of maximum 30 characters and should be in English.
•Underscores are not allowed in BAPIs so to separate the words make used of a combination of upper and lower case characters for e.g. GetDetail
•BAPIs have return parameter that can be either an export parameter or an export table.
•So that customers can enhance BAPIs, each BAPI must have an ExtensionIn and an ExtensionOut parameter.

Parameters
•If standardized parameters are used, you have to use the names specified for standardized parameters.
•BAPI parameter names should be meaningful. A parameter name can be of maximum 30 characters. For example if some BAPI is related to some customer where in customer code is to be input, the parameter name can be CUSTOMERCODE or CUSTOMERNO.
The components of a parameter name in the Business Object Repository (BOR) are separated by upper and lower case letters to make them easier to read. Example: CustomerCode
•Unit of measure fields must accompany all quantity fields and currency identifiers must accompany currency amount fields.

Standardized BAPIs
Some BAPIs provide basic functions and can be used for most SAP business object types. These BAPIs should be implemented the same for all business object types. Standardized BAPIs are easier to use and prevent users having to deal with a number of different BAPIs. Whenever possible, a standardized BAPI must be used in preference to an individual BAPI.
For details use the link http://www.sap-img.com/abap/bapi-conventions.htm
BAPIs are actually created by and maintained with other BAPIs. The BAPI that creates BAPIs is in the BOR, and is called Create. (There’s also a variation, CreateFromData, that is sometimes useful.) Objects that have already been created, and need to be modified, may be manipulated with the BAPI Change, also found in the BOR.

Other BAPI utilities for object manipulation include Delete and UnDelete, Replicate and SaveReplicate, GetStatus, GetDetail, and ExistenceCheck, all of which are self-explanatory. These handy utilities exist alongside the workhorse BAPIs in the BOR. There is also a convenience in SAP called the subobject—objects attached to a greater object, such as line items on a purchase order. The BOR provides you with Add(subobject) and Remove(subobject) to facilitate these.

Typical of an object-oriented system, BAPIs must be treated as objects. Some are instance-dependent (a specific occurrence of an object); some are instance-independent (requiring class methods). When creating a BAPI, you must obviously be clear about which applies. As an example, if you’re working with a class-method BAPI (e.g., the SalesOrder class), GetDetail isn’t useful, because it returns data items from a specific sales order. Instead, you would use GetList, which would return a list of all instantiations of SalesOrder.

Guidelines for BAPI development
•BAPI structures must not use includes.
•There should be no functional dependencies between two BAPIs
•BAPIs must perform there own authorization check
•BAPIs should not use dialogs
•CALL TRANSACTION or SUBMIT REPORT must not be invoked in a BAPI
•Instead of COMMIT WORK a BAPI must make use of the BAPI TransactionCommit to execute the commit after the BAPI has executed.
•Program should not get terminated due to BAPIs but instead the BAPI must communicate relevant messages through the return parameter.

BAPI/ALE Integration
When you use the BAPIs for asynchronous messaging, the application in the sending system calls the generated ALE IDoc interface instead of the BAPI. Asynchronous BAPIs use the ALE interface this way:
•Creates an IDOC from the BAPI data
•Sends the IDOC to the target system
•Receives the IDOC in the target system, creates the BAPI data from the IDoc and calls the BAPI

An ALE interface for a BAPI is created in transaction BDBG.