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 legacy system in a convenient way. The data can then beimported into the R/3 system via batch input, direct input, BAPIs or IDocs. Furthermore, the LSM Workbench provides a recording function 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 techniques: - 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?
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. Batch Input. It has the same meaning as BDC. The BI session is one of the 3 ways to run the BDC BI technology. Note: remember that BI may also mean Business Intelligence which is not related to Batch Input at all BTCI Batch Input. It has the same meaning as BDC. CALL DIALOG ... USING ... ABAP statement. CALL DIALOG is obsolete. It's one of the 3 ways to CDU run the BDC technology. CALL TRANSACTION ... USING ... ABAP statement. It's one of the 3 ways to run the BDC CTU technology. LSMW Legacy System Migration Workbench. It allows using the BDC recorder and the BI sessions. BDC

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 The BDC data is run via ABAP statement CALL TRANSACTION ... USING ... Only one transaction is called The ABAP program must do the error handling itself (note: CALL TRANSACTION statement returns the messages in an internal table) By default, standard size is not used

Batch Input Session It is saved to database via ABAP function modules BDC_OPEN_GROUP, BDC_INSERT, BDC_CLOSE_GROUP, and is later run by SM35 transaction, or by programs RSBDCBTC or RSBDCSUB. Internally, it does not execute CTU but the kernel program BDC_START_GROUP Several transactions can be recorded in one session There is a built-in error and recovery mechanism in SM35 to view the log of errors and run the erroneous transactions again (note: the BDC data cannot be corrected) 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 is always Synchronous (cf SAP Library) Transaction execution always stops at COMMIT WORK SY-BINPT value is always X

Update mode can be chosen You may use RACOMMIT of CTU_PARAMS to not stop the BDC at the COMMIT WORK SY-BINPT can be set to space using NOBINPT of CTU_PARAMS As SY-BINPT is reset to 'X' after COMMIT WORK, it can be set to 'X' again using NOBIEND of CTU_PARAMS Option CATTMODE of CTU_PARAMS can be used All display modes can be used, including P and S

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

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 mainly 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 other 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 ' '. The 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 Data Communication and is also referred to as Batch Input. It is a technique for mass input of data by simulating user inputs in screens of 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 <dismode> ..., or ls_ctu_params-dismode = <dismode>. CALL TRANSACTION ... USING ... 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.

dismode Meaning N Screens are not displayed. You must choose this mode when you run the BDC in a background job. All screens are displayed. On each screen, a little popup is displayed with the next recorded function, A the user has to press Enter to execute it. By default, screens are not displayed, except if an error occurs, or if the end of BDC data is reached E although the recorded transaction was not exited 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 P 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 see note 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 <updmode> ..., or ls_ctu_params-updmode = <updmode>. CALL TRANSACTION ... USING ... 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. Synchronous. Update function modules are executed in UPD workprocess BUT all COMMIT S WORK are processed as if they were COMMIT WORK AND WAIT. Local update task. Update function modules are executed as if SET UPDATE TASK LOCAL has L been executed at the start of each LUW, i.e. they are executed in the same workprocess as the main program.