Locking records for update in backend system?

[Former Member]

Sofar I have only used Web Dynpro for viewing data and inserting new data.

Now it is time for me to use some BAPIs for changing data.

What is the recommended way to update existing records?

To clarify what I am looking for:

Something like SELECT FOR UPDATE.

When I do a BAPI_*GetDetail I will get data that is presented to the user. I would like to lock that record, so that when the user has updated the data and has pressed submit, the update BAPI and the commit will release the record, so that other users can work with that very record.

If I don't do any locking, there is a risk that the following scenario becomes true:

1. User A retreives the record and starts to update the record on the screen.

2. User B retreives the same record and starts to update the record on the screen.

3. User A presses submit, the record is updated.

4. User B presses submit, the record is updated and all the changes that A made has been overwritten by B, even the ones that B didn't change.

[Former Member · Accepted solution]

Hi Lars

If you dont do a locking then all your points holds true.

As per your scenario there are 2 possibilities

Possibility 1 : User A is viewing and editing the data and is going to update. At this time User B logs in then you may either allow B to view the data or say that User A is already viewing the data and inform B that he cannot change the record at this moment of time.

Possibility 2: User A is viewing and editing the data and is going to update. At this time you still would want to allow B to view the data and inform B about the locking only when B also tries to update the data at the same time.

To implement locking you will have to use Enqueue and Dequeue functions in SAP respectively . You can either implement them in the RFC while saving or while displaying the data.

Depends on how you would like to do your locking.

Hope that clarifies your doubt. Let me know if you require some more information.

regards

ravi

[Former Member · Accepted solution]

Can I use Enqueue and Dequeue from Web Dynpro without doing any changes in the backend system?

For instance by calling a BAPI_Enqueue(...)?

I will be disappointed if I have to do a customization in every SAP backend system that I want to have access to with BAPI_Change calls.

[Ulli_Hoffmann · Accepted solution]

Hi Lars,

running web dynpro java against an abap backend, there are certain restrictions/limitations to consider:

enqueue and dequeue have to be called in the same session. Therefor, using separate bapi_* calls won't work. You have to do all the steps in one and the same rfc:

1) enqueue

2) save

3) dequeue

This implies that you can't lock an object, do some changes and release it, i.e. pessimistic locking doesn't work. You are limited to optimistic locking. The only way around this is to forget all this tedious java handling and develop your web application on the abap engine using bsp or web dynpro abap (as soon as it is available).

regards, Ulli

[Former Member · Accepted solution]

Hi

It should mostly work. But Enqueue and Dequeue are not Remote function modules. You will have to create a "Z_<Program" and then call these 2 FMs as and when you require.But you could have a problem with different sessions. For locking you would require the same session I havent tried it though.

By the way are you developing in webdynpro as well as the abap. Even if you do a Enqueue and Dequeue from Webdynpro you will have to create the lock objects right. What advantage do you think it is going to give.

We are making calls to enqueue and dequeue within our FM's. I would suggest you make a call from your RFC and handle it in ABAP.

hope that helps you.let me know if you require more information.

regards

ravi

[Former Member]

Hi Lars

There are some points that you need to consider while trying to lock DB tables using the Enqueue Dequeue RFCs. This is mostly in the context of how model objects in Web Dynpro handle RFC connections to backend systems.

->Coupling multiple RFMs in one model object causes the connection to be shared for the calls to those RFMs

->For a lock to persist the RFC connection with which the lock was created should not be used for other calls except dequeue

->Dedicating model objects for each RFM causes a dedicated RFC connection to be maintained for that Model to RFM interaction.

->So for successful Enque and Deque process create a separate but a single dedicated model object for both the RFMs by choosing to import both the FMs while model creation

Check this weblog for some more details on it

/people/sap.user72/blog/2005/01/08/adaptive-rfc-models-in-web-dynprosome-pointers

Regards

Pran