Differences between LSMW and BDC

Batch Data Communication (BDC) is the oldest batch interfacing technique that SAP provided since
the early versions of R/3. BDC is not a
typical integration tool, in the sense that, it can be only be used for uploading data into R/3 and so it is
not bi-directional.
BDC works on the principle of simulating user input for transactional screen, via an ABAP program.
Typically the input comes in the form
of a flat file. The ABAP program reads this file and formats the input data screen by screen into an
internal table (BDCDATA). The
transaction is then started using this internal table as the input and executed in the background.
In Call Transaction, the transactions are triggered at the time of processing itself and so the ABAP
program must do the error handling.
It can also be used for real-time interfaces and custom error handling & logging features. Whereas in
Batch Input Sessions, the ABAP
program creates a session with all the 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.
Batch Input (BI) programs still use the classical BDC approach but doesnt require an ABAP program
to be written to format the
BDCDATA. The user has to format the data using predefined structures and store it in a flat file. The
BI program then reads this and
invokes the transaction mentioned in the header record of the file.
Direct Input (DI) programs work exactly similar to BI programs. But the only difference is, instead of
processing screens they validate
fields and directly load the data into tables using standard function modules. For this reason, DI
programs are much faster (RMDATIND - Material Master DI program works at least 5 times faster)
than the BDC counterpart and so ideally suited for loading large volume data. DI programs are
not available for all application areas.
LSMW is an encapsulated data transfer tool. It can provide the same functionality as BDC infact much
more but when coming to techinical perspective most the parameters are encapulated. To listout
some of the differences :

LSMW is basicaly designed for a fuctional consultant who do not do much coding but need to
explore the fuctionality while BDC is designed for a technical consultant.

LSMW offers different techinque for migrating data: Direct input ,BAPI,Idoc,Batch input
recording. While bdc basically uses recording.

LSMW mapping is done by SAP while in BDC we have to do it explicitly .

LSMW is basically for standard SAP application while bdc basically for customized
application.

Coding can be done flexibly in BDC when compared to LSMW

BAPIs
Definition
A Business Application Programming Interface (BAPI) is a precisely defined interface
providing access to processes and data in business application systems such as R/3.
BAPIs of SAP Business Object Types
BAPIs are defined as API methods of SAP business object types. These business object
types and their BAPIs are described and stored in the
Business Object Repository (BOR). A BAPI is implemented as a function module, that is stored and
described in the Function Builder.
BAPIs of SAP Interface Types
As of Release 4.5A BAPIs can also describe interfaces, implemented outside the R/3
System that can be called in external systems by R/3 Systems. These BAPIs are known
as BAPIs used for outbound processing. The target system is determined for the
BAPI call in the distribution model of Application Link Enabling (ALE).
BAPIs used for outbound processing are defined in the Business Object Repository (BOR)
as API methods of SAP Interface Types. Functions implemented outside the R/3 System
can be standardized and made available as BAPIs. For further information see
BAPIs Used For Outbound Processing.

Integration
BAPIs can be called within the R/3 System from external application systems and other
programs. BAPIs are the communication standard for business applications. BAPI
interface technology forms the basis for the following developments:

Connecting:

New R/3 components, for example, Advanced Planner and Optimizer (APO) and

Business Information Warehouse (BW).

Non-SAP software
Legacy systems
Isolating components within the R/3 System in the context of Business Framework
Distributed R/3 scenarios with asynchronous connections using Application Link

Enabling (ALE)
Connecting R/3 Systems to the Internet using Internet Application Components

(IACs)
PC programs as frontends to the R/3 System, for example, Visual Basic (Microsoft)
or Visual Age for Java (IBM).

Workflow applications that extend beyond system boundaries

Customers' and partners' own developments

The graphic below shows how BAPI interfaces enable different types of applications to be
linked together.
BAPIs - Interfaces to the R/3 System

For further background information on BAPIs refer to the document

BAPI User Guide.

usiness Application Program Interfaces allow developers to

integrate third-party software into SAP's R/3 product. Consultants
who have clients with SAP systems must be familiar with BAPIs
and their role in an ERP system.
SAP R/3 is typical of enterprise platforms in that it forces its users to reconceptualize the
way information is used in a company. Integration and data transport become the
keywords, and data ceases to be treasure in the vaultit becomes a living thing, flowing
through the company like water.
Think of the pre-ERP universe as a series of small lakes, some connected, some not.
Each lake (company) is filled with data. Occasionally, boats venture from the shore to the
middle of the lake for some data. Occasionally, one of these boats transfers data from
one lake to another.

