Showing posts with label BAPI'S IN ABAP. Show all posts
Showing posts with label BAPI'S IN ABAP. Show all posts

BAPI SAMPLE CODE FOR FLAT FILE in SAP ABAP

BAPI SAMPLE CODE FOR FLAT FILE in SAP ABAP

REPORT ZBAPI.

DATA: BEGIN OF i_data OCCURS 0,
text(255),
END OF i_data.
DATA: i_ekko TYPE bapiekkoc.
DATA: it_ekko LIKE TABLE OF i_ekko INITIAL SIZE 0 WITH HEADER LINE.
DATA: BEGIN OF i_ekpo OCCURS 0,
po_item(5),
pur_mat(18),
plant(4),
net_price(23),
disp_quan(13),
END OF i_ekpo.
DATA: it_ekpo LIKE TABLE OF bapiekpoc INITIAL SIZE 0 WITH HEADER LINE .

DATA: BEGIN OF i_eket OCCURS 0,
po_item(5),
deliv_date(8),
quantity(13),
END OF i_eket.
DATA: it_eket LIKE TABLE OF bapieket INITIAL SIZE 0 WITH HEADER LINE.
DATA: v_index TYPE i.
DATA: return TYPE TABLE OF bapireturn INITIAL SIZE 0 WITH HEADER LINE.
DATA: po_num(10).

START-OF-SELECTION.

CALL FUNCTION 'UPLOAD'
  • EXPORTING
  • CODEPAGE = ' '
  • FILENAME = ' '
  • FILETYPE = ' '
  • ITEM = ' '
  • FILEMASK_MASK = ' '
  • FILEMASK_TEXT = ' '
  • FILETYPE_NO_CHANGE = ' '
  • FILEMASK_ALL = ' '
  • FILETYPE_NO_SHOW = ' '
  • LINE_EXIT = ' '
  • USER_FORM = ' '
  • USER_PROG = ' '
  • SILENT = 'S'
  • IMPORTING
  • FILESIZE =
  • CANCEL =
  • ACT_FILENAME =
  • ACT_FILETYPE =
TABLES
data_tab = i_data
  • EXCEPTIONS
  • CONVERSION_ERROR = 1
  • INVALID_TABLE_WIDTH = 2
  • INVALID_TYPE = 3
  • NO_BATCH = 4
  • UNKNOWN_ERROR = 5
  • GUI_REFUSE_FILETRANSFER = 6
  • OTHERS = 7
.
IF sy-subrc 0.
  • MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO
  • WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.
ENDIF.

loop at i_data.
if i_data-text(1) = 'H'.
shift i_data-text.
v_index = v_index + 1.
split i_data-text at ',' into i_ekko-doc_type
i_ekko-purch_org
i_ekko-pur_group
i_ekko-vendor.
append i_ekko to it_ekko.

elseif i_data-text(1) = 'I'.
shift i_data-text.
split i_data-text at ',' into i_ekpo-po_item
i_ekpo-pur_mat
i_ekpo-plant
i_ekpo-net_price
i_ekpo-disp_quan.
append i_ekpo.
move-corresponding i_ekpo to it_ekpo.
append it_ekpo.
clear it_ekpo.
else.
shift i_data-text.
split i_data-text at ',' into i_eket-po_item
i_eket-deliv_date
i_eket-quantity.

append it_eket .
move-corresponding i_eket to it_eket.
append it_eket.
clear it_eket.
endif.
endloop.

CALL FUNCTION 'BAPI_PO_CREATE'
EXPORTING
po_header = i_ekko
  • PO_HEADER_ADD_DATA =
  • HEADER_ADD_DATA_RELEVANT =
  • PO_ADDRESS =
  • SKIP_ITEMS_WITH_ERROR = 'X'
  • ITEM_ADD_DATA_RELEVANT =
  • HEADER_TECH_FIELDS =
  • IMPORTING
  • PURCHASEORDER =
tables
po_items = it_ekpo
  • PO_ITEM_ADD_DATA =
po_item_schedules = it_eket
  • PO_ITEM_ACCOUNT_ASSIGNMENT =
  • PO_ITEM_TEXT =
RETURN = return
  • PO_LIMITS =
  • PO_CONTRACT_LIMITS =
  • PO_SERVICES =
  • PO_SRV_ACCASS_VALUES =
  • PO_SERVICES_TEXT =
  • PO_BUSINESS_PARTNER =
  • EXTENSIONIN =
  • POADDRDELIVERY =
