cancel
Showing results for 
Search instead for 
Did you mean: 
Read only

Server-Side Cache

Former Member
0 Likes
431

Hey guys! Being an ABAP developer for almost 8 years, I'm having a good time learning SAP Netweaver Gateway.

I'm not sure if this is a very basic question, but here it goes: Am I able to cache entries retrieved from backend inside my service runtime artifacts, so I don't have to access the DB every time my service is called?

When I first started reading about Gateway, I understood that I wouldn't be able to it. One of the RESTful services principles is "Stateless Communication", which means no session state is held by the server, therefore server-side data caching wouldn't be possible.

But as I started learning about $top, $skip and paging, I wondered if there's any way to cache data on server-side, as some service calls could result in really large amount of data being fetched from the backend (like BSEG table). Imagine browsing BSEG for page 1, then 2, then 3, then 1 again, and so on... That triggered my "Performance Issues Alert", and that's why I raised this question. I found some stuff about server-side paging, but I couldn't understand how to implement such thing...

Like I said, I'm very noob regarding Gateway, so forgive me if this doesn't make any sense at all

Thanks!

- Mauricio

View Entire Topic
Former Member
0 Likes

Hi Mauricio,

You can do server-side caching of sorts, but it would rely on you providing the majority of the components.

With regard to $top, you can make sure that a minimum $top is used if not requested, and that any $top requested is within a reasonable limit. That handles the size of the feed at the origin point.

For paging position, you use $skip. The simplest way to implement $skip is to go to origin then read data until you hit the $skip region - but not performant, as you know.

However, you can use $skiptoken, which is a temporary key that will tell the server where to resume reading from if the client sends it with the next GET. The effectiveness of this method depends on the abilty to parcel the source data into paging sets that don't require a lot of processing to fill.

I've not used this myself as I've not yet had any practical services where there could be runaway massive queries, but look into $skiptoken.

I'll also mention that I've done caching solutions for mobile data before Gateway was on the scene, by storing query results into a shared memory object. That might be another option until SoftState arrives.

Cheers

Ron.