Scribd
Upload
54 views

BAPI Conventions

Standardized BAPIs like GetList() and GetDetail() are used to read business object instances, while Create(), Change(), and Delete() can create, update, or delete instances. Parameters have standardized names and structures for addresses, selections, extensions, and returns. BAPIs must not commit transactions or use dialogs, and instead return messages. Asynchronous BAPIs integrate with Application Link Enabling (ALE) by creating IDocs from call data to send between systems.

Uploaded by

Drcyto
Copyright
© © All Rights Reserved
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
54 views

BAPI Conventions

Standardized BAPIs like GetList() and GetDetail() are used to read business object instances, while Create(), Change(), and Delete() can create, update, or delete instances. Parameters have standardized names and structures for addresses, selections, extensions, and returns. BAPIs must not commit transactions or use dialogs, and instead return messages. Asynchronous BAPIs integrate with Application Link Enabling (ALE) by creating IDocs from call data to send between systems.

Uploaded by

Drcyto
Copyright
© © All Rights Reserved
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
You are on page 1/ 4

BAPI Conventions

Methods
Parameters
Standardized BAPIs
Standardized Parameters
Important things to remember..
BAPI/ALE Integration

Methods

If the BAPI to be implemented is a standardized BAPI, use the generic names,


for example, GetList, GetDetail.
The method name must be in English (maximum 30 characters).
The individual components of a BAPI name are separated by the use of upper
and lower case.Example: GetList
Underscores ("_") are not allowed in BAPI names.
Each BAPI has a return parameter that is 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 as meaningful as possible. Poorly chosen
names include abbreviations and technical names (e.g. "flag", table names, etc.).
The parameter and field names must be in English with a maximum of 30
characters.
The components of a parameter name in the BOR are separated by upper and
lower case letters to make them easier to read. Example: CompanyCodeDetail
Values that belong to each other semantically should be grouped together in one
structured parameter, instead of using several scalar parameters.
For ISO-relevant fields (country, language, unit of measure, currency),
additional fields for ISO codes are provided.
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.

The following standardized BAPIs are provided:


Reading instances of SAP business objects

GetList ( )

With the BAPI GetList you can select a range of object key values, for
example, company codes and material numbers.
The BAPI GetList() is a class method.

GetDetail() With the BAPI GetDetail() the details of an instance of a business object
type are retrieved and returned to the calling program. The instance is
identified via its key. The BAPI GetDetail() is an instance method.
BAPIs that can create, change or delete instances of a business object type
The following BAPIs of the same object type have to be programmed so that they can
be called several times within one transaction. For example, if, after sales order 1 has
been created, a second sales order 2 is created in the same transaction, the second BAPI
call must not affect the consistency of the sales order 2. After completing the transaction
with a COMMIT WORK, both the orders are saved consistently in the database.

Create( ) and
CreateFromData( )

The BAPIs Create() and CreateFromData() create an


instance of an SAP business object type, for example, a
purchase order. These BAPIs are class methods.

Change( )

The BAPI Change() changes an existing instance of an SAP


business object type, for example, a purchase order. The
BAPI Change () is an instance method.

Delete( ) and Undelete( ) The BAPI Delete() deletes an instance of an SAP business
object type from the database or sets a deletion flag.
The BAPI Undelete() removes a deletion flag. These BAPIs
are instance methods.
Cancel ( )

Add<subobject> ( ) and
Remove<subobject> ( )

Unlike the BAPI Delete(), the BAPI Cancel() cancels an


instance of a business object type. The instance to be
cancelled remains in the database and an additional instance
is created and this is the one that is actually canceled. The
Cancel() BAPI is an instance method.
The BAPI Add<subobject> adds a subobject to an existing
object instance and the BAPI and Remove<subobject>
removes a subobject from an object instance. These BAPIs
are instance methods.

BAPIs for Mass Data Processing


The BAPIs listed above for creating and changing data can also be used for mass
processing. For more information see BAPIs for Mass Data Transfer [Extern]
BAPIs for Replicating Business Object Instances

Replicate( ) and The BAPIs Replicate() and SaveReplica() are implemented as


SaveReplica( )
methods of replicable business object types. They enable specific
instances of an object type to be copied to one or more different
systems. These BAPIs are used mainly to transfer data between
distributed systems within the context of Application Link Enabling
(ALE). These BAPIs are class methods.
Other Less Used Standardized BAPIs

Programming GetStatus() BAPIs [Extern]


Programming ExistenceCheck() BAPIs [Extern]

Standardized Parameters
There are some parameters that can be created for various BAPIs because they contain
the same or the equivalent data in all BAPIs. They should be implemented the same in
all BAPIs.

Address
parameters

Specific reference structures are defined for address parameters in


BAPIs. You should copy these structures to use in your BAPI,
especially if the underlying object type uses the central address
management (CAM).

Change
Parameters

In BAPIs that cause database changes (for example, Change() and


Create() BAPIs) you must be able to distinguish between parameter
fields that contain modified values and parameter fields that have not
been modified. This distinction is made through the use of standardized
parameters.

Extension
parameters

The parameters ExtensionIn and ExtensionOut provides customers


with a mechanism that enables BAPIs to be enhanced without
modifications.

Return
Parameters

Each BAPI must have an export return parameter for returning


messages to the calling application. To provide application
programmers with a consistent error handling process for BAPI calls,
all return parameters must be implemented in the same, standardized
way.

Selection
Parameters

Standardized selection parameters are used in BAPIs that can be used


to search for specific instances of a business object type (e.g. in
GetList() ). These parameters enable the BAPI caller to specify the
relevant selection criteria.

Test Run
Parameters

The parameter TestRun is used in write BAPIs (Create() and


Change() ), to check the entries for the object instance in the database
before actually creating the object instance. The creation of the object
instance is only simulated and data is not updated.

Text Transfer
Parameters

To transfer BAPI documentation texts (e.g. the documentation of a


business object type), you have to create standardized text transfer
parameters.

Important things to remember..


It is important to follow the guidelines below when develop9ng BAPIs:
BAPIs must not contain CALL TRANSACTIO or SUBMIT REPORT
BAPIs must not invoke a COMMIT WORK. instead use the BAPI
TransactionCommit to execute the commit after the BAPI has executed.
BAPI structures must not use includes.
There should be no functional dependecies between two BAPIs
BAPIs must perform there own authorization check
BAPIs should not use dialogs
BAPIs must not cause the program to abort or terminate. re4levant messages
must be communicated through the return parameter.

BAPI/ALE Integration
When you use the BAPIs for asynchronous messagning, the application in the sendig
systen calls the generated ALE IDoc interface isntead 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 trhe target system, crreates the BAPI data from the IDoc
and calls the BAPI

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

You might also like