.
write: po_num.
loop at return.

write:/ return-message,return-type.
endloop.

Here it is.


RELATED POSTS

SAP ABAP BAPI 1
SAP ABAP BAPI 2
SAP ABAP BAPI 3
SAP ABAP BAPI 4


Handling errors in BAPI in SAP ABAP

You have to create a parameter named Return for every BAPI. This parameter returns exception messages or success messages to the calling program.

BAPIs themselves must not trigger any messages (such as MESSAGE xnnn) in the coding. In particular they must not generate terminations or display dialog boxes. Instead, all messages must be intercepted internally and reported back to the calling program in the Return parameter. Otherwise the BAPI will not be processed correctly and control may not be given back to the calling program.

All error messages or indeed any message that may be returned by the BAPI, must be defined in message table (Tools -> ABAP Workbench -> Development -> Programming environment -> Messages) and described in the documentation for the return parameter. This also applies to the most important or most likely error messages generated by other programs that can be indirectly passed via the BAPI to the application program.

ans in BAPI'S u can handle the errors with the help of BAPI RETURN parameter.

U have to declare an internal table like BAPIRET2. u need to pass this internal table to the RETURN structure .Now this internal table will capture the error messages once u run the BAPI.

In Every Bapi there will be a RETURN parameter of type BAPIRET2.

WE PASS IT AS TABLES PARAMETERS
AND ALL THE ERRORS ARE COLLECTED INTO IT
see the sample code
REPORT z34332_bdc_create_material .

data: la_headdata type BAPIMATHEAD,
la_clientdata type BAPI_MARA,
la_CLIENTDATAX type BAPI_MARAX,
la_return type BAPIRET2.

data: i_materialdescription type table of BAPI_MAKT,
wa_materialdescription like line of i_materialdescription.

la_headdata-MATERIAL = '000000000000000004'.
la_headdata-IND_SECTOR = 'M'.
la_headdata-MATL_TYPE = 'FERT'.

la_clientdata-BASE_UOM = 'FT3'.
la_CLIENTDATAX-BASE_UOM = 'X'.
la_clientdata-MATL_GROUP = '01'.
la_CLIENTDATAX-MATL_GROUP = 'X'.

wa_materialdescription = 'TEST'.
append wa_materialdescription to i_materialdescription.
clear: wa_materialdescription.

CALL FUNCTION 'BAPI_MATERIAL_SAVEDATA'
EXPORTING
headdata = la_headdata
CLIENTDATA = la_clientdata
CLIENTDATAX = la_CLIENTDATAX

* PLANTDATA =
* PLANTDATAX =
* FORECASTPARAMETERS =
* FORECASTPARAMETERSX =
* PLANNINGDATA =
* PLANNINGDATAX =
* STORAGELOCATIONDATA =
* STORAGELOCATIONDATAX =
* VALUATIONDATA =
* VALUATIONDATAX =
* WAREHOUSENUMBERDATA =
* WAREHOUSENUMBERDATAX =
* SALESDATA =
* SALESDATAX =
* STORAGETYPEDATA =
* STORAGETYPEDATAX =
* FLAG_ONLINE = ' '
* FLAG_CAD_CALL = ' '

IMPORTING
RETURN = la_return
TABLES
MATERIALDESCRIPTION = i_materialdescription

* UNITSOFMEASURE =
* UNITSOFMEASUREX =
* INTERNATIONALARTNOS =
* MATERIALLONGTEXT =
* TAXCLASSIFICATIONS =
* RETURNMESSAGES =
* PRTDATA =
* PRTDATAX =
* EXTENSIONIN =
* EXTENSIONINX =

.

write: la_return-TYPE, ',', la_return-MESSAGE.
clear: la_headdata, la_return, la_clientdata, la_clientdatax.

Related Posts

Learn ABAP BAPI basics


Before you program a BAPI you should clearly define the processes and situations the BAPI will be used for.To define the scenario the BAPI is to be used for, consider the following issues:

• Which scenario is to be implemented?

Every BAPI should be based on a model of a scenario in which it can be usefully employed. You can describe the scenario in the form of a process model.

• Which SAP Business Objects are involved?

From the scenario definition and with the help of the process model you can get information about the SAP Business Objects relevant to the BAPI scenario.

In the scenario to be implemented, a BAPI is required to read data about a creditor. First of all, a list of creditors is to be displayed from which a specific creditor can be selected. Then, using another BAPI, specific details about this creditor are to be displayed.

