Use a CDS View Entity as the Data Source in an ABAP SELECT

Replacing a database table with a CDS view entity in an ABAP SELECT can be a small syntax change. Deciding whether that replacement is correct takes more work.

My review rule is simple: choose the data source that represents the required business data, then verify its behavior. A CDS entity is not automatically a drop-in replacement for its underlying table.

This tutorial shows how to inspect an entity, query its exposed fields, and validate the result before changing an existing implementation.

Prerequisites

• An ABAP development system supporting CDS view entities, available from ABAP release 7.55.
• ABAP Development Tools (ADT) in Eclipse.
• Familiarity with ABAP SQL, inline declarations, and internal tables.
• Authorization to inspect and execute the selected CDS entity.
• The /DMO/I_Connection demo entity for the examples, or an equivalent entity in your system.

CDS view entities do not have the additional DDIC SQL view associated with classic CDS views. Use the CDS entity name in your ABAP query. The supplied CDS overview explains both the release requirement and this distinction.

Check local availability first. Demo objects, their definitions, and permitted API usage can differ between systems. In ABAP Cloud, also verify that the object is permitted for your development context.

Overview

SAP’s Working with CDS Views lesson establishes the central capability: an ABAP SELECT can use a CDS view entity instead of reading a database table directly.

The lesson adds useful modeling detail. A CDS definition can contain:

• Projections and field aliases.
• Calculations and aggregations.
• Joins and unions.
• Associations to related entities.
• Annotations describing semantics.

That makes the entity definition part of the query’s effective contract.

For example, a flight-connection report might need airline identifiers, connection identifiers, and departure and destination airports. If an existing CDS entity exposes those values with the required meaning, consuming it avoids reproducing its modeling logic in the report.

The source establishes the capability, but its brief summary does not establish that every table-to-CDS replacement preserves results. The inspection and validation workflow below is practical engineering guidance for making that decision.

Step 1: Inspect the CDS Entity Before Coding

In ADT, open the data definition for /DMO/I_Connection.

SAP’s lesson uses this entity as an example and identifies /dmo/connection as its underlying database table. It also explains how elements can be exposed under aliases and how associations become available to consumers through the element list. See the definition walkthrough.

Inspect four areas.

Exposed elements

Record the element names you intend to select. ABAP SQL consumes the entity’s exposed names, not necessarily the original table-column names.

The examples below expect:

Confirm these names and mappings in your installed definition before copying the code.

Row granularity

Ask what one row represents.

Is it one connection, one connection per date, or an aggregated result? Inspect joins, filters, grouping, and underlying entities. Do not assume that a declared CDS key alone proves that the returned rows are unique.

Business semantics

Check whether fields are raw values, calculated values, or converted values. For quantities and amounts, identify the corresponding unit or currency elements.

A matching technical type does not guarantee a matching business meaning.

Access and usage constraints

Inspect authorization-related annotations and applicable access-control definitions. Also check entity parameters and API release status.

Do not replace a table read until the entity’s exposed contract fits the requirement.

Step 2: Preview Representative Data

Right-click inside the data definition and select Open With → Data Preview. SAP documents this workflow in its CDS lesson.

Filter the preview to a known airline and inspect several connections.

Check that:

• The airline has the expected connections.
• Departure and destination airports match known examples.
• Identifiers retain their expected formatting.
• Unexpected duplicate rows are absent.
• Empty results make sense for the selected filter.

Preview is useful for exploration, but it is not a substitute for testing the actual ABAP consumer under its intended user context.

Step 3: Write the ABAP SELECT

Create an executable ADT class implementing IF_OO_ADT_CLASSRUN:

CLASS zcl_cds_connection_read DEFINITION
  PUBLIC
  FINAL
  CREATE PUBLIC.

  PUBLIC SECTION.
    INTERFACES if_oo_adt_classrun.
ENDCLASS.

CLASS zcl_cds_connection_read IMPLEMENTATION.

  METHOD if_oo_adt_classrun~main.

    DATA lv_airline_id
      TYPE /dmo/i_connection-AirlineID VALUE 'LH'.

    SELECT FROM /dmo/i_connection
      FIELDS AirlineID,
             ConnectionID,
             DepartureAirport,
             DestinationAirport
      WHERE AirlineID = @lv_airline_id
      ORDER BY AirlineID, ConnectionID
      INTO TABLE @DATA(lt_connections).

    IF lt_connections IS INITIAL.
      out->write(
        |No connections found for airline { lv_airline_id }.|
      ).
      RETURN.
    ENDIF.

    out->write( lt_connections ).

  ENDMETHOD.

