SHDB – Transaction Recorder

We have already come across LSMW for mass changes to SAP data. Let us not assume that LSMW is the only tool which can be used to update data in SAP. SAP provides quite a few number of tools, each with its unique features, to allow mass updation of data. In the current article I talk about the Transaction Recorder tool which can be accessed through the transaction SHDB. Like LSMW, SHDB is also used to record certain user actions in the SAP GUI for a particular transaction. These actions are used to create a recording which can be processed at a later time to upload data. Through SHDB it is also quite easy to generate an ABAP report from the recording and modify the generated code to read an input file with a list of records and upload the data though the program. In this article I demonstrate the entire sequence of actions though a recording to reset the password of a user through SU01.

We start the transaction SHDB and click the button for new recording. We give an appropriate name for the recording and input the transaction (SU01 in this case) which we are trying to record.

SHDB - New Recording
SHDB - New Recording

On clicking the check button, we are taken to the normal SU01 screen where we rest the password of any user id already created in the system (USER01).

SU01 -  Change Password
SU01 - Change Password

On saving the new password and clicking the back button, we are returned SHDB where we can check the steps in the recording.

SHDB - View Recording
SHDB - View Recording

To test the recording we change the user id to “USER02” and save the recording. Now we can process the recording from SHDB.

SHDB - Process Recording
SHDB - Process Recording

On successful processing for the recording, we get a screen showing that password for USER02 was indeed changed.

SHDB - Final Output
SHDB - Final Output

Although its technically feasible to manually change the data in the recording and process them through SHDB, the generally accepted approach is to generate a program for the recording and update a list of records though ABAP code. SHDB main screen has options to generate a program from recording.

SHDB - Generate Program for Recording
SHDB - Generate Program for Recording

On selecting this option, SHDB prompts us for the attribute details for the program and generates a skeleton code for the recording. We can now update this skeleton code to read data records from a file into an internal table, and loop over each record to update data into SAP. I am not adding the final code in this example but the basic skeleton is given below.

SE38 - View Generated Code
SE38 - View Generated Code

As you can see from the above example, like LSMW, SHDB provides us with another alternate method of upload of data into a SAP system. Which method you finally chose depends a lot on whether you are more comfortable in writing code or creating a the LSMW script.

4 thoughts on “SHDB – Transaction Recorder

  • June 28, 2012 at 7:58 am
    Permalink

    generation of the program, requires Access Key.
    Could the SHDB process be simplified, rather generating Program

    Reply
    • July 2, 2012 at 6:00 am
      Permalink

      Hi Sky fly,

      I think you would need a access key if you are using this method. Any way you will have to modify the generated program so that it can read and process an external text file. If you don’t have an access key try using LSMW or SECATT to get your job done.

      Regards,
      Aninda

      Reply
  • March 28, 2013 at 10:27 am
    Permalink

    Hi Aninda,

    One small question, from the above article, I understand that we would prefer LSMW/SECATT to SHDB due to the access key issue or ABAP coding. Howver, I would like to know, when it would be advicable to use LSMW and when SECATT. Basically, I want a comparison as to which scenario which would be better.

    Thanks,
    Tincy

    Reply
    • April 23, 2013 at 1:08 am
      Permalink

      Hi Tincy,

      It really depends on what you are more comfortable with. Both LSMW and SECATT have their own advantages. For example to run a SECATT script, the client settings should be modified to allow it. On the other hand, with SECATT, its feasible that you store your scripts in a central system and run it via RFC calls in other systems.

      Thanks,
      Aninda

      Reply

Leave a Reply

Your email address will not be published. Required fields are marked *