The relevant SAP Business Object for this scenario is Creditor.

• What functionality should the BAPI provide and how does it affect related BAPIs, especially the other BAPIs of the SAP Business Object in question?

In line with the scenario concept BAPIs must complement each other to create a complete scenario. Their relationships with each other must be clearly defined.

To read a creditor's details as described in the above scenario, two BAPIs are required:

- Display list of creditors
- Display details of a specific creditor

The interdependency between these two BAPIs is evident because first the creditor list is displayed to obtain the ID of the specific creditor sought. From this ID, details of this creditor can then be displayed.

However, the two BAPIs remain functionally independent of each other, because if the creditor ID is known, the BAPI "Display details of a specific creditor" can be used without first calling the BAPI "Display list of creditors".

• To what extent can the BAPI's functionality be implemented within the scope of the business object?

A BAPI should be developed so that it provides functionality exclusively within the context of its associated SAP Business Object. If the data of a different SAP Business Object is to be read or updated then the appropriate interface for this object must be used. The functions or methods of these other objects are used implicitly (delegation principle).

The BAPIs required to read creditor details in the above scenario are only able to access data in the SAP Business Object Creditor. Other object types are not involved.

• Is the BAPI assigned to the SAP Business Object in a meaningful and semantically correct way?

Result

Once you have considered these issues you will be able to clearly conceptualize the functionality of the planned BAPI(s). You will also have identified the SAP Business Objects relevant to the BAPI scenario.


Review

Purpose

In the previous step you created a concept for a scenario a BAPI could be applied to. You also defined relevant SAP Business Objects.

Before you implement the scenario and begin defining and developing the BAPI, you should carry out a review of the scenario concept.

Process Flow

You should carry out the review of the BAPI scenario in cooperation with all persons involved in the BAPI development and those responsible for quality control in your development group.

Result

Start developing the BAPI only after you have successfully completed the review.


Defining a BAPI and Its Interface

Purpose

After you have carried out the review of the BAPI concept and it has been accepted, you can start defining the BAPI itself.

In this step, you will decide on the names, parameters, and characteristics of the BAPI and determine the structures the BAPI will be based on.

Only after you have planned and defined these required details can you start to implement the BAPI, as described in Creating Individual Programming Objects and Programming BAPIs.

Process Flow

To define the scope and required components of the BAPI to be implemented, the following steps must be completed:

• Determining the SAP Business Object and Its Key Fields
• Defining the Interface Structure of the BAPI
• Identifying the name of the function group, or if a function group does not exist already, planning a name for one.

All BAPIs belonging to one SAP Business Object should be stored as function modules in one function group. Ascertain whether a function group has already been created for the BAPIs of the SAP Business Object in question. If a function group does not already exist, then plan a name for the one to be created.

You can use the default technical name (object type) of the SAP Business Object as the basis of the function group name. The technical name of a SAP Business Object usually takes the form of BUSnnnn, where n is a number.

Use the suffix "nnnn" as the name of the function group. For example, if the technical name of the object is BUS1008 then the associated BAPI function group is called 1008.

To ascertain the technical name of the Business Object, open the Business Object in the Business Object Repository (BOR), as described in Determining the SAP Business Object and Its Key Fields. To display further details, for example, the object type, double click the name of the Business Object.

• Assigning a name to the function module

Choose a name that gives an indication of what the BAPI is used for. The naming convention is: BAPI__. For information about naming a method refer to Naming the Method in the BOR.

For example, in the case of a BAPI which reads details for the object type Creditor, the name of the associated function module is BAPI_CREDITOR_GETDETAIL.

• Naming Parameters in the Function Module

• Defining the format for passing the values in the function module interface.
Parameters must not be converted before they are passed to and from the BAPI interface. This is because BAPIs are programming interfaces and not end user interfaces. Exceptions are currency codes, ISO codes and fields with an internal key.

• Specifying the Required Objects in ABAP Dictionary
• Naming the Method in the BOR
• Naming Parameters in the BOR

RELATED POST

SAP architecture,its full form of working and enjoy sap products

BAPI FROM BASICS

BAPI IN BOR:

SAP business objects provide an object-oriented view of business data and processes in the R/3 System.The Business Object Repository (BOR) manages business objects, organizational objects, and technical objects in a hierarchical display corresponding to the component hierarchy in the R/3 System.Methods in a business objects let you change or display its attributes.

