The new implementation of API CRM_PRODUCT_SALES_READ_API in S4 will consume CDS view to get product sales related data from S4 table.
There are two approaches: with or without application buffer.
Approach1: directly consume CDS view without buffering in application
The sample code would be:
Pros: simple logic, easy to maintain
Cons: potential performance loss for a large data volume if API is called multiple times in the same session? At least in CRM WebUI where opportunity and lead application will still be used in codeployment system, it is possible for all those API to be called in the same session repeatedly.
Approach2: add an application layer buffer
Pros: avoid unnecessary CDS view read request
Cons: if attributes in buffer comes from different CDS views, the buffer invalidation logic tends to be more complex. Difficult to maintain.
How much performance benefit we can gain from buffer approach
In ER9, I have a test CDS view which is built on MARA consisting of 109.791 entries:
I use two different methods to read data from this CDS view, one with buffer approach and the other one without.
In each method, the CDS view is read 100 TIMES with two given product types:
Test result
Approach with buffer is 40~ 50 times faster than the one without buffer. However, this read is done based on a large data volume as test set. In real WebUI use scenario, the data set is far smaller.
This performance test needs to be done again based on a kind of test data which is similar as the data used in real world.
“As my understanding, this buffer is independent on the database layer, it’s in the application layer. Is that right?”
Answer by Jerry : Yes, it is independent on Database layer. However, it is NOT in application layer as well. We as application developer can NEVER have any control on it.
It is on Netweaver system layer, see picture below:
“If my understanding is right, the CDS view buffer can be the substitution of the API buffer?”
Answer by Jerry: No, it depends. We as application developer should still design application layer buffer.
One sentence to summarize: table buffer - no matter for normal DDIC table or CDS view - should ONLY be switched on for those whose content are rare to change, and the number of total table entries are not so large - for example configuration table or system table.
For application table whose entries are frequently changed and table content are huge, the buffer must be turned off. Otherwise the expensive SAP memory are easily exhausted and system performance is dramatically degraded due to buffer synchronization overhead.
Compare the buffer setting below for application table and configuration table:
figure1: buffer switched off for application table
figure2: buffer switched on for configuration table
