Skip to Content
Author's profile photo Maksim Alyapyshev

Data filtration options and performance analysis in ABAP CDS views

Hi! In the post I would like to consider important topic of filtering data in ABAP CDS views.

I’d like to thank Sergey Shablykin for close collaboration. Without his participation, knowledge and experience the post would not have appeared.


There currently three main ways of filtering data:

  1. Parameters in all level of ABAP CDS views
  2. Variables in consumption level ABAP CDS views
  3. Authorisations with DCL views

1. Parameters

Syntax of using parameters is considered in SAP documentation. In the table below there are pros and cons of parameters functionality.

Pros (+) Cons (-)
With help of @Environment.systemField annotation they could be filled by values of standard system variables. See SAP documentation Only single
Manual transfer of parameters from consumption to basic level of CDS view garantee logic push-down and performing filtration at bottom level Only mandatory, optional are not possible

In my opinion current limitations strongly restrinct area or parameters usage. Parameters are suitable for transfering to logic some numeric values used in calculations of key figures or may be to split complex logic at different scenarios. Usually I try to write a default value and to hide parameter so business user couldn’t see it.

2. Variables

Syntax of using parameters is considered in SAP documentation. In the table below there are pros and cons of parameters functionality.

Pros (+) Cons (-)
Very flexible settings, similar to BEx variables Not obvious transfering of values to bottom level
Could be mandatory or optional
Could be single, interval, range
Support miltiple selections
Could use derivations
Could work with hierarchies

Of course you notice that I write only one limitation in right part of table.

All other part of the post will deal with eliminating of the single limitation and answering a performance question:

Will filtration by variables in ABAP CDS views be pushed down to the most bottom level?

This question used to appear very often in case of S/4HANA and (its part) Embedded Analytics promotion. Nowadays if you have S/4HANA the main stream is not to create “old” ALV reports or develop all analytical reports in separate SAP BW system. You could use embedded analytics and create reports directly in S/4HANA based on ABAP CDS views.

3. Authorizations with DCL views

They are not considered here, for more information see post.

Checking performance of CDS view with variables

The following model was used for testing.

1. Sales Model Tables

1.1. Table of sales transactions. It contains time characteristics, sales manager, customer and amount. Number of records is 133 848.

1.2. Master data table of sales managers contains language dependent text and sales groups. They combined in one table only for minimization of data preparation and manual data input. Number of records is 9.

2. ABAP CDS views

2.1. Sales data transactional view:

