CDS Views with and without parameters - performance difference

[#1]

Hello All,

I am new to CDS and have a requirement where in we have a webdynpro screen, with multiple tabs and each tab pulling some values from the views created. So currently its a ' select * ' from webdynpro calling the views (SQL name of view) and passing the filter parameters. But CDS views have been declared without the parameters, and the values passed to call the views are more of acting as filters rather than parameters. But, I also see an option in CDS where in VIEW declaration is with PARAMETERS. So my question here is, if there is any performance issue in declaring CDS with parameters vs without parameters, predominantly while calling the CDS from webdynpro by passing the filter conditions from dynpro screen. If so, how to connect the parameters/select options from webdynpro screen to the one in CDS views.

Regards,
JA

[former_member1716]

Hello J ABAP,

Calling a CDS View which is already defined as CDS with Parameters is always better than Calling a normal CDS view (Without any parameter Defined).

However there is one Drawback in CDS with Parameter, it cannot handle select Option on its own. In other words CDS with Parameter can only deal with Parameters and it will not handle Select Option. In case if you are sure that your input/filter will only be single always then i would recommend to go with CDS with Parameter for sure.

In case you have Multiple inputs like select Option, We do have a workaround to Handle select option in CDS with Parameters. This is using AMDB methods. You have to follow below steps to ensure your CDS view with parameter can handle Select Options too.

1) Core concept does not change in CDS with Parameter, Your CDS will only handle parameter hence forth your Select option should wrapped in a String. In other words you need create a Dynamic Select Query where in you wrap the select option in to a string. In case if you have two Select option then wrap each Select Options into different string.

2) This Select Option which wrapped as a string is now passed as a parameter to CDS.

3) In CDS the implementation will be defined by a AMDB method, the String Parameter will be passed on to the AMDB method and it will applied to the data using APPLY_FILTER concept. Below Code for example.

You can also look into below Blog for detailed explanation of using Select option in CDS View, Do let us know if you have any doubts in that Blog.

CDS WIth Select option

To Summarize:

For Select Option scenario, If You want to completely make use of the CDS concepts i would recommend to Go with above steps else you can just define a normal CDS view and call them by applying the filter in the where Condition like normal table call in ABAP.

If the filter is a single value you can implement the CDS with parameter which is simpler than Select option method. Please Note that defining and normal CDS and passing the filter condition will still work. Performance wise CDS with Parameters is always better than normal CDS.

Hope it helps!

Regards!!!

[former_member563268]

Thanks for the reply Gaurav Karkara , Satish Kumar Balasubramanian. I just tried it today with parameters in regular CDS view with parameters. I have around 10 selection screen parameters in selection screen and most of them are optional in nature. But, It is not currently possible to define optional input parameters or replacement parameters for input parameters. Passing no values in selection screen will result in a filtering and mostly resulting in a null fetch.

But I could achieve this in normal views without parameters, by passing the created ranges as filters to the CDS views. Is there a better solution or workaround on this. Or creating the AMDP the only better solution. I am more concenred in terms of a performance difference.

[UweFetzer_se38]

>> Calling a CDS View which is already defined as CDS with Parameters is always better than Calling a normal CDS view (Without any parameter Defined). <<

Is there a reason why do you think so?

[former_member1716]

Hello J ABAP,

I would recommend you to try implementing both the solutions. One with Normal CDS and another with CDS with table functions and find the efficiency of both.

If is purely based on your requirement on dealing with different tables, if it is a direct fetch from multiple table and you don't have complex operations you may be satisfied with CDS view as you could not find any visible difference in the performance in this case.

In case if you are having complex operations or operations that can only be supported in AMDP procedures well you will understand the real benefits of the same. Recommend you to go through below Blog for better understanding.

BLOG

[GK817]

Hi JA,

There is no performance difference as such if you have used the filters correctly in your CDS view, but there is a difference between how you call them. It won’t be that straight forward to pass select options to CDS view parameters. If your parameters are of single value only , you may go for CDS views with parameters. For select options, be ready to write a AMDP class.

Looks like your filters are static, you may continue using normal CDS views with filters.