COMPONENTS OF OBJECT TYPE:

- Basic data: Technical details such as an internal ID, release level, transport data, and so on.

- Interfaces: List of the interface from which the object type adopts attributes, methods, and events.

- Key fields: Attributes that uniquely identify an object of this type. Usually the key fields of the underlying database tables.

- Attributes: Object attributes.

These are either values from database fields (field references), values that are calculated at runtime (virtual attributes), or pointers to other objects (object references). Object references are particularly useful in Workflow definitions, allowing you to navigate easily between objects that belong together in a particular business context.

- Methods: Calls to R/3 transactions, function modules, or other ABAP code.

BAPIs are known as API methods.

- Events:

To be used in workflow definitions. The events are only defined in the BOR. To trigger an event, you can use the following (for details, see the online documentation on workflow definition):
- Links to change documents for the underlying database fields
- Links to the status administration
- Links to message control
- Calling the function module SWE_EVENT_CREATE

WHAT IS BAPI?

BAPIs are special, remote-enabled methods of a business object, and are implemented as RFC-enabled function modules.

BAPIs can perform various functions such as:
- cretaing an object
- querying the attributes of an object
- changing the attributes of an object

USES OF BAPI:

You can use BAPIs for different applications. For example:
­ Internet application components: Where individual R/3 functions are implemented on the Internet or Intranet for users with no R/3 experience.

­ Building R/3 components Communication between the business objects from different R/3 components (applications).

­ VisualBasic / JAVA / C++ : External clients access R/3 data and processes through the BAPIs.

BAPI ATTRIBUTES:

You can access BAPIs from external clients like methods access objects, which are themselves an instance in the client.

SAP guarantees that no incompatible changes will be made to the interfaces of BAPIs.

You can also use BAPIs within the R/3 System to access business data. This makes it easier for customers and partners to add to the functions offered by the system.

Displaying data that is transmitted to a BAPI or that is returned from a BAPI must be done from the calling program.

The return parameter RETURN contains success or error messages for the BAPI, and depending on the SAP R/3 Release has the dictionary structure BAPIRETURN, BAPIRETURN1, BAPIRET1, BAPIRET2 or BAPIRET2_FIX. The (common) relevant fields of these structures are:
TYPE (Message type: S(uccess), E(rror), W(arning), I(nformation) ) ;
ID (message class) ; NUMBER (message number) ; MESSAGE (message text) ;
MESSAGE_V1 , MESSAGE_V2 , MESSAGE_V3 , MESSAGE_V4 (message variables)

If the transmission is successful, RETURN is either completely empty (all the fields have their initial fields for their types), or only the TYPE field has the value 'S'. Refer to the documentation to find out which applies to the BAPI you are using.

DATA BASE UPDATES WITH BAPI:

Database updates in BAPIs are always performed by an update. The update type (synchronous or asynchronous) is specified when you call the COMMIT-BAPIs.

In BAPIs containing database updates, a COMMIT / ROLLBACK WORK is not used. Closing or rejecting a BAPI-LUW occurs by calling a special BAPI from the service object BapiService (object type 'SAP0001').
BAPI TransactionCommit (relevant function module BAPI_TRANSACTION_COMMIT)
BAPI TransactionRollback (relevant function module BAPI_TRANSACTION_ROLLBACK)

ACCESSING BAPI FROM EXTERNAL SYSTEM:

When you use BAPIs, there are 2 phases that SAP supports:

Development -

The programmer needs to know which business objects are available with which BAPIs, and what the interface looks like. You can find out this information using the BAPI Browser in the Business Object Builder. The BAPI Browser is a logical view of the BOR in which only those objects are displayed that have BAPIs. The complete interface of each BAPI is displayed.

Runtime -

SAP delivers libraries for BAPI calls for various development environments (Visual Basic, C++, Java). These libraries encapsulate the technical details of the communication, enabling developers to call a BAPI from outside the system without having to worry themselves about how BAPIs are actually implemented in the system.

ACCESSING BAPI FROM ABAP:

You can only access BAPIs currently from an ABAP program using the relevant direct function call (local or remote). SAP is planning for a later release for all BOR business objects to be integrated in the class library of ABAP so that you will be able to access BAPIs from ABAP using ABAP-OO.

The naming convention for BAPI function modules is: BAPI__

