Skip to Content
Personal Insights

S/4HANA Analytics: BW queries with or without BW modeling (comparison)

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
You must be Logged on to comment or reply to a post.
    • Hey Erdem! Thanks, glad you like it!

       

      In this particular case I used a standalone BW/4HANA 2.0, because I had more data in (and I wanted to have more data for measurements). The idea can easily be reproduced on embedded BW in S/4, but you need a good source. I am afraid this particular model RV_C_OlapStatACube is not available in S/4 (please don’t ask me why SAP has decided OLAP stats are not important there).

       

      Cheers,

      Dmitry