LSMW

[Former Member]

WHAT IS DIFFERNCE BETWEEN LSMW AND BDC.IF EVERYTHING IS POSSIBLW IN LSMW WHY WE GO FOR BDC?

[Former Member]

WHAT IS DIFFERNCE BETWEEN LSMW AND BDC.IF EVERYTHING IS POSSIBLW IN LSMW WHY WE GO FOR BDC?

[jayanthi_jayaraman]

Hi,

"The Data Transfer Workbench (or DX Workbench, transaction SXDA) is an integrated SAP tool that supports data transfer and analysis. It

does not have the built-in features for mapping for source structures to target structures, but it will allow you to integrate Legacy System Migration Workbench (LSMW) objects as processing tasks within a run definition. The DX workbench has many features for creating

test data and performing data migrations - for example, logging of data migration runs.

However, if you need to map or convert data, you should use the LSMW. Or, you can integrate

your LSMW objects as task within a more user-friendly data migration run, in which the LSMW

project steps "Read data", "Convert data," and "Start IDoc processing" are automated

and use the features of both tools. If you donot need logging and automated data migration

runs, you can perform your data migration without the DX Workbench."

The following was taken at this site :

http://www.info-sun.com/docs/wp_sapinter.pdf

“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 doesn’t 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.

Remote Function Call (RFC) in SAP R/3 is based on UNIX’s Remote Procedure Call (RPC). RFC enables the real-time link between different R/3 instances and can connect SAP to Non-SAP systems. With Remote Function Call, both inbound (RFCServer) and outbound (RFCClient) interfaces are possible.

SAP also provides a toolkit called RFC API for non-SAP systems to interact with SAP’s Function modules remotely.

RFC is a very powerful tool for interfacing with SAP system in real time. Most other interfacing techniques like ALE, EDI, BAPI etc… are

inherently based on the RFC technology.

Electronic Data Interchange (EDI) is the industry standard format for exchanging Business data. SAP uses a neutral format called Intermediate Document

(IDoc) for communicating EDI & ALE messages.

The IDoc interface contains data structures and processing logic for each of the business transaction. These are grouped as Message

Types. The external EDI Server is responsible for receiving the EDI messages sent by the trading partners. These EDI messages are then

mapped onto the IDoc structure fields and stored in the IDoc interface layer by SAP.

EDI/IDoc supports both inbound and outbound interfaces. The IDocs received through the EDI Server can be configured to automatically get

processed, or can be stored in the IDoc interface layer for a future manual or scheduled processing. The IDoc interface layer also has a powerful error

handling, reporting, monitoring and reprocessingmechanism built into it (Transaction WEDI). IDoc is also tightly integrated with the WorkFlow system

of SAP for initiating other business tasks upon receiving/sending EDI messages.

The IDoc interface can be employed for non-SAP applications to load or extract data from SAP system. But typically, EDI / IDoc is engaged when

SAP system is to be integrated with any of its business partners (Customers, Suppliers and other partners) for carrying out standard business

transactions (like Create Sales orders, Sending Purchase orders to Suppliers, etc…).

Application Link Enabling (ALE) is a middleware tool, which is part of SAP’s Business framework Architecture (BFA). ALE can effectively be used

for loosely coupled Asynchronous communication between SAP systems and with non-SAP systems. ALE is based on the distributed processing

architecture and hence integrates applications with the local database rather than centralized one. ALE messages are based on the Intermediate

Document (IDoc) format, similar to the EDI counterpart. Though ALE can be used to interface with non-SAP systems, usually it is used to

distribute Master & Transactional data between SAP R/3 instances.

The ALE distribution can be based on,

• Business APIs

• IDoc Message Types"

Business API (BAPI) is the most important component of SAP Business Framework. BAPI enables SAP and third party applications to interact and integrate

with each other at the Business Object / Process level.

[Former Member]

Hi,

The Legacy System Migration Workbench is a tool for data migration, most often used when migrating from non-SAP to SAP systems.

It supports various input methods such as BAPIs, BDC, direct input and others. You can think of the LSMW a "frontend" for those techniques. SAP has defined many objects and BDC recordings beforehand in order to simplify the migration process.

Unfortunately the LSMW does not offer solutions to every data input program, so it might be necessary to create your own BDC recording or enhance existing ones. The LSMW can help you there.

Hope that helps (please reward me if it does

Joerg

[Former Member]

hi All,

Iam new to this portal, and i can't find where i hafe to post new query, so iam posting here...

LSMW:DIRECT INPUT:MM01.

i created one template with test data, according to mm01 with all views. But views can be differ when we are selecting the views. so that iam not able to upload the test data properly and getting errors. One more problem is industrial sector char is 4. But in intial screen already some data is exist. If we give 4 char in test data, it is not uploading and also showing error, Please all help me regarding this...

thanks and regards

Partha Sarathi

[hymavathi_oruganti]

hi the main difference between lsmw and bdc, we can tell is

LSMW can do both inbound and outbound processing.

where as with BDC, only inbound processing is possible.

[Former Member]

hi,

LSMW and BDC are vastly different.

BDC (Batch Data Communication) is a technology used for data transfer. it is meant for transferring data thru SAP transactions itself. when u use BDC for data transfer, the sequence of steps is the same as when u use standard sap transaction screens for data upload. the only difference is that u can use different options for foreground/background processing.

LSMW on the other hand is a tool that helps migrate data from a legacy system (non-sap system ) to SAP system. it offers u various options to use either batch input, direct input, BAPIs or idocs. it involves a series of some 17-18 steps to migrate data.

lsmw is fully screen navigation & no code is used where as bdc , we write codes to migrate data from legacy sys to sap sys.

lsmw is a tool for automatic mapping after mapping the corresponding data we have to go for the interface method such as bdc.

regs,

jaga