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.

BADI
BADI is used to enhance R/3 For customer
Needs.

BAPI is technology of aplication

interface.

Business Add-Ins are a new SAP

enhancement technique based on ABAP
Objects.

BADI and Customer-exit

BADI

Customer-exit

Business Add-Ins are a new SAP

enhancement technique based on
ABAP Objects.

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)

Badis 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.

Customer-exit implemented in one project

cannot be implemented in other.

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.

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

In Call Transaction, the transactions

are triggered at the time of
processing itself and so the ABAP

Whereas in Batch Input Sessions, the ABAP

program creates a session with all the

program must do the error handling.

Synchronous Processing

transactional data, and this session can be

viewed, scheduled and processed (using
Transaction SM35) at a later time. The
latter technique has a built-in error
processing mechanism too.
Asynchronous Processing

We can update the database both

synchronously and asynchronously.
We can specify the mode in the
program.

Synchronous Database update.

During processing, no transaction is
started until the previous transaction
has been written to the database.

No batch input processing log

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.

While execution it starts from the

first.
Faster than session method

IDOCs and BAPIs

Not as fast as call transaction method


ALE

IDOC
IDocs are text encoded documents with
a rigid structure that are used to
exchange data between R/3 and a
foreign system

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.

Idocs are processed asynchronously and

no information whatsoever is returned to
the client,

BAPIs are called synchronously and

(usually) return information

Idocs by using tRFC support

guaranteed delivery

Whereas for BAPIs the client code

needs to do the appropriate error
handling.

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

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).

The disadvantage of asynchronous links

is that the sub-process on the server can
not return information to the calling subprocess 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.

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

IDOCs may
be more changable from release to
release.

BAPIs are reasonably well documented

IDOCs are poorly
documented

and EDI

ALE

EDI

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.

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.

User-exits and Customer-exits

User-exits(modifications)

Customer-exits(enhancements)

USER EXITS are FORMS and are

called by SAP standard programs
using PERFORM.

CUSTOMER EXITS are FUNCTIONS so they

are called using CALL FUNCTION (or more
exactly CALL CUSTOMER FUNCTION).

Inside the form (user exit) you can

read and change almost any global
data from host program.

Inside a function (customer exit) you can

only acces your
import/export/changing/tables parameters.

User exits are more flexible because

you have more information to use in
your code but on the other hand , it
is very easy to manipulate
erroneously global data and lead the
standard program to a dump or even
to make database inconsistent.

Customer exits are more restrictive but you

are sure any change you can make to any
parameters will never lead to inconsistency

User-exit doesnt have any

classification.

In customer-exit we have function-module

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

access-key

No need of access key

With user-exits the code , the

developer has written will not be
there for next version unless
modification assistance tool is used

Customer-exits are not wiped during

upgradation

Alv-grid and Alv-list

Alv-grid

Alv-list

When the report is run in

background you cannot see the grid
in the spool

When the report is run in background only

the list comes out in the spool

to have an editable grid you have to

create it using objects

you can make the list editable easily just

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

in SAPScripts

It is not possible to have scripts

without main window

Multiple page formats are possible in

smartforms

It is possible to have a smartform without

a main window.

Labels cannot be created in smartforms.

Labels can be created in scripts

Scripts doesnt generate function

module when activetd

Smartforms generates a function module

when activated.
Smartforms are faster in performance

Scripts are poor in performance

We cannot have background logos

BDC and LSMW

We can have both foreground and

background logos

LSMW
lsmw is basically for standard sap
application
in lsmw mapping is take care by sap

BDC
BDC is basically for customized
applications
in bdc we have to give mapping concept
explicitly