With the advent of ERP, a canal systemSAP R/3is installed. A vast network of
bidirectional waterways takes the place of the lakes. Small, powerful ships and barges
populate these waterways, keeping data in constant motion.
For the SAP consultant, IDocs are the barges. And Business Application Programming
InterfacesBAPIsare the small, powerful ships that keep these barges of data
moving.

First in a series
This is the first installment in a series that examines the significance of Business
Application Programming Interfaces, how to use them, and their role in designing
applications.

Building canals for the client

An understanding of how SAP changes the structure of a business is the first conceptual
step in becoming an effective SAP consultant. A solid knowledge of SAPs data-handling
mechanisms, of which BAPI is the most central, is the first practical step.
BAPI is the most powerful tool in the SAP consultants toolkit. Think of a BAPI as a
business objectsay, a master record, such as a client profile, or a transactional record,
such as an invoice. Its easy to confuse a BAPI with an IDoc (another central SAP data
transport feature). The difference is that IDocs are about moving data between systems
or modules; BAPIs are about calling data in and out of SAP in the first place.
Their place in SAP and your toolbox
SAP R/3 arrives with a bundle of BAPIs ready for your immediate use. There are several
hundred of them, in categories such as accounting, human resources, and logistics.
They perform a vast array of functions, from creating jobs in SAP to launching IDocs,
from posting sales orders to changing passwords, from listing employee benefits to
tracking a shipment. They can be used out of the box or modified to create new business
objects specific to your clients needs.
BAPI is one of a set of tools at your disposal for interfacing with an SAP R/3 system. Its
important to understand its role among them, and to have an idea of what each does in
relation to the other.
SAP Assistant

This stand-alone program is, in essence, the toolbox you carry with you as a hands-on
SAP consultant. Its contents give you access to SAP R/3s objects. All the information
you need for setting up remote function calls from outside SAP is found here. Most
importantly, SAP Assistant holds your set of keys to SAPs business objects, allowing
you access to whats there, and enabling you to create what you need (see Figure A).

Figure A

Where BAPI fits in among SAP automation components

Remote Function Calls

BAPI is ultimately a mechanism for getting data out of SAP R/3. If a BAPI is a ship
pushing a barge (data), the engine of that ship is a Remote Function Call (RFC). An RFC
is a function module in a system that is called from some other system. This, of course,
covers a great deal of ground. The two systems can both be SAP, or they can be
different platforms, or an RFC may be used on the spot in real time by any party making
an inquiry of an SAP system from the outside (including you, sitting at your laptop).
How do RFCs relate to BAPIs? An RFC is the means by which the business object
represented by a BAPI is implemented. A BAPI is a business object; an RFC is

functional code.
The Business Object Repository
A great deal goes on in the Business Object Repository (BOR), and you must know it
well. Its not overstating the case to say that the BOR is the core of SAP. If an SAP R/3
system can be described as the animation of otherwise lifeless data, the BOR describes
the living cells of this new body. Cells come in many different types, and thats what the
BOR holds: all the different types of data comprising an SAP system of databases.
The BORs contents essentially define the implementing companys business model.
The information it holds includes the definitions of all business objects internal to the
company, as well as the defining information of all interfaces to other companies.
Another new language
BAPI is, like many aspects of SAP R/3, another new lexicon of concepts, terms, and
tools a consultant must absorb to be effective. However, it will rapidly be clear to even a
less experienced consultant that these concepts are firmly rooted in the object-oriented
methodology that is now every IT professionals stock-in-trade.
It is critical that you, as an SAP consultant, understand the dynamic nature of data
handling in an SAP environment, the manner in which this mutates business processes,
and most importantly, the way in which BAPI and related tools interface with this new,
living database. Once you understand these concepts, the hands-on skills to create
applications become simple.
IDocs are simple ASCII data streams. When they are stored to a disk file, the IDocs

are simple flat files with lines of text, where the lines are structured into data fields.
The typical structured file has records, each record starting with a leading string that
identifies the record type. Their specification is stored in the data dictionary.
IDocs is the acronym for Interchange Document. This indicates a set of (electronic)
information which builds a logical entity. An IDoc is e.g. all the data of a single
customer in your customer master data file, or the IDoc is all the data of a single
invoice.
IDoc data is usually exchanged between systems and partners that are completely
independent. Therefore, the data should be transmitted in a format that can easily be
corrected by the computer operators. It is therefore mandatory to post the data in a
human readable form.
Nowadays, this means that data is coded in ASCII format, including numbers which
are sent as a string of figures 0 to 9. Such data can easily be read with any text editor
on any computer, be it a PC, Macintosh, UNIX System, S/390 or any internet
browser.
The information which is exchanged by IDocs is called a message and the IDoc is
the physical representation of such a message. The name messages for the
information sent via IDocs is used in the same ways as other EDI standards. .
Everybody who has ever dealt with interface programming, will find IDocs very
much like the hierarchical data files used in traditional data exchange.