There are no exceptions for BAPI function modules.
Success or error messages are returned by the RETURN export parameter, which depending on the SAP R/3 Release has the dictionary structure BAPIRETURN, BAPIRETURN1, BAPIRET1, BAPIRET2 or BAPIRET2_FIX. The (common) relevant fields of these structures are:

TYPE (Message type: S(uccess), E(rror), W(arning), I(nformation) ) ;
ID (message class) ; NUMBER (message number) ; MESSAGE (message text) ;
MESSAGE_V1 , MESSAGE_V2 , MESSAGE_V3 , MESSAGE_V4 (message variables)

If the transmission is successful, RETURN is either completely empty (all the fields have their initial fields for their types), or only the TYPE field has the value 'S'. Refer to the documentation to find out which applies to the BAPI you are using.

RELATED POSTS

BAPI 1
 

BAPI for SAP ABAP Four


If a business object type consists of sub-objects, you can implement the following standardized BAPIs to add or remove sub-objects.The BAPIs Add and Remove are instance methods.



Import Parameters

Both BAPIs' import parameters must contain in the function module the data that uniquely identifies the sub-object as well as the key fields of the business object.If required, you can create also create these parameters:

A test run parameter for checking the entry for an object instance before actually creating the instance in the database.A change parameter to identify parameter fields containing modified values and parameter fields that have not been modified.For more information about these parameters see Standardized Parameters.

Export Parameters

You should only create the export parameter RETURN in the BAPI Remove to return messages from the method call to the calling program. For more information about this parameter see Return Parameters (Error Handling).To make the object key available to the calling program, the key fields of the object type must also be returned in the export parameters of the BAPI Add as well as in the export parameter Return.

Extension parameters

You can create extension parameters to enable customers to enhance the functionality of BAPIs without making modifications. For information about extension parameters see Customer Enhancement Concept for BAPIs.

Locking

We recommend that you implement methods of sub-objects without the locking function and create your own BAPIs instead that lock the relevant data.If you are implementing BAPIs that create or change data you should consider using buffering. For further information see Buffering for Write BAPIs.

BAPIs for Mass Processing

The BAPIs listed in the above section, "BAPIs for Creating or Changing Data", can also be used for mass processing. Here, when a BAPI is called, several business object instances are processed at the same time.



We strongly recommend that you create instance-dependent BAPIs with buffering instead of Multiple() BAPIs. For further information see Buffering with Write BAPIs.

BAPIs for Replicating Business Object Instances

The following BAPIs are used for replicating business object instances:

Replicate() and SaveReplica()

The BAPIs Replicate() and SaveReplica() are implemented as 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.


Buffering with Write BAPIs



To save external systems each having to define their own data, predefined buffering mechanisms should be implemented in all write BAPIs (i.e. BAPIs that create and change data).For SAP internal use this is particularly relevant for BAPIs developed as of Release 4.6A. If you want to implement a buffer for BAPIs in an earlier release, you should first contact a colleague in the central BAPI development group.

For BAPIs standard R/3 System mechanisms can be used to buffer application data. Data to be created or changed by a BAPI is not created in the update buffer, it is first collected in the global buffer of the BAPI function module group. Then the whole buffer is updated at a specified time.

This has the following advantages:

Improvement in performance of the whole system.The updating of individual operations is delayed and they can all be updated together. Techniques such as "array insert" improve system performance. If buffering is not used, each change must be updated separately.

Several changes to an application instance

With the first change the data is read from the database into the buffer and the change is made in the buffer. With the next change, the system recognizes that the data already exists in the buffer and also makes the change in the buffer. If buffering were not used, the first change would have to be updated before a second change could be made.

Using in Application Link Enabling

BAPIs with buffering are especially suited in situations where mass data is exchanged between systems via Application Link Enabling (ALE).The buffering mechanism enables application instances to be processed separately in the ALE layer, while still enabling the instances to be updated together. Unlike multiple BAPIs, such as, SaveReplicaMultiple(), this procedure allows error handling of individual instances.

BAPIs with buffering mean that there is no need to use or implement multiple BAPIs.



The Transaction Model for BAPIs Without Commit in use since Release 4.0 can be enhanced on the basis of these advantages:

Within one Logical Unit of Work (LUW) several changes or detailed changes can be carried out for one instance.All changes (to one or more instances) are updated together by the BAPI BapiService.TransactionCommit().


Prerequisites

