Whenever you migrate your data from one system to another using the Legacy System Migration Workbench (LSMW), it helps to have guidelines to use as a template to develop or enhance your own LSMW implementation. In developing your guidelines, it is good to know the best practices for developing LSMW scripts, knowing when to use LSMW over traditional Batch Data Communication (BDC) programs (also known as ABAP BDC programs), and much more. Where do you begin?

My aim is to help you get the most out of your LSMW objects by providing best practices for developing LSMW scripts that are easy to support and use. These best practices provide guidance on when to use LSMW over traditional BDC programs. I discuss why you should implement LSMW development standards and what should be included in these standards. Finally, I review LSMW configuration options that will help you add flexibility to your scripts and make them more user friendly.

The concepts discussed in this article apply to LSMW version 4.0. To view the LSMW version in your system, use transaction LSMW and follow menu path Extras > Display LSMW version. Note that throughout this article I refer to executable LSMW objects as LSMW scripts.

LSMW is a comprehensive data import tool that supports four different data import methods. You can set the Import Method for an LSMW object from the Maintain Object Attributes Process step. As shown in Figure 1, the LSMW-supported import methods, are:

• Standard Batch/Direct Input
• Batch Input Recording (BIR)
• Business Object Method (BAPI)
• Intermediate (IDoc) Document

As I discuss various configuration aspects of LSMW, I am referring to all four LSMW data import methods except where noted.

Figure 1

Set the data import method for your LSMW Object

Don’t think of LSMW as simply a tool to load master data. You can also use LSMW to load data into configuration tables in your sandbox or development system. For example, this is commonly used in the Benefits area to load postal code information.

You may encounter a problem using the same LSMW script in your sandbox or your development system. This problem is caused by the fact that you are required to assign your changes to a configuration transport number in your development system, and the screen sequence recording you created in the sandbox system probably does not include the transport pop-up screen. You do not need to modify your recording to get around this problem. Instead, you can solve this issue by creating the first table entry in your development system by hand. The system does not prompt you again for a transport number once you have specified a transport number for the table changes. You can then use your LSMW script to create the rest of the table entries.

When Should I Use LSMW Instead of BDC Programs?

A traditional BDC program allows users to build a customized data load process to meet their specific data import needs. Most users are familiar with the traditional BDC data import method. One of its strengths is that you can perform the data selection using a logical database or a similar data selection method. There are, however, a number of advantages to LSMW over BDC programs:

• You can develop LSMW scripts faster than most BDC programs
• LSMW developers do not need a developer’s key
• Developers do not have to write ABAP code if they do not want to
• Managing LSMW authorizations is easier because access is restricted based on the LSMW project name. Therefore, LSMW users automatically receive access to new objects if they are already authorized to access the object’s project.

Despite these strengths, not every data load scenario is a good fit for LSMW. It is a good fit for data load scenarios when the data to be loaded has clearly been identified. In other words, somebody in your organization can provide a document, such as a spreadsheet, with the exact data to be loaded. The reason for this is that LSMW reports do not provide a selection screen that helps you select the employees to be processed (e.g., identify and process all employees belonging to a particular personnel area).

Should I Convert My BDC Programs to LSMW?

LSMW users often wonder whether it is necessary to migrate all of their traditional BDC programs to LSMW. Each tool has its own strengths and weaknesses so you need to analyze each conversion scenario individually to identify the conversion tool that best fits each situation.

Before you can perform a meaningful evaluation between LSMW and any other conversion methods, you must first answer the following question: How long (on average) does it take your team to develop an LSMW script? You may want to include not only the time spent on development, but also the time spent on testing and security changes. The reason for including testing and security tasks in this timeline is that testing time for LSMW is usually shorter than for a traditional BDC because much of the processing (such as retrieving data from a file) uses standard functionality instead of custom code.

Additionally, if you are simply adding a new LSMW object to an existing LSMW project, then there would be no need for security role changes (assuming the new LSMW object uses the same transaction to load the data as existing LSMW objects in the same project).

You can use the following guidelines in combination with your own requirements to determine the best scenarios to use LSMW over other data load methods:

• The load does not require data selection criteria, such as identifying employees based on their master data
• The amount of time it would take to load the data by hand over a certain period of time (such as one year) is greater than the time it takes to create an LSMW
• The data load must be completely accurate and occur within a short time frame
• You already have a traditional BDC program to load this data, but the program is no longer working and fixing the program would take longer than creating a new LSMW

If there is an existing traditional BDC program to perform the data load and the program is performing well, then I would recommend you keep using it.

The Need for Your Own LSMW Standards

All ABAP development teams create ABAP Workbench development standards to ensure the quality, consistency, and usability of the development work. These workbench standards are communicated to all developers, and in turn they must ensure their development work adheres to these standards. LSMW objects are in fact conversion programs. Therefore, it would be wise to develop standards for this kind of work as well. Developing and following LSMW standards not only ensures the quality of the work but also helps you create a consistent look and feel for your LSMW scripts. This makes these objects easier to support. Additionally, it makes it easier for a user to execute a script even on first-time use.

A document for LSMW standards should include guidance on the following areas:

