CDS View with annotation performance issue (Parameters / Filter annotations)

[Nicolas_Boucaud]

Hello,

I have a question about CDS View. I created an OVP (Fiori Elements) using CDS View with annotation and everything's working fine except that I'm facing performance issue.

I'm using CDS View "stacking" (CDS view calling the previous one) and because of a huge volume of data, the application is really slow to load. I assumed I had to filter the first CDS to reduce this volume.

Here is my screen :

Presently I am using filter annotation in the last CDS called (ZCDS_OVP_TBP_ALL_ANNO) :

//Join operations here//

then

Now I would like to filter the very first CDS (ZCDS_REV_YEAR) using "Company Code" parameter (bukrs) that the user enters in the input. This way I could reduce significantly the amount of data in my final CDS thus its performance.

How can I accomplish that ? I tried adding "@Consumption.filter" in the first CDS View (ZCDS_REV_YEAR)but it does not change anything.

Thanks for your help !

[abhi1185]

Hello Nicolas,

Yes Actually @consumption.filter needs to be applied on field present in Selection. I have some Date criteria which needs to be passed to WHERE condition and records falling under those dates needs to be fetched again. I have start date and end date, also there is a hierarchy of CDS, so I need to propagate this parameter down to basic CDS views.

[abhi1185]

Hello Nicolas,

Did you get solution for same, actually I also have OVP application which is created using CDS view. However as soon as I added parameter to CDS, cards stopped showing Data. I have added OdataSelect paramter = true to all cards in manifest.json, also parameter is appearing, but nothing is getting selected.

[Nicolas_Boucaud]

Hello Abhishek,

does your use case prevent you from using filter annotations (@Consumption.filter) ? Because if not, I think it is the best way to go : simpler to use and appears to be as efficient as parameters (if not more).

[former_member595836]

Hello,

There are plenty of standard CDS views that call out parameterized CDS in the call hierarchy. For example, please check C_TrialBalance.

Having said that if your sole objective is to apply direct filter on the table field (and not complex operations like calculation of YTD balance or using parameter in complex filter criteria or join conditions) then having parameter adds no value.

The SQL optimizer automatically passes down the filter to the base table if the field exists directly in the table. So I think the reason for poor performance in your case appears to be different and not related to filter.

I recommending checking "Expensive Statements" option in DB02 and narrow down to the root cause within SQL call hierarchy.

- Anup

[Nicolas_Boucaud]

First of all thanks for your answer.

The fact is if I set a fixed value for BUKRS field ("F372" for instance) in the first CDS "ZCDS_REV_YEAR" the performance is much better than if don't do that and launch the OVP with "F372" parameter value in the input (which calls ZCDS_OVP_TBM_ALL_ANNO). It returns correct/same values for cards/kpi (obviously) but takes much longer.

That is why I assume the parameter is not passed down to the base table...