Differences between various technologies in SAP
 Bapi and Badi
BAPI
BAPI is an interface which helps
the extenal world to communicate
with R/3 via OOPS Programming.
BAPI is technology of aplication
interface.
 BADI and Customer-exit
BADI
Business Add-Ins are a new SAP
enhancement technique based on
ABAP Objects.
Badi’s allow for a multi-level
system landscape (SAP, partner,
and customer solutions, as well as
country versions, industry
solutions, and the like). Business
Add-Ins can be created at each
level within such a system
infrastructure
Some BADI can have multiple
independent implementations
which is much better for software
deployment as several developers
can implement the same BADI
independently.
 Batch Data Communication methods
Call Transaction method
In this method, the ABAP/4
program uses the call transaction
<T-code > using <bdc_tab> mode
<mode> update <update >
method.
In ‘Call Transaction’, the
transactions are triggered at the
time of processing itself and so the
BADI
BADI is used to enhance R/3 For customer
Needs.
Business Add-Ins are a new SAP
enhancement technique based on ABAP
Objects.
Customer-exit
CUSTOMER EXITS(enhancements) are
FUNCTIONS so they are called using CALL
FUNCTION (or more exactly CALL CUSTOMER
FUNCTION
customer exits assumes a two-level
infrastructure (SAP and customer solutions)
Customer-exit implemented in one project
cannot be implemented in other.
Classical or session method
In this method, ABAP/4 program read the
external data that is to be entered to the SAP
system and stores the data in the batch input
session.
When the prgm has finished creating the
session, we can run the session thro the TC
SM35. This method involves FM like
BDC_OPEN,BDC_INSERT,BDC_CLOSE
Whereas in Batch Input Sessions, the ABAP
program creates a session with all the
transactional data, and this session can be
ABAP program must do the error
handling.
Synchronous Processing
We can update the database both
synchronously and
asynchronously. We can specify
the mode in the program.
No batch input processing log
While execution it starts from the
first.
Faster than session method
viewed, scheduled and processed (using
Transaction SM35) at a later time. The latter
technique has a built-in error processing
mechanism too.
Asynchronous Processing
Synchronous Database update.
During processing, no transaction is
started until the previous transaction has
been written to the database.
Detailed Log will be generated for all the
sessions
While executing it wont start from the first. It
will start from the place where it ends with
error.
Not as fast as call transaction method
 IDOCs and BAPIs
IDOC
IDocs are text encoded documents
with a rigid structure that are used
to exchange data between R/3 and
a foreign system
Idocs are processed asynchronously
and no information whatsoever is
returned to the client,
Idocs – by using tRFC – support
guaranteed delivery
With asynchronous links the sub-
process on the client can be finished
even if the communication line or
the server is not available. In this
case the message is stored in the
database and the communication
can be done later
The disadvantage of asynchronous
links is that the sub-process on the
server can not return information to
the calling sub-process on the
client. A special way for sending
information back to the client is
required. In addition, a special error
handling mechanism is required to
handle errors on the receiving side.
IDOCs may
be more changable from release to
release.
IDOCs are poorly
documented
BAPI
BAPIs are a subset of the RFC-enabled
function modules, especially designed as
Application Programming Interface (API) to
the SAP business object, or in other words:
are function modules officially released by
SAP to be called from external programs.
BAPIs are called synchronously and (usually)
return information
whereas for BAPIs the client code needs to
do the appropriate error handling.
Problems with synchronous links occur if the
communication line or the server is
temporarily not available. If this happens,
the sub-process on the client can not be
finished (otherwise there would be data
inconsistencies).
Synchronous links have the advantage that
the sub-process on the server can return
values to the sub-process on the client that
has started the link.
BAPIs are not totally immune to upgrades
BAPIs are reasonably well documented
 ALE and EDI
ALE
SAP has provided ALE (Application
Link Enabling) to distribute
applications across several SAP
systems and also between SAP and
external systems.
For eg : if we send the purchase
order via ALE to another R/3 system,
then the receiving system will store
the purchase order also as a
purchase order.
 User-exits and Customer-exits
User-exits(modifications)
EDI
EDI is described as the interchange of
structured data according to agreed
message standards between computer
systems, by electronic means. (Electronic
Data Interchange) EDI in other words is a
set of computer interchange standards for
business documents such as invoices, bills,
and purchase orders. EDI(electronic data
interchange) is used send data to an
external partner.
For eg :If we send the purchase order to a
supplier then the supplier will store the
purchase order as a sales order.
Customer-exits(enhancements)
USER EXITS are FORMS and are CUSTOMER EXITS are FUNCTIONS so they
called by SAP standard programs are called using CALL FUNCTION (or more
using PERFORM. exactly CALL CUSTOMER FUNCTION).

Inside the form (user exit) you can Inside a function (customer exit) you can
read and change almost any global only acces your
data from host program. import/export/changing/tables parameters.

User exits are more flexible because Customer exits are more restrictive but you
you have more information to use in are sure any change you can make to any
your code but on the other hand , it parameters will never lead to inconsistency
is very easy to manipulate
erroneously global data and lead the
standard program to a dump or even
to make database inconsistent.
User-exit doesn’t have any In customer-exit we have function-module
classification. exit , screen exit , menu exit

Basically designed For SD module Are available for MM,SD,FI,HR…..Basically

designed for all modules.

User-exits can be written only using No need of access key

access-key

With user-exits the code , the Customer-exits are not wiped during
developer has written will not be upgradation
there for next version unless
modification assistance tool is used
 Alv-grid and Alv-list

Alv-grid Alv-list

When the report is run in When the report is run in background only
background you cannot see the grid the list comes out in the spool
in the spool

to have an editable grid you have to you can make the list editable easily just
create it using objects flagging the field edit in fieldcat table

 SAP Script and Smartforms

SAP Script SmartForm

Scripts are client-dependent Smart-forms are client independent

Multiple page formats are not possible Multiple page formats are possible in
in SAPScripts smartforms

It is not possible to have scripts It is possible to have a smartform without

without main window a main window.

Labels can be created in scripts Labels cannot be created in smartforms.

Scripts doesn’t generate function Smartforms generates a function module

module when activetd when activated.

Scripts are poor in performance Smartforms are faster in performance

We cannot have background logos We can have both foreground and

background logos
 BDC and LSMW

LSMW BDC
lsmw is basically for standard sap BDC is basically for customized
application applications
in lsmw mapping is take care by sap in bdc we have to give mapping concept
exlicitly