LSMW

LSMW – Legacy System Migration Workbench

LSMW-The tool supports conversion of data of the legacy system in a convenient way. The data can then be imported into the R/3 system via batch input, direct input, BAPIs or IDocs. In this wiki we will use the LSMW to Update Customer Master Records with Transaction Recording. The LSM Workbench is an R/3-based tool that supports You when transferring data from non-SAP systems ("Legacy Systems") to R/3 once or periodically.The tool supports conversion of data of the l egacy system in a convenient way. The data can then beimported into the R/3 system via batch input, direct input, BAP Is or  IDocs. Furthermore, the LSM Workbench provides a recording fun ction that allows to generate a "datamigration object" in an entry or change transaction. Significance of Data Migration Data migration comes in the end of R/3 implementation. At this time, the R/3 system is normally installed and application customizing is finished (in the best case). An examination of R/3 implementation projects by SAP Consulting has shown that data migration is about 20% of the total implementation expenses. This portion may rise up to 40% in smaller implementation projects. A significant reduction of the expenses for data migration results in a corresponding significant reduction of the total project budget and the project runtime. The first experiences with the LSM Workbench in R /3 implementation projects are very promising:Both the expenses and the costs of data migration could be reduced significantly. The LSM Workbench was developed on the basis of the following principles: *Most of the functions should reside in R/3. No collection of individual programs on different platforms. *The quality and consistence of the data imported into R/3 should be more important than speed and  performance of data migration. *Existing knowledge and coding should be used. *The developed "mapping" and rules should be reusable and thus be used repeatedly in projects. The main advantages of the LSM Workbench:  - Part of R/3 and thus independent of individual platforms - A variety of technical possibilities of data conversion: - Data consistency due to standard import techniq ues: - Batch input - Direct input

- BAPIs (Business Application Programming Interfaces) - IDocs (Intermediate Documents) The import technique to be used in an individual case depends on the business object. * Generation of the conversion program on the basis of defined rules * Clear interactive process guide * Interface for data in spreadsheet format * Creation of data migration objects on the basis of recorded transactions * Charge-free for SAP customers and SAP partners Preconditions

The LSM Workbench is a tool that supports data transfer from non-SAP systems to R/3. The main functions of the LSM Workbench are: 1. Import data (legacy data in spreadsheet tables and/or sequential files) 2. Convert data (from source format to target format) 3. Import data (into the database of the R/3 application)

Concepts What are acronyms BDC, BI, BTC, BTCI, CTU, LSMW? BDC

Batch Data Collection. It's the name of the SAP technology used to record and play transactions automatically. There are 3 ways to execute BDC: BI sessions, CTU, CDU.

BI

Batch Input. It has the same meaning as BDC. The BI session is one of the 3 ways to run the BDC technology. Note: remember that BI may also me an Business Intelligence which is not related to B atch Input at all

BTCI

Batch Input. It has the same meaning as BDC.

CDU

CALL DIALOG ... USING ... ABAP statement. CA LL DIALOG is obsolete. It's one of the 3 wa ys to run the BDC technology.

CTU

CALL TRANSACTION ... USING ... ABAP statement. It's one of the 3 ways to run the BDC technology.

LSMW Legacy System Migration Workbench. It allows using the BDC recorder and the BI sessions.

What are the differences between CTU and BI session?  Note: Batch input sessions have other functions not listed here (like keep session, etc.) because we just discuss of the BDC technology here.

Call Transaction Using

Batch Input Session

It is saved to database via ABAP function modules The BDC data is run via ABAP BDC_OPEN_GROUP, BDC_INSERT, BDC_CLOSE_GROUP, and is statement CALL TRANSACTION ... later run by SM35 transaction, or by programs RSBDCBTC or  USING ... RSBDCSUB. Internally, it does not execute CTU but the kernel  program BDC_START_GROUP Only one transaction is called

Several transactions can be recorded in one session

The ABAP program must do the error  There is a built-in error and recovery mechanism in SM35 to view the handling itself (note: CALL log of errors and run the erroneous transactions again (note: the BDC TRANSACTION statement returns the data cannot be corrected) messages in an internal table) By default, standard size is not used

By default, standard size is used (22 lines * 84 columns) Since 7.0, the dates and numbers can be always interpreted correctly during execution, by indicating in which format they are stored in the BDC data when you open the BI session It's possible to define SY-CPROG in PROG parameter of  BDC_OPEN_GROUP function module

Update mode can be chosen

Update mode is always Synchronous (cf SAP Library)

You may use RACOMMIT of  CTU_PARAMS to not stop the BDC at the COMMIT WORK 

Transaction execution always stops at COMMIT WORK 

SY-BINPT can be set to space using  NOBINPT of CTU_PARAMS

SY-BINPT value is always X

As SY-BINPT is reset to 'X' after  COMMIT WORK, it can be set to 'X' again using NOBIEND of  CTU_PARAMS

Doesn't apply as BI session always stop after COMMIT WORK 

Option CATTMODE of  CTU_PARAMS can be used All display modes can be used, including P and S

All display modes can be used except P and S Extended log, Expert mode, Cancel if log error occurs

What are the differences between BDC and LSMW? 

 

 

 

LSMW is a loading tool provided by SAP where ABAP code is automatically generated based on the entered rules, and where the loading method can be BI session (either based on a LSMW recording or on a standard batch input program), BAPI/IDoc or standard direct input program. LSMW is not able to generate a CTU program, only a BI session. You can enter custom ABAP in LSMW without need of a developer license, while you need one for  writing a "BDC" ABAP program. LSMW is generally for standard SAP applications, while BDC is mainl y for any customized application The LSMW recorder is much simplified when compared to the SHDB recorder: it always start with default options (update mode A, no default size, use BDC mode (SY-BINPT is 'X'), do not simulate  background mode (SY-BATCH is space), and SY-CALLD is set to 'X'). LSMW recordings can't be migrated to SHDB recordings and vice versa. In LSMW recording, BDC_OKCODE and BDC_CURSOR fields cannot be edited, and you can't delete or add screens.