@AbapCatalog.sqlViewName: 'XV_Sales'
@AbapCatalog.compiler.compareFilter: true
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Performance test'
@VDM.viewType: #BASIC
define view XV_I_Sales as select from sales002 as t1 {
  key t1.salesrep,
  key t1.customer,
  key t1.calyear,
  key t1.calmonth2,
   @DefaultAggregation: #SUM

2.2. Sales managers texts view:

@AbapCatalog.sqlViewName: 'XV_IT_SALESREP'
@AbapCatalog.compiler.compareFilter: true
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: 'Salesrep'
@VDM: { viewType: #BASIC }
@ObjectModel: { dataCategory: #TEXT }
define view XVITSALESREP as select from salesrep {
   @ObjectModel.text: {
       element: [ 'text' ]
   key salesrep, 
   @Semantics: {language: true }
   key spras, 
   @Semantics: { text: true }   

2.3. Sales managers dimension view:

@AbapCatalog.sqlViewName: 'XV_IA_SALESREP'
@AbapCatalog.compiler.compareFilter: true
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Salesrep'
@VDM: { viewType: #BASIC }
@Analytics: { dataCategory: #DIMENSION }
@ObjectModel: { representativeKey: 'salesrep' }
define view XVIASALESREP as select from salesrep 
 association[0..*] to XVITSALESREP on salesrep.salesrep = XVITSALESREP.salesrep
   @ObjectModel: {
       text: {
           association: 'XVITSALESREP'
   key salesrep, 

2.4. Sales cube view:

@AbapCatalog.sqlViewName: 'XV_C_Sales'
@AbapCatalog.compiler.compareFilter: true
@Analytics: {
    dataCategory: #CUBE
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Performance test'
define view XVCSales as select from XV_I_Sales 
 association [0..1] to XVIASALESREP on XV_I_Sales.salesrep = XVIASALESREP.salesrep
@ObjectModel: { foreignKey: {
    association: 'XVIASALESREP'
    key salesrep,
    key customer,
    key calyear,
    key calmonth2,
    key XVIASALESREP.srgroup as srgroup1,
    @DefaultAggregation: #SUM

2.5. Sales analytical query view with variables:

@AbapCatalog.sqlViewName: 'XV_Q_Sales'
@AbapCatalog.compiler.compareFilter: true
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Performance test QUERY'
@VDM: {
    viewType: #CONSUMPTION
@Analytics: { query: true}
define view XVQSALES as select from XVCSales {
  @AnalyticsDetails: { query: {
      axis: #FREE,
      display: #KEY_TEXT 
  } }
//  @Consumption: { filter: {selectionType: #RANGE, multipleSelections: true, mandatory: false, hidden: false }}
  @AnalyticsDetails: { query: {
      axis: #ROWS 
  @Consumption: { filter: {selectionType: #RANGE, multipleSelections: true, mandatory: false, hidden: false }}  
  @AnalyticsDetails: { query: {
      axis: #ROWS
  @Consumption: { filter: {selectionType: #RANGE, multipleSelections: true, mandatory: false, hidden: false }}  
  @AnalyticsDetails: { query: {
      axis: #ROWS
  @Consumption: { filter: {selectionType: #RANGE, multipleSelections: true, mandatory: false, hidden: false }}  
  @AnalyticsDetails: { query: {
      axis: #FREE
  @Consumption: { filter: {selectionType: #RANGE, multipleSelections: true, mandatory: false, hidden: false }}    
  @AnalyticsDetails: { query: {
      axis: #COLUMNS

3. Launch query in RSRT

3.1. Enter analytical query

3.2. Execute with following debug options for analysis performance and generated SQL from application server side of view.

3.3. Enter variables. Restrict year and sales group to analyse where and how filtration will be transfered and executed.

3.4. Get resulted sql statement and find restrictions in where clause.

/* Statement Preview (might be truncated) */
 A1~CALYEAR AS K____256
, A1~CALMONTH2 AS K____255
, A1~CUSTOMER AS K____257
, COUNT( * ) AS Z____151_SUM
, SUM(  A1~AMOUNT  ) AS Z____259_SUM
   ( ( ( (
= '2016'
 ) ) AND  ( (
= '1'
 ) ) ) )
, K____256
, K____257

3.5. Result data set is filtered by year, sales group and aggregated by sales managers (they are in free part of a query). Initial view:

Only 2016 as expected:

Only sales group 1 and sales managers of this group (see master data in paragraph 1.2).

Please note, that texts are shown in english as expected (you could find more information about time-dependent attributes and language-dependent texts in blog). In master data table we have 1 test record in german with sales group A1.

3.6. Query Statistics show that Total Number of Read Records in 3744 and Total Number of Transported Records 936. But this statistics could not demonstrate how this filtration and aggregation result performed at DB level (I mean logic push-down exist or not exist).

4. HANA SQL Trace

To understand how exactly filtration and aggregation from 133 848 to 936 records performed we need to analyse HANA SQL Trace.

4.1. Switch on SQL Trace on at Administration – Trace Configuration – SQL Trace.

4.2. Run analytical report in RSRT, stop SQL Trace and analyse the results.

4.3. Find in trace log generated SQL statement and execute in with Execution plan

SELECT "CALYEAR" "K____256" ,
 "CALMONTH2" "K____255" ,
 "CUSTOMER" "K____257" ,
 COUNT(*) "Z____151_SUM" ,
 SUM( "AMOUNT" ) "Z____259_SUM"
 FROM /* Entity name: XVCSALES */ "XV_C_SALES" "A1"
   "CALYEAR" ,
   "CALMONTH2" ,
   "K____255" ,
   "K____256" ,
 WITH HINT(RESULT_LAG ('hana_long'))

Enter for CALYEAR and SRGROUP1 values 2016 and 1 accordingly.

4.4. Execution plan graph and table format

We have 2 filtering conditions by year and by sales group. In the Execution Plan we see that filtration performed at bottom level in HANA DB.


We considered main filtration options in ABAP CDS views and got an answer for the primary question:

Filtration by variables in ABAP CDS views is pushed down to the most bottom level!


Thank you for attention!

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Alexey Semenov
      Alexey Semenov

      Cool topic!

      Author's profile photo Prashant Sharma
      Prashant Sharma

      Thanks Maksim, well explained.

      Author's profile photo Viren Pravinchandra Devi
      Viren Pravinchandra Devi

      Super Maksim...Quite helpful....

      Author's profile photo Mayank Jaiswal
      Mayank Jaiswal

      Awesome Maksim,


      Thanks for this sharing this information.


      Best Regards,

      Mayank Jaiswal

      Author's profile photo Neville Woods
      Neville Woods

      Thanks Maksim - great blog, need more like this.



      Author's profile photo Christoph Paulusch
      Christoph Paulusch

      Hi Maksim,

      nice blog.

      But what to do if the filter variables are not pushed down to the bottom? We have multiple cases in our system where the filters are not pushed down and performance is very bad because of this.

      Is there anything we can do to change that?