Lock SAP transactions using WebDynpro

[former_member185029]

I have a requirement in my project where I need to lock SAP standard transaction for a document number if the same is under process from portal (webdynpro).

We have standard transactions like VL02N where we can enter a document number for processing. Now if we try to process the same document number from portal, it gives message that document number XXXXX has being locked by user XYZ.

We want a vise versa scenario to be incorporated from WebDynpro. I mean if the document number is under process from portal, SAP transaction should get a message that the document number has been locked by portal.

Are there anyways to incorporate this? If yes, could someone please throw light on pros and cons of these kinds of implementations (I mean performance vise or feasibility vise).

Ashutosh Moharir

[RichHeilman · Accepted solution]

Yes, this is a must, and good programming practice. What you need to do is call a function module to lock the particular document when processing from portal. You will need to create custom remote enabled function module with document number as an importing parameter, and maybe an int as an exporting parameter, then in this function module call the function module ENQUEUE_EVVBLKE.

call function 'ENQUEUE_EVVBLKE'
 EXPORTING
*   MODE_LIKP            = 'E'
*   MANDT                = SY-MANDT
   VBELN                = im_vbeln
*   X_VBELN              = ' '
*   _SCOPE               = '2'
*   _WAIT                = ' '
*   _COLLECT             = ' '
* EXCEPTIONS
*   FOREIGN_LOCK         = 1
*   SYSTEM_FAILURE       = 2
*   OTHERS               = 3
          .

Pass the sy-subrc value back thru the exporting parameter. You can then check this value in your webdynpro application, if its not zero, then you can issue the message that the lock failed, if it is zero, you have achieved the lock. This means that if someone from the R/3 side tries to access the document, they will get a message that says the document is locked by portal user. You must make sure to release the lock when your done using the function module DEQUEUE_EVVBLKE, again you will have to wrap it with a RFC function module.

How are you updating the document, using a BAPI? The BAPI will handle the locks for you.

Regards,

Rich Heilman

[former_member185029 · Accepted solution]

Thanks a lot Rich,

I think this is what I was looking for.

Ashutosh

[Former Member · Accepted solution]

I have similar requirement. I need to access a document in change mode from Webdynpro applcation and another user who has accessed the same document should not be able to edit/save his changes before the first user releases the lock.

If i lock the record by calling "EnqueueXXX" function module, How will i release the lock if the user closes the browser using "X" option.?

[RichHeilman · Accepted solution]

Good question, not sure what would happen then, I don't know if there is anything internal to handle "cancelled sessions". I'm thinking that the lock would probably hang out there forever(or untill the admin forces the release)

Regards,

Rich Heilman

[former_member185029 · Accepted solution]

Hi Aditya,

If you are a WebDynpro developer, let an ABAPer worry about this stuff.

I am a WebDynpro developer and what I know is that the locking is not done on WebDynpro side. Its the Remote Function Call that does it for us.

I came to know from an ABAPer that the locking is done timely fashion. I mean you can specify the lock timeout period. Also incase you close your browser without proper logout, the lock times out after some time (need to confirm the time from ABAPer).

Rich, please correct me if I am wrong :).

Ashutosh

[RichHeilman · Accepted solution]

Not sure how this works, if you close out a browser using "X" box, does this tell the ABAP side that the session is done and to release the locks, I don't think so, especially since these requests are coming over RFC. As far as lock duration, a "Time-Out" capibility would defeat the whole purpose, would it not?

F1 help.....

<i>

Lock Duration

When you set a lock, you should bear in mind that if it remains set for a long time, the availability of the object to other transactions is reduced. Whether or not this is acceptable depends on the nature of the task your program is performing.

Remember in particular that setting too many shared locks without good reason can have a considerable effect on programs that work with database tables. If several programs running concurrently all set a shared lock for the same application object in the system, it can make it almost impossible to set an exclusive lock, since the program that needs to set that lock will be unable to find any time when there are no locks at all set for that object. Conversely, a single exclusive lock prevents all other programs from reading the locked object.

At the end of an SAP LUW, you should release all locks. This either happens automatically during the database update, or explicitly, when you call the corresponding dequeue function module. Locks that are not linked to a database update are released at the end of the SAP transaction.

</i>

http://help.sap.com/saphelp_470/helpdata/en/41/7af4c5a79e11d1950f0000e82de14a/frameset.htm

Maybe a study is in order to see the effects.

Regards,

Rich Heilman

[former_member185029 · Accepted solution]

Hi Rich,

The things work in this way..

Every locking has a LUW associated with it.

LUW is something you can relate to session of browsers.

You create new instance of SAP window, it has seperate LUW (even for the same client).

I have tested locking some document numbers using standard function you have provided.

I found that the LUW automatically expires after some time if there are no activities for this document.

The time it took for timeout was nearly 30 minutes.

We are still in process to find out whether this time is SAP standard time or it varies.

Please let me know if you have any inputs on this.

Ashutosh

[RichHeilman · Accepted solution]

If there is a timeout as you stated, it is probably a system value, and if so, I would assume that it would also perform a rollback of any changed data when releasing the lock.

Regards,

Rich Heilman