Transaction Locking during multiple Webservice - persistent webs sessions

[Former Member]

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:

Message was edited by:

Joris Verberckmoes

[AndreasHuppert · Accepted solution]

You can't lock. Web Services are stateless.

[Former Member · Accepted solution]

Idd, that is the problem.

But what would be a good workaround ... how can we at the service level create the statefull behaviour or should we just not use webservices for this. If no webservices, what should we use then .... .

[AndreasHuppert · Accepted solution]

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.

[AndreasHuppert · Accepted solution]

Oh and by the way: you can never be shure which strategy other clients are using. So always assume that other clients use "Last one wins"

[Former Member · Accepted solution]

Hi Andreas,

I understand your strategies, but I don't think they will be sufficient for certain customers... .

If we want to compose an GUI application like SAP GUI or create an application like CRM ISA using the ESA model, which provides things like locking, separation between saves and commits, rollbacks, etc ... . , we will need more intelligence. We need to provide the customers the same functionality as they are used to now.

Does this means that webservices are not the way to go for my case ... ? Can we only create primitive application using webservices? We can build a shelf around it, but that cannot be the goal of ESA... .

Kind regards

Joris

[AndreasHuppert · Accepted solution]

On the other hand, stateless services are easier to handle. Not every service consumer wants to think about such things as locks, commits and rollbacks. If transaction handling is not done properly, then it's easy to block the server (e.g. by forgetting to unlock).

So ESA services are better suited for easy process integration or to facilitate building of applications, not UIs. That's the ESA goals as described in the published documents.

[Former Member · Accepted solution]

ok Andreas,

Thanks for the input!

Kind regards

Joris

[Former Member · Accepted solution]

hi,

you could create your own persistent lock service if none of the above mentioned strategies is sufficient. just create your own table and a lock/unlock service operation; call the lock operation for your business object, put a reference into your custom table together with timestamp, user, whatever necessary then call the update service; unlock it afterwards.

create a clean-up loop-back service to release "forgotten" locks or just let the 'lock checker' consider locks to be valid only if they are no older than xx minutes.

cleverly designed you can easily create a generic lock/unlock service capable to handle different objects.

combined with the above metionend strategies you'll most likely achieve whatever you need in various scenarios.

my 2 cents,

anton

[ivo_robbrecht3]

Joris,

I'm faced with the exact same scenario, but for CATSDB.

What approach did you end up choosing?

Ivo