Build ABAP CDS View Entities with Joins, Parameters, and Extensions

A useful CDS model does more than move a SELECT statement out of an ABAP program. It defines a reusable data contract: which records belong together, which inputs consumers must supply, and how additional fields can be introduced safely.

My approach is to establish the result’s grain first, then add joins, parameters, and extensions incrementally. That makes defects easier to isolate in ADT before they reach application code.

This tutorial builds a flight-reporting model. You will combine flight and carrier data, constrain results by date, and extend the model without replacing its original definition.

Prerequisites

• An ABAP development system on SAP HANA supporting CDS view entities, introduced with ABAP Platform 7.55.
• Eclipse with ABAP Development Tools (ADT).
• Authorization to create and activate development objects in a customer package.
• Familiarity with ABAP SQL, database keys, and basic CDS annotations.
• The classic flight-model tables SFLIGHT and SCARR, populated with demonstration data.

These examples target a classic ABAP development environment. Do not assume that SFLIGHT and SCARR are available or released for ABAP Cloud development. On SAP BTP, ABAP environment, adapt the examples to available, released data sources.

Check syntax against your backend release, not only your ADT version. The supplied CDS syntax reference emphasizes this release dependency and distinguishes classic CDS views from newer view entities.

Overview: Use the Series as a Learning Map

The Discovering ABAP series index organizes its coverage around an introduction, joins, parameters, and extending a CDS view. Use those entries as targeted reading:

• Start with the introduction to understand the series’ scope and terminology.
• Consult the joins article when combining multiple sources.
• Review parameters when consumers must provide inputs.
• Investigate extensions before copying or replacing an existing view.

The index provides a roadmap rather than a complete implementation in its excerpt. This tutorial adds a connected example using modern view-entity syntax, explicit activation steps, and validation checks. The supplied SAP extension references provide the detailed rules for that final step.

Step 1: Choose the CDS Object Type

A classic DDIC-based CDS view uses define view and requires @AbapCatalog.sqlViewName. It has an associated CDS-managed DDIC view.

A CDS view entity uses define view entity and does not create that separate CDS-managed DDIC view. SAP recommends view entities for suitable system releases, as summarized in the CDS reference.

For this exercise, use view entities consistently:

Do not add @AbapCatalog.sqlViewName to these examples. Use the CDS entity name when selecting from ABAP.

Step 2: Join Flights to Carrier Data

The business requirement is straightforward: show each scheduled flight alongside its carrier name.

The intended grain is one row per carrier, connection, and flight date. Before writing the join, verify that the carrier source has at most one matching record per carrier within the client.

In ADT:

1. Right-click your package.
2. Choose New → Other ABAP Repository Object → Data Definition.
3. Create ZI_FlightCarrier.
4. Replace the generated content with:

