Lesson 20 Companion — CDS and RAP Extension Reference

First, the idea

An application can be maintained by one team while another team needs a small enhancement. An extension object allows that enhancement to be developed separately, provided the owner has deliberately exposed an extension point.

For the guided SAP BTP ABAP Trial inspection application, the enhancement is easy to describe: display a readable priority and reject invalid priority codes. Those are two different requirements. The first belongs to the CDS data model; the second belongs to the RAP behavior.

Original Inspection BO
        |
        +-- CDS extension: ZZPriorityLabelZ20
        |
        +-- BDEF extension: checkPriority validation

The point is not to avoid changing all original objects. Before another team can extend them, the provider must explicitly opt in and design the contract. The point is that subsequent enhancements use separate artifacts instead of repeatedly modifying the provider's implementation.

---

1. A vocabulary that prevents confusion

Term	Practical meaning
Provider	Owner of the base table/CDS/BDEF
Extender	Developer who creates additional artifacts
Extension point	A provider-approved location for an extension
CDS view extension	Separate Data Definition with extend view entity
BDEF extension	Separate Behavior Definition with extension and extend behavior for
Extension behavior pool	Separate class implementing new behavior methods
C0 release	Contract for stable, supported extensibility
C1 release	Contract for stable, supported internal consumption

A released-for-consumption object is not necessarily released for extension. Check the intended API state and extension enablement separately.

2. What extends what?

ZINSP_###                         physical persistence
   |
ZR_INSP_###                       base CDS root
   |                                + ZX_INSP_V_###
base BDEF                         base behavior
   |                                + ZX_INSP_B_###
ZBP_R_INSP_###                     base behavior pool
                                    + ZBP_X_INSP_###

CDS extensions contribute to a queryable model. BDEF extensions contribute to allowed transactional operations and their implementation. These are separate mechanisms.

3. CDS enablement syntax

Provider CDS header:

@AbapCatalog.viewEnhancementCategory: [#PROJECTION_LIST]
@AbapCatalog.extensibility: {
  extensible: true,
  elementSuffix: 'Z20',
  allowNewDatasources: false,
  dataSources: ['Ticket'],
  quota: {
    maximumFields: 10,
    maximumBytes: 1000
  }
}

The quoted Ticket name must match the data-source alias in the CDS provider's as select from ... as Ticket clause.

The Z20 suffix controls extension element naming. In this lesson the added element is called ZZPriorityLabelZ20.

A source can disallow newly introduced data sources but still allow calculated fields based on a permitted existing alias.

4. CDS extension syntax

extend view entity ZR_Insp_### with
{
  @EndUserText.label: 'Priority Label'
  case
    when Ticket.priority = 'H'
      then cast( 'Urgent' as abap.char(12) )
    else cast( 'Routine' as abap.char(12) )
  end as ZZPriorityLabelZ20
}

The extension is a different Data Definition. The keyword does not belong inside the original define root view entity source.

The CASE expression produces a query result. No data is persisted in a zz_priority_label column.

Known limitation of this first example

The CASE expression treats anything except H as Routine. By itself it is not a validation. The BDEF extension prevents unsupported values from being saved through the RAP BO. The two extensions serve complementary purposes.

5. Why the base model opts in

Without extensibility enablement:

Extender asks to add field
             ↓
Provider contract says no
             ↓
Activation error

This is intentional. An owner may disallow certain new associations, fields, implementations, or changes for stability/security/performance reasons.

6. BDEF enablement syntax

Provider BDEF header:

managed implementation in class zbp_r_insp_### unique;
strict ( 2 );

extensible
{
  with validations on save;
}

Provider entity header:

define behavior for ZR_Insp_### alias Inspection
persistent table zinsp_###
lock master
authorization master ( none )
etag master LocalLastChangedAt
extensible
{
  ...
}

The header enablement determines which kinds of behavior are allowed. The entity-level extensible is also required.

strict ( 2 ) is a prerequisite for the behavior-extensibility syntax used here.

7. Behavior-extension syntax

For the self-owned base BO in this course:

extension implementation in class zbp_x_insp_### unique;

extend behavior for Inspection
{
  validation checkPriority on save
  {
    create;
    field Priority;
  }
}

An extension can use the existing entity alias. You do not repeat define behavior for or persistent table in this artifact.

The implementation class is separate from the base behavior pool.

SAP-delivered BO distinction

When extending SAP's standard BOs, the supported approach depends on released extension points and often uses an exposed RAP BO interface:

extension using interface <released_BO_interface>
  implementation in class <extension_pool> unique;

This line is illustrative, not a runnable template for our custom BO; we deliberately have no released BO interface in the guided exercise.

8. Validation-method contract

Let ADT generate the class and method signature. Its structure is equivalent to:

METHODS checkPriority FOR VALIDATE ON SAVE
  IMPORTING keys FOR Inspection~checkPriority.

keys identifies instances that triggered validation. In the extension handler, read their current fields using EML and write to failed-<alias> and reported-<alias>.

READ ENTITIES reads transactional state, including buffered changes, with or without IN LOCAL MODE. In a behavior extension, local mode bypasses only the extension's own feature-control and authorization implementations; it does not bypass those of the original BO. External console callers use normal EML. See SAP Help — Implementing the Behavior for the Node Extension.

9. Complete validation implementation

METHOD checkPriority.

  READ ENTITIES OF ZR_Insp_### IN LOCAL MODE
    ENTITY Inspection
    FIELDS ( Priority )
    WITH CORRESPONDING #( keys )
    RESULT DATA(inspections).

  LOOP AT inspections INTO DATA(inspection).

    IF inspection-Priority <> 'H'
       AND inspection-Priority <> 'N'.

      APPEND VALUE #(
        %tky = inspection-%tky
      ) TO failed-inspection.

      APPEND VALUE #(
        %tky = inspection-%tky
        %msg = new_message_with_text(
          severity = if_abap_behv_message=>severity-error
          text     = 'Priority must be H or N'
        )
        %element-Priority = if_abap_behv=>mk-on
      ) TO reported-inspection.

    ENDIF.

  ENDLOOP.