ENDCLASS.

Choose an airline identifier present in your demo data.

The important parts are:

• /dmo/i_connection is the CDS entity used as the source.
• FIELDS lists only the required exposed elements.
• @lv_airline_id passes an ABAP host variable.
• Inline declaration derives the result-table type from the selected columns.
• ORDER BY makes the requested ordering explicit.

ABAP SQL supports CDS entities in the FROM clause, as described in the supplied data-source reference. That reference predates CDS view entities, so use your system’s ABAP Keyword Documentation for release-specific syntax.

Selecting explicit columns also makes code review easier: the query states exactly which parts of the entity contract it depends on.

Step 4: Compare Against the Intended Business Data

Successful compilation proves that the query is syntactically valid. It does not prove business correctness.

For this simple projection example, a direct table query can provide a development-time comparison—provided table access is permitted and inspection confirms equivalent semantics.

Add this temporary check after the CDS query, before the empty-result branch:

SELECT FROM /dmo/connection
  FIELDS carrier_id      AS AirlineID,
         connection_id   AS ConnectionID,
         airport_from_id AS DepartureAirport,
         airport_to_id   AS DestinationAirport
  WHERE carrier_id = @lv_airline_id
  ORDER BY carrier_id, connection_id
  INTO TABLE @DATA(lt_expected).

IF lt_connections = lt_expected.
  out->write( 'Validation: selected rows match.' ).
ELSE.
  out->write( 'Validation: investigate differing results.' ).
  out->write( lt_expected ).
ENDIF.

This example assumes the exposed fields retain the corresponding table-field types and meanings. Confirm that assumption locally.

A direct table read is not always the correct oracle. A business-oriented entity may intentionally filter, join, aggregate, or restrict data. In that situation, validate against documented business rules and approved expected records instead.

Use a small test matrix:

Investigate differences rather than immediately forcing equality. Access control, filters, or joins may explain why the CDS result differs from a raw table read.

Step 5: Review Parameters, Associations, and Performance

Before transporting the change, check features that the basic example does not exercise.

Parameters

A parameterized entity needs actual parameter values in its data-source expression. This differs from a WHERE condition, which filters the entity result.

The supplied ABAP SQL reference documents parameter assignment for CDS data sources. Check the exact parameter names and types in your entity.

Associations

An exposed association represents a relationship, not a scalar value to display directly. Retrieving related elements requires appropriate association-path usage or another explicit query design.

Review the relationship and expected row multiplicity before extending the query. SAP’s lesson explains association exposure and consumption.

Performance

Do not assume that replacing a table with a CDS entity improves runtime. The entity may introduce additional work through its underlying model.

My practical recommendation is to:

• Keep selective predicates in the database query.
• Avoid unused columns.
• Inspect expensive underlying logic.
• Measure with representative data and your team’s tracing tools.

Correctness comes first; performance claims require measurement.

Step 6: Add Quality Checks Before Replacing Production Code

Turn the validation exercise into maintainable evidence:

1. Document why the entity matches the business requirement.
2. Record field mappings and intentional semantic differences.
3. Add automated tests for filtering and empty-result handling.
4. Keep controlled integration checks for actual entity behavior.
5. Run syntax checks and your project’s ABAP Test Cockpit checks.

Avoid tests that depend on arbitrary demo records remaining unchanged. Separate stable application-logic tests from integration tests requiring prepared database data.

In code review, I would ask: “What proves this entity returns the right business rows?” The answer should be stronger than “the new query activates.”

Conclusion

Using a CDS view entity in an ABAP SELECT is straightforward: name the entity in FROM and select its exposed elements.

The important work surrounds that statement. Inspect field names and semantics, understand row granularity, preview representative data, and validate the result under the intended execution conditions.

When the entity’s contract matches the requirement, consume it directly. When it does not, choose a better-fitting source rather than treating CDS adoption as a mechanical table-name replacement.

References

• CDS View Entities
• Goodbye CDS View, Hello CDS View Entity – Part 1