Skip to Content
Technical Articles

Filtering on Association property in Fiori Element app via ABAP CDS Virtual Elements

Some time back there was a auestion about filtering the Fiori Element application by association property of the CDS view.

At that time, I debugged both the UI5 Fiori Elements APIs and backend odata and found that Fiori Elements & SAP Gateway both doesn’t support it.

Actually It supports the filter on association property but only with the associations having cardinality of 1..1 and it doesn’t support 1..n .Β  Not sure if something has changed in between as I debugged it last year Feb 2019.

In fact, I was planning to blog about it πŸ˜€ funny, I didn’t have a solution at that time for that but still created a blog post and hoped in that process I will figure out the solution πŸ™‚ πŸ™‚ believe me it works πŸ™‚ πŸ˜€ and it is one of the best way to learn & dig deep into the subject πŸ™‚Β  But I was lazy and left that blog post in the draft state πŸ˜€

Now recently there was some activity in that question asking for a proper solution and I replied with a workaround of using the table function but now again I found a different way, which uses the Virtual Elements in ABAP CDS πŸ™‚

So in this blog post, I will show the way to filter the data by association property with 1..n cardinality using the Virtual Elements in CDS view. I believe this will be applicable for ABAP Restful programming model as well as the SADL layer(Data fetching logic of CDS view) is common for both ABAP programming model for Fiori and RAP.

For filtering via AMDP/Table Function in CDS, check the below blog.


I will use an example of Carrier CDS view, which has an association(1..n cardinality) with Flights CDS view.

OData service is generated based on the annotations and consumed in the Fiori Elements List Report application.


Now the functionality to fetch all the carries is based on the “Country From”(COUNTRYFR) should be provided. But this field is not part of SCARR table, it is part of the association table SPFLI(1..n).

For this we will use the virtual element annotations and create a class as shown in the below steps.


Creating both the root(parent) and child cds views.


Root CDS view – ZC_CARRIER

@AbapCatalog.sqlViewName: 'ZVCCARRIER'
@AbapCatalog.compiler.compareFilter: true
@AbapCatalog.preserveKey: true
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: 'Car1 Test'
@OData.publish: true
define view ZC_CARRIER
  as select from scarr
  association [0..*] to ZC_SPFLI as _spfli on $projection.carrid = _spfli.carrid
  association [0..*] to sgeocity as _geoCity on $projection.country_from =
      @UI.lineItem: [
      { position: 10 }]
  key scarr.carrid,
      @UI.selectionField: [{ position: 20 }]
      @UI.lineItem: [{ position: 20 }]
      @UI.selectionField: [{ position: 30 }]
      @UI.lineItem: [{ position: 30 }]
      @UI.lineItem: [{ position: 50 }]
//      @ObjectModel.virtualElementCalculatedBy: 'ABAP:ZCL_VE_CAR1'
      @ObjectModel.filter.transformedBy: 'ABAP:ZCL_VE_CAR1'
      @EndUserText.label: 'Country From'
      @UI.selectionField: [{ position: 50 }]
      @Consumption.valueHelp: '_geoCity'
      cast( '   ' as land1 preserving type ) as country_from,

        /* Expose the associations*/

Child CDS view

@AbapCatalog.sqlViewName: 'ZVCSPFLI'
@AbapCatalog.compiler.compareFilter: true
@AbapCatalog.preserveKey: true
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: 'Spfli1'
define view ZC_SPFLI
  as select from spfli
  association [0..1] to ZC_CARRIER as _carrier on spfli.carrid = _carrier.carrid
  key spfli.carrid,
  key spfli.connid,

They both are pretty simple CDS views, but the Root CDS view has the new Virtual Element “country_from”Β with annotations related to Virtual Elements.

More about it in SAP Help link:


Above annotation tells that the property is a Virtual Element.

@ObjectModel.filter.transformedBy: 'ABAP:ZCL_VE_CARRIER'

above one will tell the framework that ifΒ  the filter is applied on the Virtual Element then call the ABAP class “ZCL_VE_CARRIER” to get the filter condition.



Let’s create the class and implement the interface as shown below:

    INTERFACES if_sadl_exit .
    INTERFACES if_sadl_exit_filter_transform .

  METHOD if_sadl_exit_filter_transform~map_atom.
    DATA(country_from) = cl_sadl_cond_prov_factory_pub=>create_simple_cond_factory( )->element( '_SPFLI.COUNTRYFR' ).
    ro_condition = country_from->equals( iv_value ).


In the above code,Β  I created a condition on the Association Property “_SPFLI.COUNTRYFR” and sent is back to the framework.

For more information, check the SAP help from the step1, It’s just a basic code and in production scenarios, it should be able to handle the different type of of filter conditions(EQ, Contains..,).


