Need for separate BAPI Structure for import parameters

[Former Member]

Hi All,

I have a doubt regarding the logic behind declaring a separate BAPI structure for import paramters and use it.

Let me explain you clearly,

Whenever we pass an import parameter(like vendor number/sales order number) to an normal function module we declare it using either like/type referring to an existing dictionary structure field. but when the number of import parameters increase we may think of creating a single structure with all and use it for simplicity.

But when it is the case with a BAPI, it is suggested that we create a structure even when we have single import parameter.

for example.

supposing that we create a normal function module to get the details of a given Vendor, then we declare the import parameter as below

VENDORNO LIKE LFA1-LIFNR

But <b>if we observe the BAPI_VENDOR_DISPLAY, We find that declaration for the same as

VENDORNO like BAPIVENDOR_ID-VENDOR_NO,

where BAPIVENDOR_ID is a separate BAPI sturcture created and assocaited only with Business object "Vendor".</b>

I tried it by declaring as for a normal FM, even then it work fine.

Now my question is,

If SAP Suggests that we have a separate structure for all import parameters starting with name BAPI and use only those fields to reference with,

what is the logic/reason behind asking so.

I had created a BAPI with paramters referring to standard database fields like

VENDORNO like LFA1-LIFNR and it is still working

<b>I had also written interface programs using VB/ .NET to access the data from my own BAPI and standard BAPI's and both were working alike.</b>

so anyone <b>please give me the reason/logic behind declaring a separate BAPI stuture for all the import parameters to be used in a method</b>.

Thanks in advance,

Lakshmi

[Former Member]

Hi,

The only reason why this has been done by SAP is that these individual fields refer to different data elements which will have a better descriptions so that a non-SAP person can understand the meaning of the same. Other wise if you see the data types being referred to, they will be exactly the same.

Regards,

Ravi

[RichHeilman]

I would say that it really comes down to simplicity. Think of it this way, you are not an ABAPer, you must right a VB or a java program to call this BAPI from outside the system, you know nothing about R/3 or its data structures/tables. Now that said, think of what it would be like if all of the fields in the BAPI signature were like we find in the standard tables, LIFNR, etc. What is LIFNR, right? Since we are ABAPers we know that it is Vendor, but for others, they may not know. This is why you will find the signature of a BAPI very descriptive, notice that all of the fields describe the field in english. This is good for non-ABAPers. To organize all of these fields that may be used in the BAPI interface, it is good to put all of them in one defined structure, that way they are all in one place, and can be referenced as such. Again, BAPIs are designed to be used by ABAPers and non-ABAPers, so simplicity is important.

Regards,

Rich Heilman