• Naming convention for the LSMW project, subproject, and object. For example, the project can represent an HR module, the subproject can represent an infotype, and the object can represent the subtype.
• Whether or not scripts should support all visible fields on the screen being maintained even if the immediate need is to load data for a few fields. Ideally you would want to support as few scripts as possible so it would be best to have scripts that support all fields on an infotype screen instead of having large numbers of specialized LSMW scripts. You should not include hidden fields in your LSMW because the system issues warnings when executing the Run Batch Input Session step of the data load.
• Whether there are certain mandatory fields every script should have. For example, you can require that the structure for all scripts for Personnel Administration loads start with the following fields: Personnel Number, Begin Date, and End Date.
• Whether or not to use wild cards on the file name (Figure 2). You can use wild cards to prevent data from being loaded into the wrong system. You could, for example, set the wild card to denote the system to which you want to load your data. This would help prevent errors such as loading sample data into a production system.
• The file location for data to be loaded. You can work with your infrastructure team to set up a folder in a shared drive with the proper security settings. This helps ensure the data is secure yet easily accessible to anyone with the proper access.
• A naming convention for the data files. For example, the data files should use the same name as the LSMW’s object plus the wild card value.
• Whether or not a script should have a template file that contains the script fields as well as one or more sample data rows. You should also make sure all templates are stored in the same file location for easy access.

By developing and enforcing LSMW standards, you can have scripts that are easily supported and have a consistent look and feel.

Figure 2

Stipulate the location of your data files and set the various values

One of the strengths of LSMW is that scripts are easy to create. That makes it easier for anyone with access to LSMW to create their own scripts. Allowing too many people to develop their own LSMW scripts can pose a problem, however, because it makes it difficult to enforce LSMW standards. Therefore, you may want to consider limiting the number of people who can create LSMW scripts. Alternatively, you could implement a process to review LSMW scripts before they are moved to the QA or production systems.

One of the first questions a script developer must answer before developing a new LSMW object is whether to create the object on an existing LSMW project or to create a new project. To answer this question, the developer should take into consideration company-specific requirements as well as the following two items:

• Security access to LSMW scripts is controlled based on the project name. Hence, it makes sense to group together infotype data loads that closely resemble end-user segregation of duties access. For example, including master data and Payroll infotypes on the same project could cause problems because this could cause a segregation of duties conflict.
• All of the LSMW objects belonging to the same LSMW project can share the project’s reusable objects such as fixed values, translations, user-defined routines, and recordings. Therefore, by using fewer LSMW projects you reduce the number of reusable objects you must create or maintain.

Transporting Projects

You can transport LSMW configuration between SAP systems via the standard SAP transport system as well as via a download/upload process. The download/upload process allows you to download the objects assigned to an LSMW project to a file that can then be used to upload the LSMW project on a different system.

Even though it is tempting to simply use the download/upload process as the main method for transferring LSMW projects between systems, you should be aware of some potential pitfalls of this method.

• This method does not transport certain IDoc configuration settings
• It is not possible to trace the transport of LSMW scripts. This makes it impossible to audit configuration transports.
• It is too easy to make a mistake when transporting only parts of an LSMW project because the user could inadvertently delete existing objects. Additionally, it would be easy to transport scripts that are not ready for production (e.g., test scripts).

Therefore, you may want to use the download/upload process on a limited basis and use the standard SAP transport system as your main transport method. I do not believe there is a way to switch off the upload/download option.

Useful Configuration Options

A number of LSMW configuration options can help you add flexibility to your scripts and make them more user friendly. Three specific configuration options that help you get the most out of your scripts are:

• The Selection Parameter flag on the source field configuration
• Global variables
• Global functions

Let me explain these configuration options in detail, starting with the Selection Parameter setting. This option allows you to configure the source fields assigned to your import structure so that they are available as a selection parameter on the Read Data and Convert Data processing steps. For example, if you are using LSMW to load employee master data, then you could make the Personnel Number field a Selection Parameter field (Figure 3). This allows you to test the data conversion process using specific personnel numbers contained in your data file.

Figure 3

User-defined selection parameters

You can include your own selection parameters on the Read Data or Convert Data processing steps (available in the LSMW process step screen) by setting the Selection Parameter for “Import/Convert Data” flag. You can access the Selection Parameters configuration by selecting the Maintain Source Fields LSMW configuration step. You must access this step in maintain mode. Double-click the field you want to add to the selection screen. On the Change Source Field pop-up window, select the Selection Parameters for “Import/Convert Data” check box at the bottom of the screen (Figure 4).

Figure 4

Configure the source field

The Selection Parameter source field configuration allows you to include user-defined selection parameters on the Read and Convert data programs.

LSMW provides a number of global variables you can access in your LSMW scripts (Table 1). Global variables are SAP fields that provide information on the current LSMW process. You can, for example, include the record number in your error message text. This makes it easier for users to find these errors in the data file. You can access the global variables from the Maintain Field Mapping and Conversion Rules configuration screen. Double-click a target field to access the coding screen, and then follow menu path Insert > Global variable.

LSMW also delivers seven functions you can integrate in the LSMW data conversion step (Table 2). Functions are SAP-delivered routines you can use to perform certain activities. For example, you can use function skip_record if you find an error in a data load record and do not want to process that record.

You can access these functions from the Field Mapping and Conversion Rules screen. Double-click a target field to access the coding screen, and then follow menu path Insert > Global functions.

As with any implementation, for your LSMW implementation to make a difference you must make sure to communicate and enforce the guidelines you have created. Make sure all interested parties are aware of them and fully understand them. Additionally, you must ensure that new LSMW development work adheres to these guidelines.

Manuel Gallardo

Manuel Gallardo is the director of HCM consulting at /N SPRO. He is a former SAP platinum consultant and his area of expertise is SAP HCM enterprise architecture, SuccessFactors, and enterprise mobility. Since working on his first SAP implementation in 1994, he has also worked on a wide variety of SAP HR modules, as well as SAP NetWeaver Portal and ABAP development. Manuel is the author of Configuring and Using CATS, and is a frequent conference speaker.

You may contact the author at manuel.gallardo@n-spro.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.