Transaction Locking during multiple Webservice - persistent webs sessions

Question

Hi All,<br>
<br>
Yesterday evening we had a discussion concerning ESA architecture. We want to create (web)services for accessing the SAP business objects (using XI) and use these (web)services via visual composer, webdynpro or custom java development.<br>
<br>
It does not seem a big problem to perform creations and reads of transaction, but when we want to change objects, we saw some problems concerning locking/commiting and rollbacks.<br>
<br>
From our GUI we would like to be able to go in edit mode and from that moment on, the transaction should be locked. We then want to change certain parameters and commit only when we push the save button.<br>
<br>
We can invoke a webservice wich tries to lock the transaction, but at the moment the XI scenario is completed (=the lock is created), the program at SAP side (=proxy in our case) is also finished and the lock is automaticly removed. How can we do locking, when using webservices via XI?<br>
<br>
The problem of the rollback and commit we can partially solve by putting more logic in the GUI, but we don't want to do that. How can we do a change of a business object and remember this change without doing a commit on the SAP system.... . Same problem for the rollback.<br>
<br>
Is there a away to keep a session "alive" during multiple webservice calls or to simulate it? Every webservice invokation happens in a different context...isn't it?<br>
<br>
<br>
<b>Just to make it a bit more clear.</b><br>
<br>
Suppose we create 6 service related to the business object bupa (business partner).<br>
- read<br>
- change<br>
- commit<br>
- rollback<br>
- lock<br>
- unlock.<br>
<br>
We create a GUI which uses these services.<br>
<br>
<b>Step1:</b> we want to see bupa in detail, so the read webservice is called and the retrieved details are shown in the GUI<br>
<b>Step2:</b> we want to go in edit mode, so the lock webservice is called to lock the bupa. The bupa should stay locked, untill the unlock is called. Here occurs the problem. The webservice lock is called, XI will trigger the proxy on the SAP system. This proxy will lock the bupa. As soon as the proxy-program is completed, the bupa lock will automaticly be removed ... . We want to keep this lock!<br>
<b>Step3:</b> we change the bupa using the change webservice. Only the user who locked the bupa should be able to change it.<br>
Problem concerning the locking occurs: standard we don't know who locked the bupa (this is done by the generic RFC user, configured in sm59). Should we pass some kind of GUID towards the proxy and build some additional logic to know which end-user in fact locked it... . Using the userid isn't sufficient, because a user could logon multiple time simultanously.<br>
<br>
Another problem is that we want to change the bupa, without having to do a commit yet.De commit should be called only when pushing the save button. When the proxy is ended and we did not do a commit, the changes are lost normally ... .<br>
<br>
What we in fact want to do is Simulate the bsp behaviour.<br>
<b>Step4:</b>We want to perform a save of the things we changed or a reset. This means the commit or rollback webservice is called.<br>
<b>Step5:</b> We want to unlock the bupa by calling the unlock webservice.<br>
<br>
<br>
Please give me your comments.<br>
<br>
Kind regards<br>
Joris<br>
<br>
Note: Transaction Locking during multiple Webservice "sessions".
Message was edited by:
        Joris Verberckmoes

Answer 1

There are multiple strategies how to resolve this. They require that the last change time is available in the changed object, and also that the client keeps the value of the change time when it read the data.
1. First one wins
Immediately before posting the changes, the current change time is read from the server. In case it is different from the client buffer, then the client changes are discarted.
Example:
1. Client A reads data
2. Client B reads data
3. Client B changes its buffer
4. Client B checks if server change time has changed (result is no)
5. Client B writes his changes to the server
6. Client A changes its buffer
7. Client A checks if server change time has changed (result is yes)
8. Client A discarts its changes
2. Last one wins
Easy. Client just writes his changes to the server, overwriting any changes that might have occured since it read the data.
Example:
1. Client A reads data
2. Client B reads data
3. Client B changes its buffer
4. Client B writes his changes to the server
5. Client A changes its buffer
6. Client A writes its changes to the server -> changes from client B are lost
3. Everybody wins
Most complicated. In case of concurrent changes, the client is responsible for merging his changes with the changes from other clients and to resolve any conflicts.
Example:
1. Client A reads data
2. Client B reads data
3. Client B changes its buffer
4. Client B checks if server change time has changed (result is no)
5. Client B writes his changes to the server
6. Client A changes its buffer
7. Client A checks if server change time has changed (result is yes)
8. Client A merges its changes with changes from client B
9. Client A writes his changes to the server
"Last one wins" is definitely not water-proof. But even with the other strategies, data can potentially get lost in the short timeframe when the change time is checked and the actual update.
To make it more secure, server support is required. E.g. the client could pass the change time from its read access to the server. The server can then reliably reject the update if the change data has been updated in beetween by another client.