Parameterized CDS Views and Filtering

Explanation

Parameterized CDS views allow consumers to pass input values such as date, company code or key date into the CDS model. They are useful when the logic depends on a required input, such as validity date, exchange rate date or reporting period. Parameters can help push filtering to the database early. However, parameters should not be overused. If normal WHERE filters are enough, a parameter may not be needed. Good parameter design improves performance and clarity, while poor parameter design makes CDS harder to consume.

Code example

@EndUserText.label: 'Billing by Posting Date Parameter'define view entity ZI_BillingByDate with parameters p_from_date : abap.dats, p_to_date : abap.dats as select from vbrk{ key vbeln as BillingDocument, fkdat as BillingDate, kunag as SoldToParty, netwr as NetValue}where fkdat between $parameters.p_from_date and $parameters.p_to_date // Purpose:// Parameters force date filtering inside the CDS model.// This helps avoid unrestricted large data selection.

Real project scenario

A pricing validity report used a key-date parameter so only condition records valid on that date were selected by the CDS view.

Common mistakes

- Using parameters for every optional filter. - Not documenting parameter meaning. - Creating parameterized views that are difficult to consume. - Ignoring value help or defaulting strategy.

Best practices

- Use parameters for mandatory business inputs. - Keep parameter names clear. - Avoid unnecessary parameters. - Push selective filters early.

Interview angle

A strong answer should explain when parameters are useful and when normal filters are enough.