Recording (SHDB) How do I record a Batch Input session for later playback and analysis? Using transaction SHDB it is possible to record transactions as well as create skeleton programs that contain all the necessary code for creating batch input sessions.

Why SHDB didn't record some screens? There was probably a COMMIT WORK. By default, the recording stops after COMMIT WORK (for more information, read Note 24141 - Program terminates on COMMIT WORK ). When you start the recording, you have a checkbox "not possible, but anyway it makes no sense to transport them: the recordings have no vocation to remain in the system, and are usually converted into programs or function modules, which are cross-client.

How to copy a recording? 1. Display the recording 2. There is a button to export to a file on your presentation server  3. Create a recording without transaction code and without starting the recorder, a button to import is then displayed  Note that recordings are client-dependent.

How to transport a recording? It's not possible, but anyway it makes no sense to transport them: the recordings have no vocation to remain in the system, and are usually converted into programs or function modules, which are cross-client.

How does recording work? It works the same as CTU with Display Mode "A", but it's surrounded by kernel calls to SET_TRANS_VAR  for activating and deactivating the recording: among o ther things, before CTU, there are call 'SET_TRANS_VAR' id 'RECORDING' field 'X' and CALL 'SET_TRANS_ VAR' ID 'ACTIV' FIELD 'X', and after CTU, there is call 'SET_TRANS_VAR' id 'RECORDING' field ' '. Th e main function module for  recording is BDC_RECORD_TRANSACTION, which returns the BDC data. The SHDB recorder records the BDC data into APQI and APQD tables. LSMW recorder uses this same technology, but saves the BDC data into /SAPDMC/LSGBDC* tables.

What is the Simulate Background mode? It is available when you record a transaction. Refer to the Display mode chapter in Batch Input - BDC.

Overview

BDC stands for Batch D ata Communi cation and is also referred to as Batch Input. It is a te chnique for mass input of data by simulating user inputs in screens o f existing transactions. Screens are not displayed, it can be run in the background. You do not bypass any of the standard SAP consistency checks, authorizations, etc. BDC was a great way of uploading data into SAP in a pre-BAPI era, now SAP is making available BAPIs for  most of the functionalities, some one should first look out for BAPI if it is not available then go for BDC. Other  methods of update include direct update SAP programs and IDocs. There are two main methods of BDC, these are:  

Call Transaction Using (CTU) Batch Input Session (BI session) See the FAQ below to know the differences between CTU and BI session methods .

Both must be programmed in an ABAP program. First do a recording of the transaction using SHDB transaction, see SAP Library - Transaction recorder . Then embed the recording into your program, then trigger  it by using either CTU or BI session method. The CTU method requires to use CALL TRANSACTION statement, see ABAP documentation - CALL TRANSACTION. The BI session method requires to call BDC_OPEN_GROUP, BDC_INSERT and BDC_CLOSE_GROUP function modules, and end them with a COMMIT WORK, then start manually the BI session using SM35 transaction (see SAP Library - Managing Batch Input Sessions, or start it automatically by calling either  RSBDCSUB or RSBDCBTC program. For snippets of code, see wiki Sample codes for BDC methods - CTU and BI session.

Display mode 



CTU: either CALL TRANSACTION ... USING ... MODE ..., or ls_ctu_params-dismode = . CALL TRANSACTION ... USING ... OPTIONS FROM ls_ctu_params ... BI session: you can choose it only by running the session interactively (SM35), a popu p dialog is displayed with many options.

dismode

Meaning

 N

Screens are not displayed. You must choose this mode when you run the BDC in a background job.

A

All screens are displayed. On each screen, a little popup is displayed with the next recorded function, the user has to press Enter to execute it.

E

By default, screens are not displayed, except if an error occurs, or if the end of BDC data is reached although the recorded transaction was not exited

P

Same as N. The difference is that if a breakpoint is reached and the classic debugger is used, then P will avoid the error 00344 concerning screen SAPMSSY3 0131 (or other SAPMSSY3 screen). For  more information, see Note 72551 CALL TRANSACTION USING and DEBUGGER . Since the new debugger has been introduced, mode P is more or less obsolete

Others

Like A

Since SAP WAS 6.10, there are 4 additional execution modes, for more information seenote 433137 - Batch input: Simulating background mode:

dismode

Meaning

Q

Same as N + the execution is run with SY-BATCH = 'X'

D

Same as A + the execution is run with SY-BATCH = 'X'

H

Same as E + the execution is run with SY-BATCH = 'X'

S

Same as P + the execution is run with SY-BATCH = 'X'

Update mode It indicates how the function modules in the update task will be run. 



CTU: either CALL TRANSACTION ... USING ... UPDATE ..., or ls_ctu_params-updmode = . CALL TRANSACTION ... US ING ... OPTIONS FROM ls_ctu_params ... BI session: you can choose it only by running the session interactively (SM35), a popup dialog is displayed with many options.

updmode

Meaning

A

Asynchronous. Update function modules are executed in UPD workprocess. A is the default mode.

S

Synchronous. Update function modules are execut ed in UPD workprocess BUT all COMMIT WORK are processed as if they were COMMIT WORK AND WAIT.

L

Local update task. Update function modules are executed as if SET UPDATE TASK LOCAL has  been executed at the start of each LUW, i.e. they are executed in the same workprocess as the main  program.