The buffering mechanism for BAPIs must be implicit, that is, the caller must not have to control the buffering. A calling program must be able to use, for example, a Create()or Change() BAPI with buffering as well as it can use a BAPI without buffering. The buffer is updated implicitly in R/3.If buffering has been implemented for a business object type, all write BAPIs of this business object type must also be implemented with buffering.If write BAPIs with buffering have been implemented for a business object type, this affects the read BAPIs of this object type. Refer to the information in the Activities section below.

Features

For BAPIs with buffering, in addition to the standard guidelines, the following implementation steps and characteristics described below are required.

Function Modules for Updating the Contents of the Buffer

As BAPIs with buffering can only create or change instances in the buffer, you have to provide one or more function modules to carry out the final update of the buffer contents. These update modules transfer the entire contents of the buffer to the update program.These function modules should not be implemented as BAPIs, as these are only used in the system in which the buffer is also used.

The naming convention for these function modules is:
_SAVEBUFFER.

Exceptions must not be defined for the update modules, as these are not run until the end of the program, when error handling is no longer possible.

Function Modules for Deleting the Contents of the Buffer

To ensure that the buffer is empty at the start of a transaction, you must provide a function module that deletes the contents of the buffer. This delete function module deletes the entire contents of the buffer and removes any locks on the instances. Neither should you implement this function module as a BAPI, because it is only used in the system in which the buffer is also used.

The naming convention for this function module is:

_CLEARBUFFER.

No exceptions can be defined for delete modules because these are not run until the end of the transaction, when error handling is no longer possible (see Special Characteristics below).

Special Characteristics

BAPIs with buffering need to have special characteristics. For example, these BAPIs must be able to deal with errors because a caller cannot reprocess data in the buffer. As data is buffered implicitly, no administration BAPIs are provided for callers.

Consistency of the Buffer Contents

A BAPI with buffering must carry out all the processing steps, except for updating. The consistency of all instances created or changed in the buffer must be guaranteed by the application.

This means that:

Only operations that can be updated with consistency guaranteed can be carried out in the buffer. The update module itself cannot perform consistency checks.All other steps required before updating, such as assigning numbers or creating application blocks, must be carried out before calling the update module.For operations that cannot be updated consistently, no action can take place. In these cases the error situation must be reported in the BAPI return parameter.

Calling Update Modules

After the buffer operations have been successfully carried out, using the command
PERFORM ON COMMIT
call a form routine which then calls the update module(s).
The update modules must be called using the command
CALL _SAVEBUFFER IN UPDATE TASK
to flag the execution in the update program.

By adding 'ON COMMIT' to the command PERFORM ON COMMIT, updating is not carried out immediately,it is carried out in the next COMMIT WORK. This way any number of BAPI calls can be collected together. The final COMMIT WORK command that is executed via the BAPI BapiService.TransactionCommit(), executes the form routine and also each update module once only. For this reason error handling cannot be performed in this form routine or in the function module.

Subscribing the Delete Module

At the start of each LUW the buffer must be empty. Any instances that may exist in the buffer, which were updated in an earlier LUW, are no longer blocked and may be older than the versions in the database. If this instance is updated again, inconsistencies would result.



The delete module is subscribed by calling the central function module BUFFER_SUBSCRIBE_FOR_REFRESH, whereby the parameter NAME_OF_DELETEFUNC must contain the name of the delete module.


Activities

Keep in mind the following important information about how write BAPIs with buffering interact with read BAPIs of the same business object.

Write BAPIs with Buffering and Read BAPIs for the Same Business Object
No Buffering for Read BAPIs

If write BAPIs with buffering are implemented for the same business object type, read BAPIs are not allowed to use the buffer for the same business object type, so that data read from the database can be stored, thereby avoiding further database accesses.

As the imported data is not locked, the corresponding data in the buffer would become outdated over time. Subsequent read operations would first access the buffer and read the potentially out-of-date data, as data in the database can only be read, if this data is not in the buffer.

Buffer Instances Are "Real" Instances

All instances created or changed by write BAPIs in the buffer are consistent. They can be used by other change BAPIs for further processing within the same LUW.To guarantee the consistent behavior, all read BAPIs must handle existing instances that are in the buffer, and not yet in the database, as valid instances. Read BAPIs must be implemented in such a way that they first try to read an instance in the buffer and only start searching the database, if the instance is not found in the buffer.A buffer instance is therefore "real" instance. For example, a BAPI ExistenceCheck() must search for the existence of an instance in the buffer also

Prerequisites