International standards like the ODETTE or VDA formats are designed in the same
way as IDocs are.
Other EDI standards like XML, ANSI X.12 or EDIFACT/UN are based on a data
description language. They differ principally from the IDocs concept, because they
use a programming language syntax (e.g. like Postscript or HTML) to embed the
data.

RFC
A remote function call (<b>RFC</b>) is the call of a function module that runs in an external system
to the calling program. Although it is also possible to call a function module in the same system as an
RFC, normally RFCs are used when the caller and the called function module do not run in the same
system.
ALE
The <b>ALE (Application Link Enabling)</b> concept available in R/3 (Release 3.0) supports the
development of applications across different SAP systems. It incorporates the exchange of business
information across these systems whilst ensuring consistency and integrity of the data. This
functionality is achieved with the use of Idocs (Information Document) as opposed to the use of a
centralised database.
BAPI
<b>BAPI</b>
At the encapsulated heart of the SAP Business Framework stand
Business Objects and the beloved BAPI (Business Application Programming
Interface). Non-R/3 applications never manipulate a Business
Object directly. It is always done indirectly, via BAPIs. In effect,
BAPIs are a developers window to the wonderful world of R/3. All
object data intended for usage outside R/3 must be passed through these
specific methods on SAP Business Objects. It is through this standard
that SAP enforces stable interfaces to the business logic that is encapsulated
by SAP Business Objects.

RFC means remote function call,

these are the function modules which can help u to access across the sap and from sap to
third party front end,

IDOC means intermediate document, which can help u to carry the data from sap to nonsap.
this is two types,
one is ALE,
and second is EDI.
ALE uses to tranfer the data across sap systems
where as EDI uses to transfer the data from sap to third party front end.
BAPI means Business application programing interface which is the RFC enable function
module and uses in OOPS concept.

Explain to me about Idoc?

IDoc (for intermediate document) is a standard data structure for electronic data interchange
(EDI) between application programs written for the popular SAP business system or between
an SAP application and an external program. IDocs serve as the vehicle for data transfer in
SAP's Application Link Enabling (ALE) system.
IDocs are used for asynchronous transactions: Each IDoc generated exists as a selfcontained text file that can then be transmitted to the requesting workstation without
connecting to the central database.
Another SAP mechanism, the Business Application Programming Interface (BAPI) is used
for synchronous transactions.
A large enterprise's networked computing environment is likely to connect many
geographically distributed computers to the main database. These computers are likely to use
different hardware and/or operating system platforms. An IDoc encapsulates data so that it
can be exchanged between different systems without conversion from one format to another.
IDoc types define different categories of data, such as purchase orders or invoices, which
may then be broken down into more specific categories called message types. Greater
specificity means that an IDoc type is capable of storing only the data required for a
particular transaction, which increases efficiency and decreases resource demands.
An IDoc can be generated at any point in a transaction process. For example, during a
shipping transaction process, an IDoc may be generated that includes the data fields required
to print a shipping manifest. After a user performs an SAP transaction, one or more IDocs are
generated in the sending database and passed to the ALE communication layer. The

communication
layer performs a Remote Function Call (RFC), using the port definition and RFC destination
specified by the customer model.
The IDoc is transmitted to the receiver, which may be an R/3, R/2, or some external
system.
*-- Ashok
What are the main advantages if IDOC?
IDoc is the data Format used by the SAP in data transfer using ALE /EDI methods. They
provide more data security. An IDoc is an intermediate document used to send data in two
ways, that is internal and the external point for you.
In BW, IDoc is a transfer mode, when you create a Infosource you can select the transfer
mode as PSA or IDOC. Its the method provided for backward compatibility. In older version
the hirerchies where loaded using IDOC transfer method. Now its possible with PSA but still
that method is available to load the hierarchies.
An example in SD:
For creating sales documents (sales order) through IDOCS you will have to use the T code
WE19. In that click basic type and enter order05(IDOC type) and select via message type
then enter ORDERS(message type), click execute.
You will get to see many fields.here you have to enter the datas that you enter in the VA01
screen in order to create sales order. The datas such as material name, date, qty, P.O no etc.
After entering all the datas, you click standard inbound the IDOC would be created by the
system.You can see the created order by going in to VA03 screen.
Next time when you create the IDOC, in same tcode WE19 screen, click existing IDOC and
enter the IDOC which you created in the above step and just change the P.O no.Sytem will
create new sales order through new IDOC
Before doing all you need to maintain the partner profile in T code WE20. For this Discuss
with EDI consultant.