That’s it, just run the application to see the new Country From Filter, selectΒ  a value and apply the filter to get all the carries based on the Country From:


Some more Technical Details for the Geeks

When the search is executed in the Fiori app, SADL layer will request the Virtual Element filters before performing the actual CDS view Select execution below:


These conditions taken from that exit will be converted to a where condition by SADL layer in the below format:

           FROM ZC_CAR1 AS ZC_CAR1 
          WHERE nav_TO_SPFLIZC_SPFLI1_0~COUNTRYFR = 'DE' AND ( ZC_CAR1~CARRID = ZC_CAR1__BSAX~CARRID OR ZC_CAR1~CARRID IS NULL AND ZC_CAR1__BSAX~CARRID IS NULL ) )                                                                                                                                                                                                        

It’s a general subquery, but I never used it and never knew about it (What a shame πŸ˜€ πŸ˜€ ) , thought it is a new syntax for a second there πŸ˜› πŸ˜› πŸ˜€ πŸ˜€


BTW I found this virtual elements association filtering concept when I was analysing a standard application to understand the behavior of the Virtual Elements πŸ™‚ πŸ™‚

Also, this might be heavy on the performance due to the Sub Query, not sure though. If yes, this can be handled using the Table Function, which I mentioned in the Original Question’s answer. Maybe in an another blog post πŸ™‚

<Update>: Performance is better with Virtual Elements via subquery, check the below blog post.


So that’s it folks πŸ™‚ and please share your thoughts and suggestions about this.


And Don’t forget to check the blogging initiative by Phil CooleyΒ  This year is the year of SAP blogs 2020YearofSAPBlogsΒ  πŸ˜€ πŸ™‚Β  I will be creating atleast one blog post per month πŸ™‚ So don’t wait to share your SAP findings and knowledge. Learn, Share & Repeat πŸ™‚





You must be Logged on to comment or reply to a post.
  • Hey Mahesh,

    Thanks for such a nice blog!!! πŸ˜‰

    This is one of the common scenario when it comes to CDS and I always had this question in mind. Even it's always an difficult to explain Functional folks about this technically πŸ˜‰ but finally I can say we had something which we can do in these scenario's. Thank You very much for this blog I was searching this for long time.

    Even I believe it's good to use Virtual elements instead of table function. Because I had experience where table function is also putting lot of load on system when filtering for exact same scenario.


    Dhiraj M




    • Thanks for the feedback Dhiraj, really appreciate it πŸ™‚ πŸ™‚

      Yeah it is a lot better to use Virtual Elements compared to Table function in this scenario, initially I assumed that the table function will be a lot better but I was wrong and when I wrote an another blog post, comparing the both, I found VE is a lot better in this case.



      • Hey Mahesh,

        Yeah we face one issue when we were using AMDP Table function to concatenate system/user status. And when using filters on concatenated fields, we saw it was loading all data into memory which caused high memory usage and performance issues. And then we went for the Virtual elements and everything was fine.

        But now one question which is bothering is then we should not use AMDP table functions at all because eventually it will give performance issues and memory consumption issue when we have more data. That's a big disadvantage we have with AMDP and will stop everyone from using it.

        So I was wondering is it the issue with AMDP or were we using it incorrectly.

        Any thoughts on this or someone with more experience on AMDP can comment: better:)


        Dhiraj M

  • Hi Mahesh,

    Thanks for nice blog and detailed explanation.

    We have used virtual element to do filtering on Assocation fileds having (0-n).

    I have question how to display this countryfromΒ  virtual field in Result list Table.We have requirement to show field both (virtual element) in filtering and result table.




    • Hi Amit, Really appreciate the feedback πŸ™‚ thanks.

      I am not sure if it is possible because you need to consider this scenario: What if there are multiple association values, in this case, how can you show them in a single line in the list report(parent entity)? as it’s not possible, we cannot do it, the only way is to navigate to the object page, where we can show them.

      Else, you can do via table function as shown below: here you can concatenate all the child and you can also show them in the parent row, but I don’t think this is the right solution. Still would advise you to show them on the object page.



  • Hi Mahesh,

    Thanks for this detailed blog.

    I wonder if it’s possible to search in assosiation field using the default search element.

    I tried this:

    @ObjectModel.filter.transformedBy: 'ABAP:ZCL_VE_CAR1'
    @Search: {defaultSearchElement: true}
    cast( '   ' as land1 preserving type ) as country_from

    But it doesn’t work as expected. It’s not event calling the class.

    I also tried with an amdp but I get the following error:

    Database returned the SQL code 7. Error text: feature not supported: CONTAINS predicates on aggregate functions

    Is there any workaround?