Standards for BAPIs | Java & BAPI Technology for SAP

Team-Fly

Before we get into the nuts and bolts of building a BAPI, you should know about the standards and rules that SAP has imposed for BAPIs.

A BAPI cannot contain the ABAP statement COMMIT WORK. Using a COMMIT WORK in a BAPI may trigger unwanted tasks in the calling program (for example, perform XXX on commit). If a COMMIT WORK is to be performed, it should be done through the BapiService.TransactionCommit call from the program that is calling the BAPI. The BAPI should then perform its updates through the update task, based on the On Commit principle of SAP ABAP.
BAPIs should be able to function on their own, without the need to call other BAPIs. Also, keep in mind that BAPIs are function modules that are part of function groups. Function groups have shared global memory, and a BAPI should not rely on some prior function module call to the same group to set this shared memory.
BAPIs cannot call up any dialog boxes or output any type of display (including lists). A BAPI may be called by a system that is external to SAP (for example, a Java program) that will not be able to handle the dialog or list display.

BAPIs should not contain any message statements.
BAPIs also cannot contain the ABAP commands CALL TRANSACTION or SUBMIT REPORT.
BAPI structures cannot use Include structures.
Global memory should not be used to transfer data to or from a BAPI. Along these same lines, you should not use parameter IDs (through set or get) in a BAPI.

Because each BAPI should be able to run on its own without any prior calls to other BAPIs, all pertinent authorization checks should be performed in every BAPI.

Standards for Parameters

The standards for parameters are as follows:

SAP has indicated that all BAPI parameters must be in the English language and be meaningful. You should not have fields like FLAG or RESTRICT because they do not intuitively indicate what the parameter does.
When dealing with numerical values such as quantity or currency, you must also specify a parameter to indicate the unit that the quantity is in or the type of currency you are dealing with.
You must either define all BOR fields in the input and export parameters, or not define the fields at all.
All key fields in GetDetail and GetList BAPIs must be displayed as text fields.
Also, whenever possible, F4 input help for fields in BAPI parameters must be made available. The F4 help documents the parameters and is often the only documentation that is easily available for a programmer to reference.
All BAPIs must have either an export parameter named RETURN or a table named RETURN. This variable tells the calling program whether any problems were encountered during the BAPI call. The standard here is that the RETURN parameter is set to initial if no problems were encountered in the BAPI's execution. The RETURN parameter is modeled after the structure BAPIRET2 and can be filled via the function module BALW_BAPIRETURN_GET2.

The fields of structure BAPIRET2 are shown in Table 18.1.

Table 18.1 Structure for BAPIRET2

Field	Type	Description
TYPE	CHAR 1	S = success message E = error message W = warning message I = information message A = termination message (abort)
ID	CHAR 20	Message ID. The BAPIRET2 structure takes into account the name space extension for the message class as of release 4.0. If you want messages to be compatible with earlier R/3 releases, use only the first two characters of the message ID.
NUMBER	NUMC 3	Message number.
MESSAGE	CHAR 220	Full message text from table T100. All variables (in fields Message_V1 to Message_V4) have been replaced with text.
LOG_NO	CHAR 20	Number of application log. This field is empty if no log is used.
LOG_MSG_NO	NUMC 6	Current number of messages in the application log.
MESSAGE_V1
MESSAGE_V2
MESSAGE_V3
MESSAGE_V4	CHAR 50	Fields for the variable texts of the message specified in ID and NUMBER fields.
PARAMETER	CHAR 32	Identifies the parameter containing the invalid value.
ROW	INT 4	Identifies the line number of the data record containing the invalid value.
FIELD	CHAR 30	Identifies the field containing the invalid value.
SYSTEM	CHAR 10	System (logical system) in which the message was generated.

Standardized BAPIs

Before you start to develop your BAPI, you need to consider whether it falls into a category that SAP calls Standard BAPIs. These BAPIs provide basic functionality that can be used on many SAP objects. An example of a standardized BAPI is the GetList BAPI. This BAPI returns a list of the objects of which it is a method. Therefore, if you are going to write a similar BAPI for a customer-built object, you should call the method GetList, not ShowObject or ListEntries. This approach enables other programmers to easily navigate and use your BAPIs.

GetList

The GetList standard BAPI imports the object keys and retrieves the objects that meet the input criteria. The list of fields for each listed object should be extensive enough to allow the user to easily differentiate the objects. Ideally, you should put a user exit in this BAPI that would allow a programmer to modify the list of fields returned for each object.

GetDetail

The GetDetail standard BAPI imports the object keys and returns details from one specific object. Ideally, a user exit should be coded into the BAPI that will allow a programmer to modify which fields are returned.

GetStatus

The GetStatus BAPI is an Instance BAPI that returns the current status of an object (for example, a sales order).

ExistenceCheck

The ExistenceCheck BAPI is an Instance BAPI that checks whether the specified object actually exists. Remember that this BAPI does not return data about the object; it simply determines whether the object exists. Therefore, for performance reasons, when coding the database Select statements, make sure to retrieve as little information as possible.

select matnr into loc_matnr from mara where matnr = mara-matnr.

Create or CreateFromData

The Create or CreateFromData BAPI creates a single instance of an object.

Change

The Change BAPI changes an existing object.

Delete and UnDelete

The Delete BAPI deletes objects from the database. Deleting does not necessarily mean physically deleting the item; it may just mean to mark the object's delete indicator (the record is deleted later by some archiving procedure). The Undelete BAPI resets the delete indicator on a record.

Add(subobject) and Remove(subobject)

Certain objects have subobjects attached to them, for example, a sales order that has line items. In the SalesOrder example, you could set up the AddItem and RemoveItem BAPIs to actually add and remove items from the sales order.

Replicate and SaveReplica

The Replicate and SaveReplica BAPIs are implemented as methods of replicable business objects. These BAPIs enable specific instances of an object type to be copied to one or more systems. Replicate and SaveReplica are used mainly to transfer data between distributed systems within the context of ALE.

Team-Fly