Here’s #1 of our series on squeezing every drop of power out of CDS Views.

Avoid Virtual Elements because they contradict one of RAP’s core principles and just slow things down.

So if you want blazing fast CDS Views, then you’re in the right place.

Let’s get started!

Avoid those Virtual Elements

Before anything else, why avoid Virtual Elements?

Because . . . if you use Virtual Elements, you undermine one of the fundamental principles of RAP (Restful ABAP Programming).

And RAP is our goal.

CDS Views are a cornerstone of RAP.

Thus, the entire purpose of CDS Views is to support RAP.

And one of the core objectives of RAP is the Code Pushdown.

What is the Code Pushdown?

Well, the concept of Code Pushdown is to handle logic on the database instead of the application server.

For example, instead of calculating the value of an order (quantity * price) in ABAP on the application server layer, we’d do this in a CDS View on the database layer.

Why?

Because we want to utilize the brutal power of the HANA database.

CDS Views get executed on the database.

CDS Views are actually nothing more than syntactic sugar for SQL.

If you execute a CDS View, you execute a SQL statement at the end.

Well, and SQL gets executed on the database.

Again, RAP has the execution of logic on the database layer as a fundamental concept.

CDS Views execute logic on the database layer.

Surprise, CDS Views as part of RAP are a perfect match.

So why do I bother you with those details above you ask?

Well, now with that those things being said and keeping those in mind, let’s make the transition to what Virtual Elements actually are.

What are Virtual Elements?

Virtual Elements, those little rascals.

I’m already getting upset just by mentioning them.

Anyway, there is no way around:

For instance, taking the example from above, suppose you want to calculate the value of an order (quantity * price).

Assume for a moment that this calculation couldn’t be done with CDS Views.

In that case, you could create a Virtual Element in a CDS View.

Because that Virtual Element would execute ABAP code to perform the logic mentioned above, multiplying quantity by price.

And you surely can solve the problem with ABAP.

Then, htat ABAP code would be executed each time the Virtual Element is accessed on the CDS View, solve the problem, and return the result to the CDS View.

So what’s the issue with Virtual Elements?

Why I’m upset?

Sound good so far, doesn’t it?

No.

Well, where does the ABAP code of the Virtual Element gets executed?

Precisely, on the application server.

Not the database.

What is one of the main fundamentals of the RAP framework?

Yes, the Code Pushdown.

What does that mean, again?

Executing logic on the database, utilizing the absurd might of HANA.

You see my point?

We don’t want to execute ABAP instead of CDS Views’ SQL.

How to avoid Virtual Elements

Well, CDS Views are Turing-complete.

So, CDS Views can solve any problem that a computer can, with enough time and memory.

CDS Views can do any computation that doesn’t require infinite resources.

Therefore, take a closer look at your requirement at hand and ask yourself whether the logic necessary can’t be done in a reasonable way with CDS Views.

I say “reasonable way” because, while CDS Views might be Turing-complete, that doesn’t mean you should do any computation with CDS Views.

Especially due to performance reasons.

You will see in the coming parts of this series what I mean by this.

On top of just using CDS Views instead of Virtual Elements, take a look at Table Functions.

Table Functions work similarly to Virtual Elements, but the crucial difference is that table functions invoke SQLScript instead of ABAP as Virtual Elements do.

SQLScript again gets executed on the database, not like ABAP on the application server.

Hence, Table Functions don’t contradict the Code Pushdown principle but perfectly compliment those.

Example of an unworthy Virtual Element in a CDS View executing ABAP logic

Here’s what a Virtual Element looks like in a CDS View so you can spot and replace them without thinking twice.

define view entity /INUI/C_DEMO
  as projection on /INUI/C_DEMO_R
{ . . .

  @ObjectModel.virtualElementCalculatedBy: 'ABAP:/INUI/CL_ORDER_VALUE'
  @EndUserText.label: 'Order Value'
  virtual OrderValue : abap.curr,
  
  . . . }

Here is the Virtual Element’s ABAP logic that gets executed on the application server, not the database, each time you request that Virtual Element on the CDS view.

CLASS /inui/cl_order_value DEFINITION
  PUBLIC
  FINAL
  CREATE PUBLIC .

  PUBLIC SECTION.
    INTERFACES if_sadl_exit_calc_element_read.

  PROTECTED SECTION.
  PRIVATE SECTION.

ENDCLASS.


CLASS /inui/cl_order_value IMPLEMENTATION.

  METHOD if_sadl_exit_calc_element_read~get_calculation_info.
  
    . . .
  
  ENDMETHOD.

  METHOD if_sadl_exit_calc_element_read~calculate.
  
     . . .
  
  ENDMETHOD.

ENDCLASS.

tl;dr

Avoid using Virtual Elements in CDS Views because they execute logic on the application server rather than on the database, which contradicts the Code Pushdown, a fundamental concept of SAP RAP and bringer of performance.