The buffering mechanism for BAPIs must be implicit, that is, the caller must not have to control the buffering. A calling program must be able to use, for example, a Create()or Change() BAPI with buffering as well as it can use a BAPI without buffering. The buffer is updated implicitly in R/3.If buffering has been implemented for a business object type, all write BAPIs of this business object type must also be implemented with buffering.If write BAPIs with buffering have been implemented for a business object type, this affects the read BAPIs of this object type. Refer to the information in the Activities section below.

Features

For BAPIs with buffering, in addition to the standard guidelines, the following implementation steps and characteristics described below are required.
Function Modules for Updating the Contents of the Buffer
As BAPIs with buffering can only create or change instances in the buffer, you have to provide one or more function modules to carry out the final update of the buffer contents. These update modules transfer the entire contents of the buffer to the update program.

These function modules should not be implemented as BAPIs, as these are only used in the system in which the buffer is also used.
The naming convention for these function modules is:
_SAVEBUFFER.

Exceptions must not be defined for the update modules, as these are not run until the end of the program, when error handling is no longer possible.

Function Modules for Deleting the Contents of the Buffer

To ensure that the buffer is empty at the start of a transaction, you must provide a function module that deletes the contents of the buffer. This delete function module deletes the entire contents of the buffer and removes any locks on the instances. Neither should you implement this function module as a BAPI, because it is only used in the system in which the buffer is also used.

The naming convention for this function module is:

_CLEARBUFFER.
No exceptions can be defined for delete modules because these are not run until the end of the transaction, when error handling is no longer possible (see Special Characteristics below).

Special Characteristics

BAPIs with buffering need to have special characteristics. For example, these BAPIs must be able to deal with errors because a caller cannot reprocess data in the buffer. As data is buffered implicitly, no administration BAPIs are provided for callers.

Consistency of the Buffer Contents

A BAPI with buffering must carry out all the processing steps, except for updating. The consistency of all instances created or changed in the buffer must be guaranteed by the application.

This means that:

  1. Only operations that can be updated with consistency guaranteed can be carried out in the buffer. The update module itself cannot perform consistency checks.
  2. All other steps required before updating, such as assigning numbers or creating application blocks, must be carried out before calling the update module.
  3. For operations that cannot be updated consistently, no action can take place. In these cases the error situation must be reported in the BAPI return parameter.

Calling Update Modules

After the buffer operations have been successfully carried out, using the command PERFORM ON COMMIT call a form routine which then calls the update module(s).The update modules must be called using the command CALL _SAVEBUFFER IN UPDATE TASK to flag the execution in the update program.

By adding 'ON COMMIT' to the command PERFORM ON COMMIT, updating is not carried out immediately,it is carried out in the next COMMIT WORK. This way any number of BAPI calls can be collected together. The final COMMIT WORK command that is executed via the BAPI BapiService.TransactionCommit(), executes the form routine and also each update module once only. For this reason error handling cannot be performed in this form routine or in the function module.
Subscribing the Delete Module.

At the start of each LUW the buffer must be empty. Any instances that may exist in the buffer, which were updated in an earlier LUW, are no longer blocked and may be older than the versions in the database. If this instance is updated again, inconsistencies would result.



Activities

Keep in mind the following important information about how write BAPIs with buffering interact with read BAPIs of the same business object.Write BAPIs with Buffering and Read BAPIs for the Same Business Object

No Buffering for Read BAPIs

If write BAPIs with buffering are implemented for the same business object type, read BAPIs are not allowed to use the buffer for the same business object type, so that data read from the database can be stored, thereby avoiding further database accesses.As the imported data is not locked, the corresponding data in the buffer would become outdated over time. Subsequent read operations would first access the buffer and read the potentially out-of-date data, as data in the database can only be read, if this data is not in the buffer.

Buffer Instances Are "Real" Instances

All instances created or changed by write BAPIs in the buffer are consistent. They can be used by other change BAPIs for further processing within the same LUW.To guarantee the consistent behavior, all read BAPIs must handle existing instances that are in the buffer, and not yet in the database, as valid instances. Read BAPIs must be implemented in such a way that they first try to read an instance in the buffer and only start searching the database, if the instance is not found in the buffer.

A buffer instance is therefore "real" instance. For example, a BAPI ExistenceCheck() must search for the existence of an instance in the buffer also.

RELATED POSTS

BAPI PART 1
BAPI FROM BASICS

EnjoySAP introduction and Business Process of SAP