Advanced CDS Features: Session Variables, Parameters and UNION in ABAP CDS View Entities

Imagine you want your CDS View to always return data based on today's date, the current logon language or the current client.

Should these values be hard-coded?

Absolutely not.

Every user logs into the SAP system with a different runtime context.

Instead of hard-coding these values, SAP provides Session Variables.

Session Variables provide information about the current SAP session at runtime.

A common requirement is to display only documents created up to the current date.

define view entity ZI_SALES

  as select from I_SalesDocument
{
    key SalesDocument,

    CreationDate
}
where

    CreationDate <= $session.system_date;

Every time this CDS View is executed, the system automatically substitutes $session.system_date with the current date.

Text tables usually contain multiple languages.

Instead of hard-coding a language, use the current logon language.

where

Language = $session.system_language

If the user logs on in English, English texts are returned.

If another user logs on in German, German texts are returned without changing the CDS View.

Session Variables can also be passed directly to built-in functions.

dats_days_between(

    CreationDate,

    $session.system_date

) as DaysSinceCreation

The function calculates the number of days between the document's creation date and today's date.

Although Session Variables look like ordinary fields, they are special runtime variables provided by the ABAP runtime environment.

Every execution of a CDS View may produce different results depending on the current user's session.

Most SAP tables are client-dependent.

If required, the current client can be referenced using the session variable.

where

Client = $session.client

During execution, the runtime automatically substitutes the current client value.

Some business scenarios require filtering records that belong to the current user.

where

CreatedByUser = $session.user

This allows a single CDS View to behave differently for different users without any code changes.

Consider the following CDS View.

where

CreationDate <= $session.system_date

Suppose today is:

15-Jul-2026

Internally, the runtime evaluates the expression as if it were:

CreationDate <= '20260715'

Tomorrow, the same CDS View automatically behaves as:

CreationDate <= '20260716'

No transport or code modification is required.

Session Variables are provided automatically by the SAP runtime.

But sometimes the runtime doesn't know what value should be used.

For example:

• Show Sales Orders for a specific date.
• Show Billing Documents for a particular Company Code.
• Show Purchase Orders for a selected Plant.

These values must be supplied by the application executing the CDS View.

CDS Parameters allow the caller to provide values at runtime.

define view entity ZI_SALES

with parameters

    p_creation_date : abap.dats

as select from I_SalesDocument
{
    key SalesDocument,

    CreationDate,

    SoldToParty
}
where

    CreationDate >= $parameters.p_creation_date;

The CDS View now expects a value for p_creation_date whenever it is executed.

Parameters are accessed using the $parameters namespace.

$parameters.p_creation_date

Unlike Session Variables, parameters do not have predefined values.

The caller is responsible for supplying them.

SELECT *

FROM ZI_SALES(

    p_creation_date = @sy-datum

)

INTO TABLE @DATA(lt_sales).

During execution, Open SQL passes the value of sy-datum to the CDS parameter.

So far, every CDS View in this tutorial has selected data from a single source.

But real business scenarios often require combining records from multiple data sources into a single result set.

This is where UNION and UNION ALL become useful.

UNION combines the result of multiple SELECT statements into a single result set.

define view entity ZI_BUSINESS_PARTNERS

as

select from I_Customer
{
    key Customer     as BusinessPartner,
        CustomerName as Name
}

union all

select from I_Supplier
{
    key Supplier     as BusinessPartner,
        SupplierName as Name
}

The result contains both Customers and Suppliers in a single CDS View.

• Both SELECT statements must return the same number of columns.
• Columns must appear in the same order.
• Data types must be compatible.
• Field semantics should match.
• Use CAST when compatible data types cannot be inferred automatically.