LSMW – Mass User Creation

LSMW – Mass User Creation

LSMW stands for Legacy System Migration WorkBench. Originally it was a tool supplied by SAP to migrate data from a legacy system to SAP. However,  as we will see in this article, it can be used to upload almost any data into SAP. In the present case, we will be creating a lsmw script to create a bunch of user ids, a job which is common for any security administrator. Since lsmw is based on sap BDC (batch-data-communication sessions) we would have to first create a recording to store the entire sequence of actions involved in creating a user, read the user data for a set of users from a data file and use the read data to create a session for user creation. At the final step we would run the session to actually create the users. Though I have taken the example of user creation, by no means should it be assumed that this is the only application of lsmw in security. As long as you can create a recording for a sequence of repetitive actions, lsmw can step in and lighten your load.

To start LSMW we use the transaction “lsmw”.  We start create a project, subproject and object as shown below.

 

Once the project is created we are greeted with the lsmw main screen showing a set of actions needed to create the complete script. Depending on the nature of the script and the data all or some of these option need to be updated.

Step 1 – We start by maintain the object attributes. The most important attribute which needs to be specified is the name of the recording which will be used to create the BDC session.  A recording is basically a set of actions that the script will replicate during executing. We can create a recording from following the menu options in the same screen. In the present case, we create a recoding for the SU01 transaction and fill up the various input fields needed to create a user.

Step 2 – We create a source structure to store the data needed for the script. This will store the user attributes needed by the script.

Step 3 – Next we maintain the data fields in the source structure. In the present case, I have only used the data fields – system id, last name, first name, department, email, user group and password. Nothing is really stopping you from using more or less fields. Note that unless all users use the same roles, it would be difficult to incorporate role addition into the same script.

Step 4 – Next we maintain the structure relations. Since we defined only one structure in our script, we accept the default values suggested and click save.  This single data structure is used as the data source for the recording that is used to create each user.

Step 4: Maintain field mapping between the data structure and the fields used in the recording.

Step 5: In the next screen we can define our own fixed values, translations or routines to be used in the script. In the present script, these options are left unused.

Step 6: In the next screen we define the path and format of the input files which would actually store the legacydata meant to be loaded by the script.  We have used a csv file in the local machine as our data source.

Step 7: Next we assign the data from the file to any of the structures used in the script. The present script uses a single file and a single data structure. So we just accept the default values suggested.

Step 8: Next we import the data from the source file

Step 9: On clicking execute we get the next screen displaying details about the data read. The input file in our case had 33 records for creation of 33 users.

Step 10: We can display the read data to verify that input data has been correctly imported into the script.

Step 11: The next 2 steps are converting imported data and displaying the converted data for verification. Since, we use imported data without change, these options remain unused for our script. Finally we generate the BDCsession for our recording and using the imported data from the source file. Once the BDC session has been successfully generated we use the last screen option in lsmw or transaction SM35 to execute the session. If the recording is without errors and the data is correct, executing of the session will create the 33 users whose attributes were originally provided in the source file.

 

LSMW is very similar to creating a recording through transaction SHDB, generating an ABAP report for the recoding and modifying the generated code to read a source file and use the data to generate a BDC session. A seasoned ABAP developer might prefer this method as custom code provides a greater degree of flexibilty to answer complicated user requirements. However, custom code invariably results in greater maintenance and testing effort. So finally which method you end up following will probably depend on your own special requirements.