ENDMETHOD.

%tky identifies the failing transactional instance. %element-Priority connects the message to a particular field.

10. When does the check execute?

An on save validation is evaluated in the RAP save sequence.

MODIFY ENTITIES
  → request enters transactional buffer

COMMIT ENTITIES
  → save validation runs
  → valid: persist
  → invalid: FAILED + REPORTED; do not persist

A test which only checks FAILED immediately after MODIFY can incorrectly report success. Inspect the commit response.

After an unsuccessful save, use ROLLBACK ENTITIES or correct/clear the transactional buffer before attempting a fresh transaction. SAP documents this behavior explicitly.

11. Valid and invalid input matrix

Priority	Friendly CDS label	RAP save outcome
H	Urgent	Success
N	Routine	Success
X	Routine (CASE fallback)	Validation error; not saved
blank	Routine (CASE fallback)	Validation error; not saved

This table demonstrates why presentation logic must not be confused with business validation.

12. Physical extensions are different

To store a new field, developer extensibility often requires:

1. provider-enabled table or extension-include structure;
2. append structure (instead of editing provider's base table definition);
3. CDS extension exposing the persisted field;
4. BDEF mapping/field-control extension as applicable;
5. projection, UI metadata, and service exposure if users need to see it;
6. draft persistence handling if the original BO is draft-enabled.

SAP's reference pattern often places a provider-controlled extension include structure in both active and draft tables, then uses a customer append against the include. Our standalone BO uses no Draft and today's added field is calculated, so none of those extra artifacts is necessary.

13. Projection behavior extensions

The mandatory lesson tests through EML and CDS Data Preview. If an extended BO is also exposed as an OData service, do not assume its extension field or new action automatically appears in the UI.

For a full service scenario, check:

base root CDS
→ projection CDS (possibly extend it too)
→ projection behavior (possibly extend it)
→ UI metadata extension
→ Service Definition / Service Binding
→ Fiori Elements Preview

Projection behavior extensions use:

extension for projection;

and extend behavior for ... to reuse newly added actions or other supported features as required.

14. S/4HANA extensibility models

Model	What it means	Actual lab situation
On-stack developer	Develop extensions in an S/4HANA ABAP environment through permitted extension points	The same ideas are practiced on our own objects, not SAP-delivered S/4HANA BOs
Key user	Use S/4HANA's business-oriented custom-field/logic apps	Not provided by standard BTP ABAP Trial
Side-by-side	Build on BTP and integrate with released S/4HANA APIs	Covered by our later integration project, subject to API access

CDS/RAP extensibility does not equal remote API consumption. That distinction leads into Lesson 21 (Clean Core & Released APIs).

15. C0 vs C1

Contract	Question answered
C0	Is this a supported stable extension point?
C1	Is this a supported stable internal consumption API?

A provider can permit some extension types while denying others. There is no guarantee that every CDS view or every SAP BO can be extended. Always check release state and allowed extensibility scope in ADT.

Our custom, self-owned trial lab demonstrates the syntax and concepts but does not imply that its objects have a formal C0 release contract.

16. Common errors and reliable fixes

Problem	Likely cause	Check
extend view entity activation error	Provider not extensible	CDS annotations, permitted fields and aliases
Suffix error	Wrong extension field name	elementSuffix: 'Z20'
Unknown Ticket	Alias mismatch	as select from ... as Ticket
extensible BDEF error	Missing strict mode	strict ( 2 );
validation rejected in extension	Missing permission	Header with validations on save;
Wrong reported component	Alias differs	Inspection alias and generated method
X record saved	Test only checked modify result	COMMIT ENTITIES RESPONSE OF ...
UI field missing	Only base CDS was extended	Projection CDS/metadata/service chain
Working on SAP-delivered BO in Trial	Wrong landscape	Own the lab BO; SAP on-stack extensions need supported S/4HANA access

17. Technical review questions

• Where must extensible be declared for behavior extensions?
• Why does with validations on save matter?
• What is the difference between the provider's original class and the extension behavior pool?
• Why should data validation happen in RAP rather than only in CDS CASE?
• What steps are necessary before a new persisted field appears on a draft-enabled OData service?
• Why should a C1 release alone not be treated as permission to extend SAP code?

18. Official verification sources

• SAP Learning — Enabling and Developing Behavior Extensions
• SAP Learning — Developing Data Model Extensions
• SAP Developer Center — Extend a Custom Core Data Service in ABAP Environment
• SAP Help — Enabling the Database Tables
• SAP Help — Validation

Scope of verification: Examples follow SAP's current documented syntax and behavior. They have not been compiled in your specific BTP Trial tenant. Keep the guided activation checkpoints: they catch system-release and ADT-generation differences rather than hiding them.