Skip to Content

Let me start this blog by first defining what logical locking means:  Logical locking is mechanism provided by SAP to prevent concurrent user access to same data:

  1. A Locked table entry is not physically locked in the database table.
  2. A table entry can be locked irrespective of its physical existence in database.
  3. SAP lock needs to set explicitly by application programmer for effective data consistency during transaction processing.

To be able to place a lock you need a lock object which is common knowledge but what might be surprising is that SAP allows you to create lock objects on ABAP dictionary structures also same as you create for a tables. When you create lock object using ABAP dictionary structure SAP lets you use all field of structure to be defined as lock parameters which gives you the power of locking based on just any data during the program execution. This means that you are no longer restricted to have a data field part of table’s primary key to place a lock based on it.

Lately I happen to realize this power when one of my colleague, who was developing a custom data entry transaction, walked up to me with a weird requirement that “One user should be able to run only one instance of the transaction (say ZVA1) at a time and other attempts to run this transaction in any other session by same user should not be allowed but other users should be able to run it in a single session”.

To achieve above functionality it is obvious that you need to place a write lock based on the logged in user but user name was not part of primary key in custom table and requirement did not allow user name as part of key field. So all you need to do is to create an ABAP dictionary structure with fields required for locking and generate lock object for this structure and use in the program.

In this blog I will show the steps to achieve solution for this requirement:

To start with I will create a new ABAP dictionary structure with two fields on which I want to place lock as shown below in Figure 1:

Figure 1

Now let’s create the lock object for this structure:

Figure 2 

Now move to next tab “lock parameter” which will display all fields from structure that you provided in primary table name.

Figure 3

Now save and activate this lock object so that you can call it in the program where you want to implement locking concurrent access of user to same transaction. Once activated ENQUEUE and DEQUEUE modules are generated:

Figure 4

Now just call the enqueue FM at the beginning of the transaction by passing the SY-UNAME in USERNAME and SY-TCODE in TCODE and your job is done. In my example I called it in first PBO module.

Figure 5

Now execute your transaction (ZVA1 in my case):

Figure 6

Now execute it in another session:

Figure 7

And you will receive error message, I have used the standard message returned by ENQUEUE FM but you can give you own custom message for more clarity:

Figure 8 

On pressing enter key or clicking on exit button a blank screen will be displayed. But you can login with another user and you can again run this transaction once in single session.

All the views provided here are my personal opinions and based out of my experience with ABAP and do not necessarily reflect my employer’s. Please treat the inputs in this blog as just opinions and you should definitely seek professional expertise and opinion before making your business decisions.

To report this post you need to login first.

2 Comments

You must be Logged on to comment or reply to a post.

  1. Naimesh Patel
    We should always use the Locking for business document.

    For your particular requirement, you can use the FM TH_USER_LIST to read the current active sessions for the Users. READ the table USRLIST with user name and transaction code to check how many sessions are active for the TCODE for an user.

    Regards,
    Naimesh Patel

    (0) 
    1. Gaurav Bharadwaj Post author
      Business document should be locked or not while processing is not a point made in this blog. The intention in this blog is talk of possibility of different use of lock objects.
      To your second point FM TH_USER_LIST cannot be for this requirement as this FM returns you uses list as you see in SM04 whereas what actually you need is the list of all sessions opened by user as user might work on multiple transactions at a time. But here even SM50 list will not suffices as you need TCODE also for the example in blog.
      In this blog the example I quoted is just one possibility but there can be various use of generic lock objects created on structures.
      (0) 

Leave a Reply