Using BAPI's in ABAP code

[Former Member]

Hi bapi Guru's,

I am asked to use bapi's(Instead of BDC's) for data upload .I am not getting good documentation on 'USING BAPI's IN ABAP',Like Defining structures, and what are the FM's to be called like bapi_commit.

Any Info is Appriciated.

Regards

satish

[Former Member]

Try transaction BAPI, you will get list of all business objects and their associated BAPIs, You should get documentation of each of these BAPI's as well...

Rgds,

Samir.

[Former Member]

Hi Satish,

You will be using the BAPI function module in your ABAP code just like any other function module and there is enough information about each individual BAPI function module. I am not sure I understood your statement when you said there is not good documentation on 'Using BAPIs in ABAP'.

Srinivas

[Former Member]

Hi Satish,

There is some quite good SAP help on using BAPIs. The following link should give you everything you need (including examples of calling bapis from ABAP).

Check out: http://help.sap.com/saphelp_erp2004/helpdata/en/7e/5e114a4a1611d1894c0000e829fbbd/frameset.htm

Hope that helps.

Brad

[Former Member]

Hi,

Though BAPIs are documented well, you could either search this forum for the BAPI you intend to use or post any questions you have. I am sure the community will try to assist you as much as possible.

Take a look at http://searchsap.techtarget.com/originalContent/0,289142,sid21_gci948835,00.html for an easy to use BAPI Learning Guide by searchsap.com

Regards

[juan_suros]

Every BAPI method is implemented as a remote-enabled RFC function. See transaction "BAPI", tab "Detail", field "Function module" for each BAPI method. This will show a FM name that can be called directly from ABAP.

After calling the bapi FM, you may need to call FM BAPI_TRANSACTION_COMMIT to force the system to save the change at that time.

Most of the time, using these bapi FMs is faster than BDC sessions and easier to debug.

[Former Member]

Hi Juan,

<rant begins>

What does:

> easier to debug

mean?

This is completely the opposite of my experience. Bapis are abstracted from the user experience, and provide error messages which are sometimes meaningful and sometimes not. There is no built-in error re-processing capability in BAPIs.

BDC's provide a screen by screen system for detecting and correcting errors. Not only, if you have an error, can you see exactly what screen it occurs on, but you can also correct the error on the fly. And all of these details are recorded in the SM35 log.

Sorry, but I really don't agree with that statement at all.

<rant over>

Cheers,

Brad

[juan_suros]

Dear Brad,

Not surprisingly, I don't agree.

SAP transactions have a lot of business logic built into their screens that a BDC session uses without understanding. You would have to fight your way through a lot of GUI code to debug what is actually happening in a BDC session.

BAPIs, having no User Interface, are easier to debug.

You are correct that "BAPIs are abstracted from the user experience" and that is the point I am trying to make.

ABAP should be used to customize SAP, not to replace standard functionality. For the standard exceptions to this rule like repetitive data entry and data extraction we have BAPIs.

Juan

[Former Member]

Sorry Satish,

Maybe this is going off topic a little, bit perhaps also its relevant as you have been asked to move from BDC's to BAPIs.

Juan,

When I talk about debugging, there are two levels to this:

<b>1. Debugging by the programmer</b>

In this case, how can it be easier to debug an error from a BAPI than from the screen? For a sales order, for example, when you enter a delivery date of 01.01.2000 for an item, via BDC you will get an error message as the item is entered (something along the lines of delivery date is in the past), and you will see exactly the date you have entered, and if you don't understand the error, you can click on F1 and it will give you the long description of the error. Via a BAPI, you would get the error message, and you MIGHT get the item number and the date in question. But if you don't understand the error what do you do then? Debug the BAPI itself? You could, but isn't this a rather lengthy way to get to the root of the problem? In general, any errors you get calling BAPIs/BDCs are errors with your master data, or breaking business rules, you shouldn't have to debug standard code to tell you whats going wrong, the application can tell you.

<b>2. Debugging by the end user</b>

When you implement a BAPI/BDC this will be related to an interface/automated transaction etc. When its in production you will occassionally get errors (due to bad master data, not fully capturing all the business logic in your custom coding [it happens], technical issues etc.) What do you do then? In the case of BDC you can do nothing. The error is recorded, and you can get end users to process the errors by stepping through the screens (which they already know how to use) and make corrections as required. In the case of BAPIs, you have to record the error in a table or a file, then develop some kind of interface to display the errors, then develop some kind of process for re-processing the errors. If the data used to call the BAPI is not correct then you also need to provide a facility for changing the data before reprocessing. Normally you do none of this because its too much work and you end up having all errors coming back to the SAP team who have to debug and change table entries etc. to get it all to work. I would not say that this makes BAPIs easier to debug.

Oops, just realised my pasta is burning!!!

Anyway, think I got my point across. Not personal but feel quite strongly about this topic. To me BDC's are still a relevant tool despite the push for Idocs/BAPIs.

Cheers,

Brad