on 2014 Feb 28 3:04 PM
Hi all,
In typical RESTful web applications it is possible to access the HTTP Request object, the HTTP Session object etc. Typically you use them in your service implementation. Just to give you an example: with Jersey (a common REST lib for Java) you can simply inject the Http Servlet Object with @Context HttpServletRequest. There are many reasons why you might need to access the request object, but also the response object etc (but that's ouf of scope for this discussion).
I am currently trying to find more about handling of concurrent access. The following gives you a good idea of how to apply ETags in your Gateway application: http://scn.sap.com/thread/3298520
What we actually want is to migrate our SessionID based locking mechanism from an old BSP application to our new Gateway services. The problem is now that there is no way to access the Http Request or Htp Session in the service implementation, is that correct? We need a real locking mechanism, ETags are not enough. In other words: we need pessimistic locking!
My idea for solving this would be creating a Lock entity, a corresponding Locks entity set + service implementation. The Lock entity would contain fields like sessionId, userId, lockTimeStamp, lockedObjectId, entityName etc. Before editing an Entity the client application (in our case a simple SAPUI5 application) would have to create a Lock for any given entity first and when pressing the save button the Lock would be deleted (Lock creation + deletion via Gateway services for the Lock entity mentioned above). When creating a Lock the SAPUI5 application has to retrieve the current sessionID from the cookie and pass it to the create service.
1. What do you think?
2. Are there any best practices for pessimistic locking of Gateway entities?
3. Wouldn't it be a good idea to have the possibility to access the Http Request etc. inside the service implementation, especially for the UPDATE service implementation (feature request)?
Cheers,
Nabi
Yes, As I understand you cannot get http request or http session at data provider class. But if you want the http request headers use below code inside your *DPC class. But this would not work in *DPC_EXT class since mo_facade is private .
DATA: lt_client_headers TYPE tihttpnvp,
lt_client_headers = mo_facade->get_request_header( ).
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
69 | |
13 | |
11 | |
10 | |
9 | |
9 | |
6 | |
6 | |
5 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.