Enterprise Resource Planning Blogs by Members
Gain new perspectives and knowledge about enterprise resource planning in blog posts from community members. Share your own comments and ERP insights today!
cancel
Showing results for 
Search instead for 
Did you mean: 
dmitry_kuznetsov1
Active Participant
Since I am a proponent of using BW queries even directly in S/4HANA Embedded Analytics, I have done some research whether stirring BW objects into the picture has any major down-sides.

There are two major scenarios of virtual data consumption in BW:

  • A BW Query directly on a CDS view with @Analytics.dataCategory: #CUBE. I will call it CDS scenario further in the text.

  • A BW Query on a Composite Provider that has an OpenODS that is based on DataSource that is based on CDS (mentioned above). I will call it HCPR scenario.


We all realize that CDS-scenario is much simpler, robust, extendable, easier to support and so on. But... we have some BW fans amongst us that would maybe like to union the live data with something else like benchmarks, external system data, etc., so we have certainly valid reasons for HCPR scenario.

Before we start doing any modeling, let us just measure if there is a penalty of using the triple-sandwich of BW objects. For the sake of real head-to-head comparison let us eliminate various factors that may influence performance like network time (if we have separate instances), additional data union operations, etc. I take just a plain and simple example of standard BW technical content consumed in two different ways. (Don't blame me for using BW technical content here, it is written in the same ABAP CDS nowadays and works in exact same fashion as S/4HANA CDS views).


So, here we go, 2 queries with exact same set of fields built on top of CDS-view directly on one end and HCPR on the other.

I execute (yes, in RSRT) three very basic tests:

  • Very aggregaed, i.e. just Key Figures and nothing in drill-down

  • Slightly aggregated, i.e. just an Object is in drill-down

  • Full details, i.e. all 10 characteristics are in rows


In addition, I execute it on two very different data-sets, 1 being 20k records, the other – 1,6 mil (filtered to 0,4 mil in Query), so we see if there is growth related to data-volume.

 































Scenario Small data-set Observation Big data-set Observation
Very aggregated

Nothing major, but Data Manager seems taking +45% more time in HCPR case

 

HCPR also implies query regeneration even though I generated it before execution (1/10th of a second)
No major impact
Slightly aggregated

Nothing major, but Data Manager seems taking +25% more time and

OLAP Data Transfer +70% more time in HCPR case

 

HCPR also implies query regeneration even though I generated it before execution (1/10th of a second)
No major impact
Full details

OLAP Data Transfer +8%

Data Manager +6%
The cumulative effect of DM and OLAP in HCPR case is +20 seconds (15% increase), which is a significant penalty

 

* a small remark that I am doing it on a system where there are 1,6 mil records

So, to draw a conclusion – I’ve never noticed HCPR-based solution taking over the CDS

There seems to be insignificant penalty for using HCPR in aggregated data-sets, so it is a viable way forward from performance point of view. For bigger, more detailed queries I would do the exact measurement and see if user-expectations will be met.

If you would like to reproduce the same scenario, you may grab a BW system and work with Technical Content, e.g. OLAP statistics CDS views. I used RV_C_OlapStatACube
3 Comments