Professional Documents
Culture Documents
1. BAPI stands for Business Application Programming Interface. It is a library of functions that are released
to the public as an interface into an existing SAP system from an external system. RFC is the protocol used
to call functions in an R/3 system by a caller external to R/3 or to call programs external to R/3 from an R/3
system.
2. Functions can only be called via RFC, if they are tagged as RFC functions in the SAP development
workbench. They are then called RFC function modules. BAPIs are complete sets of (BAPI) function
modules that model a business application.When you are familiar with web developments: RFC can be
compared to HTTP and BAPIs are CGI applications. In other words: A BAPI function is a function module
that can be called remotely using the RFC technology.
3. An RFC, or Remote Function Call, describes an external interface to a system function module available
in SAP. For example, getting the system parameters is a system function available via RFC.
A BAPI, or Business Application Programming Interface, is an RFC-enabled function module that
provides external access to an SAP business application such as creating a sales order.
In effect, all BAPIs are RFCs but there are a superset of RFCs that are not considered BAPIs. Really, two
sides of the same coin.
4. BAPI are RFC enabled function modules. The difference between RFc and BAPI are business objects.
You create business objects and those are then registered in your BOR (Business Object Repository) which
can be accessed outside the SAP system by using some other applications (Non-SAP) such as VB or JAVA.
in this case u only specify the business object and its method from external system in BAPI there is no direct
system call. while RFC are direct system call 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
What's the difference between COMMIT WORK and BAPI_ TRANSACTION _COMMIT
Commit work is used when you code directly in ABAP and make changes in the database and
want to commit the database.
BAPI_TRANSACTION_COMMIT is used when you make changes to the SAP database by
calling a BAPI from outside SAP and want to commit the database. When you use a BAPI, you
can not directly use commit work, instead you are allowed to use only
BAPI_TRANSACTION_COMMIT.
I would sasy the difference lies more in the way u want to call Commit Work.
With BAPI_TRANSACTION_COMMIT ..the external systems have a way of deciding on whether
to Commit or to Roll back Changes.
But with Commit Work u have to code it inside ure BAPI and the outside systems then have no
chance or have any hold over the commit...
so i guess the diff lies more in the way how u want to call commit ,either from outside or from
within ure BAPI. You can use both...
SAP though recommends using BAPI_Transaction_Commit and not using Commit_work in the
BAPI...
But its upto u and your middleware guy to decide how u want to do it.
1. Header data
2. Item level
3. Schedule lines.
Header data stores the information about the characteristics of the document. Suppose if it is a sales order
how a sales order should behave will be defined here. The header data is stored in Header Tables. Header
data do not change very frequently.
For e.g:
VBAK is header table for the Sales Documents data which stores the characteristics of Sales Documents
data like Sales Document number, date created, time of creation, name of the person created the Sales
document and the quotation/inquiry is valid from details.
Item Data stores the characteristics of the items or material like which category it belongs wheather it's a
service item, deliverable item, package goods, semifinished etc. apart from this different conditions
pertaining to this items are mentioned here. The item data is one which change frequently.
For e.g VBAP is item table for the sales document which stores the data of Sales document client, material
number, sales document item and other material data for that sales document.
What is difference between Open SQL & Native SQL?
OPEN SQL
Open SQL allows developers to control SQL statements directly. Open SQL encapsulates the semantics for
statement execution, parameter binding and results fetching provided by each database vendor in a vendorindependent interface. The operations performed with Open SQL translate directly to the primitive
operations provided by each database, yet the API is consistent across all vendors.
To avoid incompatibilities between different database tables and also to make ABAP/4 programs
independent of the database system in use, SAP has created a set of separate SQL statements called Open
SQL. Open SQL contains a subset of standard SQL statements as well as some enhancements which are
specific to SAP.
Open SQL contains the following keywords:
MODIFY - Inserts lines into database tables or changes the contents of existing lines.
OPEN CURSOR, FETCH, CLOSE CURSOR - Reads lines of database tables using the
cursor.
All Open SQL statements fill the following two system fields with return codes:
SY-SUBRC
After every Open SQL statement, the system field SY-SUBRC contains 0 if the operation
was successful, a value other than 0 if not.
SY-DBCNT
After an OPEN SQL statement, the system field SY-DBCNT contains the number of
database lines processed.
Open SQL allows you to access all database tables known to the SAP system, regardless of the database
manufacturer. Sometimes, however, we may want to use database-specific SQL statements called Native
SQL in the ABAP/4 program.
A database interface translates SAP's Open SQL statements into SQL commands specific to the database in
use. Native SQL statements access the database directly.
Native SQL
Native SQL allows you to use database-specific SQL statements in an ABAP program. This means that you
can use database tables that are not administered by the ABAP Dictionary, and therefore integrate data that is
not part of the R/3 System.
ABAP Native SQL allows you to include database-specific SQL statements in an ABAP program. Most
ABAP programs containing database-specific SQL statements do not run with different databases. If
different databases are involved, use Open SQL. To execute ABAP Native SQL in an ABAP program, use
the statement EXEC. Open SQL (Subset of standard SQL statements), allows you to access all database
tables available in the R/3 System, regardless of the manufacturer. To avoid conflicts between database
tables and to keep ABAP programs independent from the database system used, SAP has generated its own
set of SQL statements known as Open SQL.
If you create a table by using database tools, without ABAP Dictionary, you are not able to use Open SQL to
reach this table. You just can use Native SQL to do that.
Native SQL statements bypass the R/3 database interface. There is no table logging, and no synchronization
with the database buffer on the application server. For this reason, you should, wherever possible, use Open
SQL to change database tables declared in the ABAP Dictionary. In particular, tables declared in the ABAP
Dictionary that contain log columns with types LCHR and LRAW should only be addressed using Open
SQL, since the columns contain extra, database-specific length information for the column. Native SQL does
not take this information into account, and may therefore produce incorrect results. Furthermore, Native
SQL does not support automatic client handling. Instead, you must treat client fields like any other.
To ensure that transactions in the R/3 System are consistent, you should not use any transaction control
statements (COMMIT, ROLLBACK WORK), or any statements that set transaction parameters (isolation
level) using Native SQL.
Using Native SQL, you can
Native SQL works without the administrative data about database tables stored in the ABAP Dictionary.
Consequently, it cannot perform all of the consistency check used in Open SQL. This places a larger degree
responsibility on application developers to work with ABAP fields of the correct type. You should always
ensure that the ABAP data type and the type of database column are identical.
Native SQL Advantages and Disadvantages - EXEC SQL statement
Advantages
Tables are not declared in ABAP Dictionary can be accessed. (e.g. Tables belonging to
sys or system user of Oracle, etc.)
To use some of the special features supported by the database-specific SQL. (e.g.
Passing hints to Oracle optimizer.)
Disadvanteges
ABAP program containing database-specific SQL statements will not run under different
database systems.
What are the difference between table controls and step loops in dialog programming ?
1.Function modules use a special screen to define the parameters where as subroutines use
the same ABAP/4 editor to define its parameters.
2.Tables work area can be commonly shared by calling program and subroutine where as
function modules do not share commonly.
3. Calling a function module syntax (Call function.) is different from calling a subroutine
syntax (perform.).
4. With raise statement user can exit from a function module where as exit is used in
subroutines
TABLE CONTROLS are simply enhanced STEP LOOPS that display data with the look and feel of a table
widget in a desktop
application. TABLE CONTROLS are always single lines, but can be very long. ( Table control rows are
scrollable ). The structure of table controls is different from step loops.
STEP LOOP
The STEP LOOP are the predecessor of TABLE CONTROL they are used to display tabular data on the
screen.They are repeated sequence of blocks of screen element. In a step loop number of screen elements are
combined together to form a loop block. A step loop, as a screen object, is simply a series of field rows that
appear as a repeating block. There are 2 types of step loops
1)Fixed Size 2)Variable Size..
In a fixed size loop the number of loop blocks shown in the screen is fixed,while in case of variable size
step loop the number of blocks will change dynamically
according to the size of the screen.There could be only one variable step loop per screen and unlimited fixed
size step loops per screen.
A step loop can extend more than one line on the screen(see Table Control).A vertical scroll bar is
automatically created to show step loops on he screen.
Step loops have no name. We use LOOP ...ENDLOOP to program step loops in a screen in both PBO and
PAI.
Since the number of loop blocks in variable step loops can change the number of loop blocks at any moment
is placed by the system in system field SY-LOOPC
and the current step loop pass number is placed in system field SY-STEPL .
Loop Type attribute is used to specify the type of step loop and Loop Count attribute is used to specify the
number of step loop blocks that will be displayed on the screen at a time.
We use two flavours of LOOP ... ENDLOOP in screen flow logic to program the step loops.We have to
program both in PBO and PAI so that transfer of data can take place between screen and abap program.
1) LOOP
MODULE fill_data
ENDLOOP.
here in PBO a module should be called that will transfer the data to the
screen fields. In PAI the module call is not required only the empty LOOP..ENDLOOP will do or we can call
a module to write the data to an internal table.In this method there is no automatic scrolling we have to
program it in ABAP.
2) LOOP AT int_table [INTO wa ][CURSOR line_number][FROM n1 TO n2]
ENDLOOP.
Here in PBO a module call is not required to fill the step loop screen fields as the data is copied to the
workare wa and from there to screen fields in step loop automatically. INTO wa is not required if we use the
int_table declared with a header line.
In PAI the addition AT int_table is also required for automatic scrolling.
The parameter CURSOR line_number which is of TYPE I is used to specify
the that will be the first to be displayed,it is filled in the ABAP program.
But from a programming point of view, TABLE CONTROLS and STEP LOOPS are almost exactly the
same.
NOTE:
1) It is preferable to use TABLE CONTROL instead of STEP LOOPS.
2) It is preferable to use LOOP AT int_table instead of plain LOOP..ENDLOOP.
Steploop and table contol is inevitable in certain transactions. When we run BDC for such transactions, we
will face the situation: how many visible lines of steploop/tablecontrol are on the screen? Although we can
always find certain method to deal with it, such as function code 'NP', 'POPO', considering some extreme
situation: there is only one line visible one the screen, our BDC program should display an error message.
(See transaction 'ME21', we you resize your screen to let only one row visible, you can not enter mutiple
lines on this screen even you use 'NP')
I find a method with which we can determine the number of visible lines on Transaction Screen from our
Calling BDC program. Maybe it is useless to you, but I think it will give your some idea.
Demo ABAP code has two purposes:
1. how to determine number of visible lines and how to calculte page number;
(the 'calpage' routine has been modify to meet general purpose usage)
2. using field symbol in BDC program, please pay special attention to the difference in Static ASSIGN and
Dynamic ASSIGN.
Now I begin to describe the step to implement my method:
(I use transaction 'ME21', screen 121 for sample, the method using is Call Transation Using..)
Step1: go to screen painter to display the screen 121, then we can count the fixed line on this screen, there is
7 lines above the steploop and 2 lines below the steploop, so there are total 9 fixed lines on this screen. This
means except these 9 lines, all the other line is for step loop. Then have a look at steploop itselp, one entry of
it will occupy two lines.
(Be careful, for table control, the head and the bottom scroll bar will possess another two fixed lines, and
there is a maximum number for table line)
Now we have : FixedLine = 9
LoopLine = 2(for table control, LoopLine is always equal to 1)
Step2: go to transaction itself(ME21) to see how it roll page, in ME21, the first line of new page is always
occupied by the last line of last page, so it begin with index '02', but in some other case, fisrt line is empty
and ready for input.
Now we have: FirstLine = 0
or FirstLine = 1 ( in our case, FirstLine is 1 because the first line of new page is fulfilled)
Step3: write a subroutine calcalculating number of pages
(here, the name of actual parameter is the same as formal parameter)
global data:
FixedLine type i, " number of fixed line on a certain screen
LoopLine type i, " the number of lines occupied by one steploop item
FirstLine type i, " possbile value 0 or 1, 0 stand for the first line of new
" scrolling screen is
empty, otherwise is 1
Dataline type i, " number of items you will use in BDC, using DESCRIBE to get
pageno
type i, " you need to scroll screen how many times.
line
type i, " number of lines appears on the screen.
index(2) type N, " the screen index for certain item
begin
type i, " from parameter of loop
end
type i. " to parameter of loop
*in code sample, the DataTable-linindex stands for the table index number of this line
if FirstLine eq 0.
pageno = DataLine div vline.
if pageno eq 0.
pageno = pageno + 1.
endif.
elseif FirstLine eq 1.
pageno = ( DataLine - 1 ) div ( vline - 1 ) + 1.
midd = ( DataLine - 1 ) mod ( vline - 1).
if midd = 0 and DataLine gt 1.
pageno = pageno - 1.
endif.
endif.
line = vline.
endform.
Step4 write a subroutine to calculate the line index for each item.
form calindex using Line type i (visible lines on the screen)
FirstLine type i(see step 2)
LineIndex type i(item index)
changing Index type n. (index on the screen)
if FirstLine = 0.
index = LineIndex mod Line.
if index = '00'.
index = Line.
endif.
elseif FirstLine = 1.
index = LineIndex mod ( Line - 1 ).
if ( index between 1 and 0 ) and LineIndex gt 1.
index = index + Line - 1.
endif.
if Line = 2.
index = index + Line - 1.
endif.
endif.
endform.
Step5 write a subroutine to calculate the loop range.
form calrange using Line type i ( visible lines on the screen)
DataLine type i
FirstLine type i
loopindex like sy-index
Step6 using field sysbol in your BDC, for example: in ME21, but you should calculate each item will
correponding to which index in steploop/Table Control
form creat_bdc.
field-symbols: , , .
The naming standard of function modules for function module exits is:
EXIT_ <3 digit suffix>
The call to a functionmodule exit is implemented as:
CALL CUSTOMER.-FUNCTION <3 digit suffix>
For Example:
The program for transaction VA01 Create salesorder is SAPMV45A
1. If you search for CALL CUSTOMER-FUNCTION program SAPMV45A you will find ( Among
other user exits):
CALL CUSTOMER-FUNCTION '003'
exporting
xvbak = vbak
xvbuk = vbuk
xkomk = tkomk
importing
lvf_subrc = lvf_subrc
tables
xvbfa = xvbfa
xvbap = xvbap
xvbup = xvbup.
The exit calls function module EXIT_SAPMV45A_003
2. How to Find User Exits
Display the program where you are searching for and exit and search for CALL CUSTOMEREXIT
If you know the Exit name, go to transaction CMOD. Choose menu Utillities->SAP
Enhancements.
Enter the exit name and press enter.
You will now come to a screen that shows the function module exits for the exit.
or use this ABAP program to search for user exits :Finding the user-exits of a SAP transaction code
3. Using Project management of SAP Enhancements
You want to create a project to enhance transaction VA01
- Go to transaction CMOD
- Create a project called ZVA01
- Choose the Enhancement assign radio button and press the Change button
In the first column enter V45A0002 Predefine sold-to party in sales document . Note that an
enhancement can only be used for 1 project. If the enhancement is allready in use, and error
message will be displayed
- Press Save
- Press Components. You can now see that enhancement uses user exit EXIT_SAPMV45A_002.
- Double Click on the exit.
Now the function module is displayed. Double click on include ZXVVAU04 in the function
module
Insert the following code into the include: E_KUNNR = '2155'.
Activate the include program. Go back to CMOD and activate the project.
Goto transaction VA01 and create a salesorder. Note that Sold-to-party now automatically is
"2155"
How many types of reports are there in ABAP and what is the difference between them.
There are 2 type of reports. They are:
1. Interactive report
2. Classic reports
In classic reports,we can see the output in single list where as in interactive reports we can
see the output in multiple list.
Classical
Interactive
Logical Database
ABAP query