@EndUserText.label: 'Flights with carrier details'
@AccessControl.authorizationCheck: #NOT_REQUIRED
@AbapCatalog.viewEnhancementCategory: [#PROJECTION_LIST]
define view entity ZI_FlightCarrier
  as select from sflight as Flight
    inner join scarr as Carrier
      on Flight.carrid = Carrier.carrid
{
  key Flight.carrid   as CarrierId,
  key Flight.connid   as ConnectionId,
  key Flight.fldate   as FlightDate,
      Carrier.carrname as CarrierName,
      Flight.seatsmax as SeatCapacity,
      Flight.seatsocc as OccupiedSeats
}

Save and activate the definition. Open Data Preview to inspect the result.

An inner join keeps only matching rows. If flights without matching carrier master data must remain visible, use a left outer join instead. The supplied SAP Community introduction to CDS view types explains these matching and preservation rules.

Three quality checks matter here:

• CDS key declarations do not remove duplicates.
• Incomplete join conditions can multiply rows.
• Client-dependent ABAP CDS sources normally receive implicit client handling; do not add client fields mechanically.

With a left outer join, unmatched right-side values are null at database level. ABAP SQL typically maps these to type-dependent initial values unless null handling is requested. Also, a where condition on a right-side field can remove unmatched rows and defeat the intended outer-join behavior.

The authorization annotation is for this exercise, not a production security design. #NOT_REQUIRED does not implement row-level access control. Define and test appropriate DCL before exposing business data.

Step 3: Add a Parameterized Consumption Layer

Next, allow a report to request flights within a date interval.

Keep the reusable join separate from the parameterized layer. This avoids forcing every consumer of the base entity to provide dates.

Create another data definition named ZI_FlightByDate:

@EndUserText.label: 'Flights within a date interval'
@AccessControl.authorizationCheck: #NOT_REQUIRED
define view entity ZI_FlightByDate
  with parameters
    p_from_date : abap.dats,
    p_to_date   : abap.dats
  as select from ZI_FlightCarrier as Flight
{
  key Flight.CarrierId,
  key Flight.ConnectionId,
  key Flight.FlightDate,
      Flight.CarrierName,
      Flight.SeatCapacity,
      Flight.OccupiedSeats
}
where Flight.FlightDate >= $parameters.p_from_date
  and Flight.FlightDate <= $parameters.p_to_date

Activate it and supply both dates in Data Preview.

Parameterized views are part of the CDS modeling options described in the SAP Community overview.

Use parameters when an input belongs to the entity’s interface. For an ordinary optional report filter, an ABAP SQL WHERE condition may be simpler.

Validate that the start date does not exceed the end date in the calling application. This CDS definition simply returns no matching rows for a reversed interval; it does not generate a user-friendly validation message.

Step 4: Consume the Parameterized Entity from ABAP

Place this snippet inside an executable method or report:

DATA lv_from_date TYPE d VALUE '20261001'.
DATA lv_to_date   TYPE d VALUE '20261031'.

SELECT FROM ZI_FlightByDate(
    p_from_date = @lv_from_date,
    p_to_date   = @lv_to_date )
  FIELDS CarrierId,
         ConnectionId,
         FlightDate,
         CarrierName,
         SeatCapacity,
         OccupiedSeats
  WHERE CarrierId = 'LH'
  ORDER BY CarrierId, ConnectionId, FlightDate
  INTO TABLE @DATA(lt_flights).

Choose dates and a carrier present in your demonstration data.

Notice the distinction:

• $parameters.p_from_date references a parameter inside CDS.
• @lv_from_date passes an ABAP host variable.
• The additional WHERE condition filters the parameterized result.

Select explicit fields rather than SELECT *. That makes dependencies visible and avoids silently expanding an application’s result structure when the CDS model is extended.

Step 5: Extend the Existing Entity

Suppose reporting now requires the carrier’s currency code. The base join already exposes SCARR through alias Carrier, but does not project CURRCODE.

Create a separate data definition named ZX_FlightCarrier:

extend view entity ZI_FlightCarrier with
{
  Carrier.currcode as CarrierCurrency
}

Activate it, then reopen the base entity’s preview. CarrierCurrency should now be available.

The extension uses the original source alias. SAP’s extension lesson explicitly describes this requirement.

The base annotation #PROJECTION_LIST permits select-list extensions. For view-entity extensions, there is no extension name after with and no DDIC append-view annotation. SAP’s extension syntax overview documents these differences.

Important boundaries:

• An extension cannot add input parameters or new key fields.
• It is not a mechanism for rewriting the original join or filter.
• SAP-delivered entities require suitable extensibility settings and, where applicable, release contracts.
• Explicit downstream projections do not automatically expose the new element.

To return the currency through ZI_FlightByDate, add Flight.CarrierCurrency to that entity’s projection deliberately.

For a broader exercise involving custom tables and associations, consult SAP’s custom CDS extension tutorial.

Step 6: Validate Before Transport

My review checklist is short but non-negotiable:

• Cardinality: Compare base-table and joined row counts.
• Boundaries: Test a single-day interval and both interval endpoints.
• Empty results: Test dates without flights.
• Extensions: Confirm existing consumers still activate.
• Security: Test authorization behavior with representative users.
• Performance: Measure representative queries with ABAP SQL tracing or SQL Monitor where available.

CDS enables database-side execution, but does not guarantee efficient SQL. Inspect actual access patterns before adding further layers.

Conclusion

Build the base model around a clear grain. Add joins only after checking matching keys. Introduce parameters when inputs belong to the interface, and use extensions for supported additive changes.

The most valuable next step is to repeat the exercise with your own business sources—and prove row counts, authorization behavior, and performance before transport.

References

• CDS View Entities
• ABAP Core Data Services: New syntax for extending CDS …