CDS View Extensions in SAP S/4HANA Cloud Private Edition: Architecture, Tools, and What Matters

***Applies to: SAP S/4HANA Cloud Private Edition 2023 FPS01 and later. CDS extension mechanics apply from S/4HANA 1909 onwards; the Joule connectivity described here requires 2023 FPS01+***

Part 1 of 2 | Series: Your SAP S/4HANA Data Model Is Your AI Strategy

Picture this scenario. As part of an SAP S/4HANA Cloud Private Edition transformation project, your company has just enabled Joule on the SAP Fiori Launchpad. The demo has gone well. The finance lead is keen. Within the first week she asks: “Can Joule tell me the margin by our internal product tier classification?”

The answer is it cannot. Not because Joule can’t surface it, but because your product tier classification has been sitting in a Z-table since the SAP ERP days and was never added to any CDS view. From where Joule sits, that data does not exist. The same gap is blocking the OData API your integration team wants to expose. The same gap is blocking the SAC model your analytics team is trying to build.

One missing CDS extension. Three blocked workstreams.

That is the argument for getting CDS extensions right. Not one platform. All of them.

Supporting customers in my role as SAP S/4HANA RIG solution architect, I see this pattern on almost every transformation engagement and it rarely arrives alone.

Now picture the procurement lead sends a different request that same week: “Can we get planned delivery time into the purchasing analytics dashboard?”  This one looks identical from the outside – another field Joule and SAC cannot see – but the cause is different. Planned delivery time already exists in SAP’s database. It is standard SAP data that simply has not been promoted to any released CDS view. No Z-table, no custom logic, but the fix is not the same either.

Two situations. Same symptom. Different cause. Different path. Let’s work through both.

The SAP S/4HANA Cloud Private Edition Context

In SAP S/4HANA Cloud Private Edition, SAP manages the HANA database, application server, and OS layers on hyperscaler or SAP’s own infrastructure. You own the application configuration, the transport landscape, and the extension estate. That split matters more than it sounds.

The release rhythm is: a base release every two years (S/4HANA 2023, 2025, 2027), Feature Pack Stacks every six months within a base release, delivering incremental innovations, and Support Pack Stacks after mainstream cutover, carrying only fixes. Mainstream maintenance runs seven years per base release. Under RISE with SAP, SAP executes the upgrade; you own the readiness work and the cutover decision.

In practice, that means upgrade preparation sits on your plate, and the quality of your extension determines how much of that preparation is analysis versus remediation.

Here is what upgrade readiness actually means for extensions. SAP runs the Software Update Manager (SUM) against your development system. As part of that process, ABAP activation checks run against every object in the customer namespace. Any extension that references an internal SAP object that has changed, which can be a view structure, a table field, or an association cardinality, will throw an activation error. Those errors block the transport chain. You cannot promote to QA or production until every activation failure in the development system is resolved, re-tested and re-transported. On a program with 50–100 custom extension objects, even three or four failures, you can add hours to days to a cutover window that is usually already tight.

The mechanism that prevents this is the C1 release contract. When SAP marks a CDS view as C1-released, it is a formal architectural commitment: the view’s interface, its field names, types, and association signatures, will not change in ways that break downstream consumers. If your extension targets a C1-released view using EXTEND VIEW ENTITY, SAP owns the upgrade compatibility. If you’ve extended an unreleased view, used a Z-copy of a standard view, or written Classic ABAP that reads internal table structures directly, there is no contract and no guarantee. The ABAP Test Cockpit (ATC) will tell you how exposed you are; running it against your extension estate before each FPS is not optional, it’s the earliest point at which you find out what needs to be fixed.

On-premise teams have exactly the same structural problem. The difference is that on-premise teams control the upgrade schedule and can defer it. In SAP S/4HANA Cloud Private Edition, that deferral option is limited; you stay current, or you fall out of mainstream maintenance. That is why the extension quality conversation that on-premise programs have been able to postpone tends to arrive earlier and more urgently for SAP S/4HANA Cloud Private Edition.

The Extensibility Stack: Where CDS Extensions Fit

SAP S/4HANA Cloud Private Edition supports the full SAP extensibility portfolio. Understanding where CDS extensions sit within it matters before choosing your approach.

CDS view extensions, written as EXTEND VIEW ENTITY in ADT, sit in the Developer In-App tier. When targeting C1-released views, they are Level A: ABAP Cloud compliant and fully upgrade-safe.

One practical note specific to SAP S/4HANA Cloud Private Edition: in a system configured with the ABAP Cloud language version, the compiler will reject references to unreleased objects. This is not a warning; it is a build failure. That enforcement mechanism is one of the more useful guardrails the platform provides.

Clean Core, Release Contracts, and Upgrade Safety

The A–D Classification

SAP’s Clean Core framework maps to something concrete: whether your extension object activates cleanly after an upgrade without manual intervention.

Level A costs upfront discipline — checking release contracts, following the bottom-up propagation pattern, using the right syntax. That investment is front-loaded: a few extra steps at build time that translate into a quieter, lower-risk upgrade cycle. Level C and D extensions tend to surface at upgrade time as activation failures that need to be resolved before cutover.

Release Contracts

Before extending any CDS view, check its release contract. This is the formal binding between SAP and you on interface stability.

In ADT, open the target view and navigate to the API State tab. A C1 or C0 contract means SAP has committed to not changing the interface in ways that break extensions. @vdm.lifecycle.contract.type: #PUBLIC_LOCAL_API is a further contract type indicating a stable, released public interface — also safe to build on.

The Virtual Data Model: Your Extension Target

SAP’s Virtual Data Model is a semantic stack with deliberate layering:The rule that matters most: extend at the lowest layer where the data lives and let it propagate up. If you only extend the consumption view, the OData service bound to the interface view won’t see your field. If you extend the interface view, every consumer up the stack including OData, SAC, Fiori, Joule inherits it automatically.

You can see this layering live in the Fiori View Browser app (F2170). Search for I_PurchaseOrderItemAPI01, which is the view used in the code examples throughout this post. The results list shows its VDM View Type as Basic, confirming this is the interface layer: above the physical database, below the consumption views. This is the layer your extension targets.

In ADT, the view type is declared explicitly on every SAP-delivered VDM view via @vdm.viewType: #BASIC, #COMPOSITE, or #CONSUMPTION. This annotation drives behaviour in SAC, Embedded Analytics, and Fiori Elements, and tells you which layer you’re working with before writing a single line of extension code.

Never extend P_* (private) views: no release contract, subject to change by SAP without notice.

Two Kinds of Data Gap

Two distinct situations produce the same symptom – a consumer that cannot find the data it needs. Diagnosing which one you are dealing with determines your path.

Gap 1: A Standard SAP Field Not Yet Exposed

The field exists in a standard SAP table, such as EKPO, MARA, LFA1, VBAP, but no released CDS view has ever selected it. This is more common than expected. SAP has exposed the majority of high-traffic fields through released views, but the long tail of table columns that matter to specific business scenarios is substantial.

First step: confirm with Alternative Search in View Browser (F2170)

Before concluding a field is unavailable, use the Alternative Search function. Open the View Browser (F2170), switch to the Alternative Search tab, and enter the table name and field name. This searches across all released CDS views for any that read that field from that table — including views you would not have found by name.

If no results carry the Released status, even if internal views reference the field, it is not accessible through any stable CDS interface. PLIFZ returns 86 views in this search shown above. None are Released. From Joule, SAC, or any OData client, this field does not exist.

Once confirmed, three paths forward in clean core preference order:

Option 1 — Key User path (cleanest)

Check whether the field’s business context is available in the Custom Fields app (F1481). If it is, add the field as a key user extension. SAP handles CDS propagation and OData registration automatically. No developer code required and the result is Level A clean core.

Option 2 — Wrapper view (developer path)

If the key user path is not available, build a minimal custom CDS view that reads the fields directly from the SAP standard table, then extend the released interface view with an association to this wrapper. The wrapper reads unreleased SAP table structures — Level C in the clean core model. It works and can be made stable, but it carries an upgrade risk if SAP restructures the underlying table. Document it explicitly, add the base table to your Simplification List checks before each FPS and track it as technical debt until SAP delivers a clean release.

Note on ABAP Cloud mode: In an SAP S/4HANA Cloud Private Edition system configured with ABAP Cloud language version, direct access to unreleased tables like EKPO will be rejected at compile time. Option 1 or Option 3 are the only supported paths in that configuration.

— Wrapper view: reads unreleased SAP table directly (Level C in clean core)
— Only build this after confirming the field is not already exposed
— using Alternative Search in View Browser (F2170)

Option 3 — Request SAP to release the field

Submit a feature request via . SAP reviews these and adds fields to released CDS views based on demand. The right long-term resolution when the field is strategically important, and the wrapper approach introduces unacceptable upgrade risk.

Gap 2: Custom Business Data

If the data was never part of SAP’s standard model — it lives in a Z-table carried over from an SAP ERP landscape, or was built fresh during the current implementation — Alternative Search will return nothing by design. The field isn’t missing from SAP’s views; it simply doesn’t exist in SAP’s data model at all.

The resolution here is the developer extension pattern: build a CDS view on your custom table, then extend the relevant SAP interface view with an association to it. The data stays in your Z-table, the CDS layer becomes the bridge. Every consumer above, including OData, SAC, Fiori, Joule, gains access through that association. The worked example later in this post walks through this .

The Extension Toolkit: Key User and Developer Paths

Once you know what gap you are filling, you have two supported extension paths in SAP S/4HANA Cloud Private Edition. They are deliberately separate and cannot directly consume each other’s outputs.

The Key User Lane

Custom Fields app (F1481) — No ABAP, no ADT. Create custom fields, extend data sources, and implement custom logic within a form-based UI. When a view is available as a data source in this app, the platform handles CDS propagation, OData registration, and Fiori field placement automatically. The result is Level A clean core.

Custom CDS Views app (F1866A) — A guided SAP Fiori application for building analytical and external API views without code. Select a scenario (Analytical Cube, Standard CDS View, or External API), choose from released SAP data sources, define joins through a form, and activate. The system generates the CDS source.

Use it when: your requirement is analytical reporting or a simple external API, all data sources are released SAP views, and the logic fits what the form can express.

Hard limits: you cannot use it if you need association-based views also exposed as OData (mutually exclusive in the app) or if your data source is a Z-table. Custom CDS Views created here carry no C1 release contract. In ABAP Cloud development (the standard for Level A clean core), they cannot be consumed as a data source. Classic ABAP can access them, but at the cost of coupling key user and developer extensibility layers, which is worth documenting as a dependency. The reverse also holds: views extended through ADT cannot be used as data sources in the app.

The Developer Lane

Code-first, full CDS DDL language, managed in your own development project in ADT. This is the path for anything the app can’t handle: extending existing SAP views bottom-up through the full VDM stack, working with RAP business objects, or building the data model foundation that feeds a Joule skill.

The template you select in the ADT New Data Definition wizard depends on the base view type:

• define view → select Extend View template → syntax: extend view Base with ExtensionName { }
• define view entity → select Extend View Entity template → syntax: extend view entity Base with { }

Most standard SAP VDM views in older S/4HANA releases use the classic define view syntax. Newer RAP-based views use define view entity. Always check the first line of the target view in ADT — the two syntaxes are not interchangeable.

Before You Extend: Three Checks

Whether you’re coming from Gap 1 or Gap 2, these checks apply to the target view before writing extension code.

1. API State in ADT: C1, C0, or #PUBLIC_LOCAL_API contract. @Metadata.allowExtensions: true indicates direct metadata extension support. Registration in SCFD_REGISTRY (check 2) is the complementary signal for field-list extensions via EXTEND VIEW ENTITY.

1. SCFD_REGISTRY: Views registered here are explicitly designed for extension. The Custom Fields app (F1481) can also drive extensions to them.

1. Structural blockers — Views using GROUP BY, UNION, or UNION ALL cannot have their select list extended. Check @AbapCatalog.viewEnhancementCategory. If it’s #NONE, build a custom view on top instead.

The Core Pattern: Extending for Custom Business Data

The following section works through a complete extension for the Gap 2 scenario: custom business data in a Z-table that needs to be visible to Joule, SAC, and a custom OData service.

Choosing your method

Before writing a line of code, understand which of the three developer-side methods applies. They produce different results and are not interchangeable.

How to choose in practice:

• Open the Custom Fields app (F1481). If the view appears in the data source list as Released, use the key user path.
• Open the view in ADT. If you see a pre-defined _Extension association pointing to an E_* include view, SAP has pre-wired an extension point. Add an append to the include structure and extend the view to expose the field, and no Z-table is needed.
• If neither applies, the view is not in the Custom Fields app (F1481) and has no pre-wired extension include, use the Z-table approach below.

What the worked example uses: the Z-table + Extend View path. This is the most general approach and the one most commonly needed for custom enrichment scenarios. It requires the most manual steps but gives you complete control over the data model.

Worked Example

A manufacturing company needs to add a sustainability certification reference (ZZ_SUSTAIN_CERT_REF) to purchase order items so it is available for Datasphere replication, custom analytical queries and downstream applications built on the extended CDS view.

Step 1, Create the custom extension table. Create a transparent Z-table (ZPOITEM_SUST) with MANDT, EBELN (PurchaseOrder), and EBELP (PurchaseOrderItem) as key fields, plus ZZ_SUSTAIN_CERT_REF as the payload field. Create a basic CDS view (ZI_POItemSustain) on top of it. This table is the data store for the extension; the CDS view makes it joinable from the standard view layer.

Step 2, Extend the interface view:

@AbapCatalog.sqlViewAppendName: ‘ZEXPOITEMSUST’
@EndUserText.label: ‘Extend PO Item — Sustainability Cert’

extend view I_PurchaseOrderItemAPI01
  with ZEX_I_PurchaseOrderItemAPI01
  association [0..1] to ZI_POItemSustain as _ZPOItemSustain
    on  $projection.PurchaseOrder     = _ZPOItemSustain.PurchaseOrder
    and $projection.PurchaseOrderItem = _ZPOItemSustain.PurchaseOrderItem
{
  — Expose the field from the extension table
  _ZPOItemSustain.ZZ_SustainCertRef,

  — Expose the association so path expressions work downstream
  _ZPOItemSustain
}

Syntax note: I_PurchaseOrderItemAPI01 uses the classic define view syntax, so its extension uses extend view Base with ExtensionName { } with a mandatory @AbapCatalog.sqlViewAppendName annotation. Select the Extend View template in ADT. Use $projection.FieldName in association ON conditions to qualify base view fields and avoid ambiguity errors.

Step 3a, Verify at the CDS layer:

With ZEX_I_PurchaseOrderItemAPI01 activated, ZZ_SustainCertRef is now part of the extended I_PurchaseOrderItemAPI01 view. Verify by opening the view in ADT and pressing F8 (Data Preview). The column should appear alongside standard PO item fields. Add a row to ZPOITEM_SUST for a real PO item first so you have a non-null value to confirm.

Step 3b, Expose via a custom OData service:

The standard SAP purchase order API (API_PURCHASEORDER_PROCESS_SRV) has an explicit contract and does not inherit CDS view extensions. To expose ZZ_SustainCertRef via OData, you need a custom service definition and binding.

Create and Activate the Service Definition

• Name: ZSD_POITEMSUSTAIN

@EndUserText.label: ‘PO Item Sustainability Extension’
define service ZSD_POITEMSUSTAIN {
  expose I_PurchaseOrderItemAPI01 as PurchaseOrderItem;
}

Create, Activate and Publish the Service Binding

• Name: ZSB_POITEMSUSTAIN
• Binding Type: OData V4 – Web API
• Service Definition: ZSD_POITEMSUSTAIN

The editor shows the service URL once published.

Append /$metadata to the service URL and search for ZZ_SustainCertRef. It will appear as a property on the PurchaseOrderItem entity type. Query the entity set for a PO item that has a row in ZPOITEM_SUST to confirm the value is returned.

Joule: The custom OData service published here is the data source for a Joule skill. Register ZSB_POITEMSUSTAIN as a BTP destination, point a Joule skill at that endpoint, and Joule can surface ZZ_SustainCertRef in natural language responses alongside standard PO item data. The CDS extension is the foundation, one field added at the interface layer, surfaced through every consumer that reads from the service.

What this extension does not do automatically: expose the field in SAP’s standard A2X API (API_PURCHASEORDER_PROCESS_SRV) or in the standard Fiori UI. For Fiori UI visibility, the same extend view pattern applies to the item-level consumption view that backs your target app.  Identify it in View Browser (F2170) and add an equivalent extension with @UI annotations. For standard API exposure, the supported path is the Custom Fields app (F1481), which handles the service registration as part of the key user extensibility flow.

Performance Considerations

A few principles worth stating upfront, before they become debugging sessions later.

Use associations, not joins, for optional enrichment data. An association resolves only when a consumer navigates it. A join executes unconditionally on every query. For custom enrichment tables — classification data, custom attributes, legacy reference data — associations are almost always the right choice. A poorly placed join on I_JournalEntryItem (backed by ACDOCA with hundreds of millions of rows in production) can have a significant impact on query response time.

Declare cardinality accurately. [0..1] vs [1..1] on an association is not cosmetic. Incorrect cardinality can cause the query optimiser to generate multiply-joining plans, producing duplicate rows or forcing outer joins where inner joins would suffice.

Avoid calculated fields in ON and WHERE clauses. Computed expressions in join conditions prevent HANA from pushing predicates to the storage layer. The result is a scan instead of a seek.

Validate with ST05 and ADT Dependency Analyser after activation. What runs in 200ms on a sandbox with 50,000 rows may behave differently on a production system with 800 million. Test with realistic data volumes before promoting to quality.

Pre-Flight Checklist Before You Extend

Before writing a line of code on any SAP S/4HANA Cloud Private Edition extension:

• ☐ Base view has C1, C0, or #PUBLIC_LOCAL_API contract, verified in ADT API State tab
• ☐ View registered in SCFD_REGISTRY, or @Metadata.allowExtensions: true present on the base view
• ☐ Enhancement category is not #NONE
• ☐ No GROUP BY or UNION in the base view
• ☐ Gap type confirmed: standard SAP field (Alt Search in View Browser first) or custom data
• ☐ Bottom-up propagation plan mapped out, every layer from DB to consumption
• ☐ Extension object created in ABAP Cloud software component (compiler enforces release contract compliance)
• ☐ Associations used for optional data, no unconditional joins on high-volume views
• ☐ Cardinality declared accurately on all associations
• ☐ Naming convention followed: ZEX_I_*, ZEX_C_*, ZEX_Q_*
• ☐ Transport dependency order documented, extension activates after base view

Governance Checklist Per Extension

For architect sign-off on any extension going to quality:

• ☐ Release contract confirmed (ADT + SCFD_REGISTRY)
• ☐ ABAP Cloud software component used, compiler passes without released-object violations
• ☐ All VDM layers propagated bottom-up, confirmed end-to-end in the Fiori app and OData service
• ☐ Performance reviewed, ST05 trace run on production-scale data
• ☐ Simplification List checked, base objects not deprecated in target release
• ☐ Downstream consumers inventoried: Fiori apps, SAC, Datasphere, OData clients, Joule skills if applicable
• ☐ If OData exposure needed: service definition and binding created, BTP destination configured
• ☐ Transport landscape validated, correct promotion order in dev → QA → prod

Part 2 picks up here: six situations you are likely to encounter on SAP S/4HANA Cloud Private Edition projects, with the exact technical detail of what goes wrong and why, and the full architecture chain from CDS extension to working Joule skill, end to end.

Official SAP References

CDS View Extension, Language & Syntax

• ABAP CDS, CDS Entity Extension (EXTEND VIEW ENTITY), ABAP Keyword Documentation
• Extending CDS Views (ABAP RAP). SAP Help Portal
• CDS-Enabling Architecture (extensibility annotations). SAP Help Portal

Clean Core & Developer Extensibility

• Clean Core Extensibility Principles. SAP Developer Center
• Developer Extensibility in SAP S/4HANA Cloud. SAP Help Portal
• ABAP Extensibility Guide, Clean Core for SAP S/4HANA Cloud. SAP Community (August 2025)
• Clean Core Extensibility in SAP S/4HANA Cloud SAP S/4HANA Cloud Private Edition, SAP.com

Key User Tools

• Custom CDS Views App, Key Features. SAP Help Portal
• Custom CDS Views, FAQ. SAP Community

SAP S/4HANA Cloud Private Edition Release & Upgrade

• Navigating Release Upgrades in SAP S/4HANA Cloud Private Edition. SAP Learning

Finding Released APIs

• SAP Business Accelerator Hub, Central catalogue of released APIs and CDS views

Brought to you by the SAP S/4HANA RIG team.

*** This post was written with AI assistance***

 ***Applies to: SAP S/4HANA Cloud Private Edition 2023 FPS01 and later. CDS extension mechanics apply from S/4HANA 1909 onwards; the Joule connectivity described here requires 2023 FPS01+***Part 1 of 2 | Series: Your SAP S/4HANA Data Model Is Your AI StrategyPicture this scenario. As part of an SAP S/4HANA Cloud Private Edition transformation project, your company has just enabled Joule on the SAP Fiori Launchpad. The demo has gone well. The finance lead is keen. Within the first week she asks: “Can Joule tell me the margin by our internal product tier classification?”The answer is it cannot. Not because Joule can’t surface it, but because your product tier classification has been sitting in a Z-table since the SAP ERP days and was never added to any CDS view. From where Joule sits, that data does not exist. The same gap is blocking the OData API your integration team wants to expose. The same gap is blocking the SAC model your analytics team is trying to build.One missing CDS extension. Three blocked workstreams.That is the argument for getting CDS extensions right. Not one platform. All of them.Supporting customers in my role as SAP S/4HANA RIG solution architect, I see this pattern on almost every transformation engagement and it rarely arrives alone.Now picture the procurement lead sends a different request that same week: “Can we get planned delivery time into the purchasing analytics dashboard?”  This one looks identical from the outside – another field Joule and SAC cannot see – but the cause is different. Planned delivery time already exists in SAP’s database. It is standard SAP data that simply has not been promoted to any released CDS view. No Z-table, no custom logic, but the fix is not the same either.Two situations. Same symptom. Different cause. Different path. Let’s work through both.The SAP S/4HANA Cloud Private Edition ContextIn SAP S/4HANA Cloud Private Edition, SAP manages the HANA database, application server, and OS layers on hyperscaler or SAP’s own infrastructure. You own the application configuration, the transport landscape, and the extension estate. That split matters more than it sounds.The release rhythm is: a base release every two years (S/4HANA 2023, 2025, 2027), Feature Pack Stacks every six months within a base release, delivering incremental innovations, and Support Pack Stacks after mainstream cutover, carrying only fixes. Mainstream maintenance runs seven years per base release. Under RISE with SAP, SAP executes the upgrade; you own the readiness work and the cutover decision.In practice, that means upgrade preparation sits on your plate, and the quality of your extension determines how much of that preparation is analysis versus remediation.Here is what upgrade readiness actually means for extensions. SAP runs the Software Update Manager (SUM) against your development system. As part of that process, ABAP activation checks run against every object in the customer namespace. Any extension that references an internal SAP object that has changed, which can be a view structure, a table field, or an association cardinality, will throw an activation error. Those errors block the transport chain. You cannot promote to QA or production until every activation failure in the development system is resolved, re-tested and re-transported. On a program with 50–100 custom extension objects, even three or four failures, you can add hours to days to a cutover window that is usually already tight.The mechanism that prevents this is the C1 release contract. When SAP marks a CDS view as C1-released, it is a formal architectural commitment: the view’s interface, its field names, types, and association signatures, will not change in ways that break downstream consumers. If your extension targets a C1-released view using EXTEND VIEW ENTITY, SAP owns the upgrade compatibility. If you’ve extended an unreleased view, used a Z-copy of a standard view, or written Classic ABAP that reads internal table structures directly, there is no contract and no guarantee. The ABAP Test Cockpit (ATC) will tell you how exposed you are; running it against your extension estate before each FPS is not optional, it’s the earliest point at which you find out what needs to be fixed.On-premise teams have exactly the same structural problem. The difference is that on-premise teams control the upgrade schedule and can defer it. In SAP S/4HANA Cloud Private Edition, that deferral option is limited; you stay current, or you fall out of mainstream maintenance. That is why the extension quality conversation that on-premise programs have been able to postpone tends to arrive earlier and more urgently for SAP S/4HANA Cloud Private Edition.The Extensibility Stack: Where CDS Extensions FitSAP S/4HANA Cloud Private Edition supports the full SAP extensibility portfolio. Understanding where CDS extensions sit within it matters before choosing your approach.CDS view extensions, written as EXTEND VIEW ENTITY in ADT, sit in the Developer In-App tier. When targeting C1-released views, they are Level A: ABAP Cloud compliant and fully upgrade-safe.One practical note specific to SAP S/4HANA Cloud Private Edition: in a system configured with the ABAP Cloud language version, the compiler will reject references to unreleased objects. This is not a warning; it is a build failure. That enforcement mechanism is one of the more useful guardrails the platform provides.Clean Core, Release Contracts, and Upgrade SafetyThe A–D ClassificationSAP’s Clean Core framework maps to something concrete: whether your extension object activates cleanly after an upgrade without manual intervention.LevelWhat it meansCDS extensions land here when…AABAP Cloud compliant, released objects onlyTargeting C1/C0-released views with EXTEND VIEW ENTITYBStable interfaces, not fully cloud-readyExtending views with partial release contractsCReferences internal SAP artifactsUsing unreleased views or internal objectsDDirect modification of SAP standardNot appropriateLevel A costs upfront discipline — checking release contracts, following the bottom-up propagation pattern, using the right syntax. That investment is front-loaded: a few extra steps at build time that translate into a quieter, lower-risk upgrade cycle. Level C and D extensions tend to surface at upgrade time as activation failures that need to be resolved before cutover.Release ContractsBefore extending any CDS view, check its release contract. This is the formal binding between SAP and you on interface stability.ContractNameWhat it meansWhat it enablesC0ExtendStability at defined extension points only. Has two visibility scopes: Use in Key User Apps or Use in Cloud Development — or bothCDS view extensions, append structures, BAdIs. Use in Key User Apps scope makes the view available in Custom Fields & Logic (F1481) and SCFD_REGISTRY toolsC1Use System-InternallyStable public interface guaranteed for use within the ABAP system. SAP will not change the interface in ways that break downstream consumers after an upgradeUsing the view as a data source in custom ABAP development within the same systemC2Use as Remote APIStable public interface guaranteed for use outside the ABAP systemConsuming the view via OData, remote function calls, or external API clientsNo contract / internalUnreleasedNo stability guarantee — SAP can change or remove the object without noticeNothing. Referencing these places your extension at Level C or D in the clean core classificationIn ADT, open the target view and navigate to the API State tab. A C1 or C0 contract means SAP has committed to not changing the interface in ways that break extensions. @vdm.lifecycle.contract.type: #PUBLIC_LOCAL_API is a further contract type indicating a stable, released public interface — also safe to build on.The Virtual Data Model: Your Extension TargetSAP’s Virtual Data Model is a semantic stack with deliberate layering:The rule that matters most: extend at the lowest layer where the data lives and let it propagate up. If you only extend the consumption view, the OData service bound to the interface view won’t see your field. If you extend the interface view, every consumer up the stack including OData, SAC, Fiori, Joule inherits it automatically.You can see this layering live in the Fiori View Browser app (F2170). Search for I_PurchaseOrderItemAPI01, which is the view used in the code examples throughout this post. The results list shows its VDM View Type as Basic, confirming this is the interface layer: above the physical database, below the consumption views. This is the layer your extension targets.In ADT, the view type is declared explicitly on every SAP-delivered VDM view via @vdm.viewType: #BASIC, #COMPOSITE, or #CONSUMPTION. This annotation drives behaviour in SAC, Embedded Analytics, and Fiori Elements, and tells you which layer you’re working with before writing a single line of extension code.Never extend P_* (private) views: no release contract, subject to change by SAP without notice.Two Kinds of Data GapTwo distinct situations produce the same symptom – a consumer that cannot find the data it needs. Diagnosing which one you are dealing with determines your path.Gap 1: A Standard SAP Field Not Yet ExposedThe field exists in a standard SAP table, such as EKPO, MARA, LFA1, VBAP, but no released CDS view has ever selected it. This is more common than expected. SAP has exposed the majority of high-traffic fields through released views, but the long tail of table columns that matter to specific business scenarios is substantial.First step: confirm with Alternative Search in View Browser (F2170)Before concluding a field is unavailable, use the Alternative Search function. Open the View Browser (F2170), switch to the Alternative Search tab, and enter the table name and field name. This searches across all released CDS views for any that read that field from that table — including views you would not have found by name.If no results carry the Released status, even if internal views reference the field, it is not accessible through any stable CDS interface. PLIFZ returns 86 views in this search shown above. None are Released. From Joule, SAC, or any OData client, this field does not exist.Once confirmed, three paths forward in clean core preference order:Option 1 — Key User path (cleanest)Check whether the field’s business context is available in the Custom Fields app (F1481). If it is, add the field as a key user extension. SAP handles CDS propagation and OData registration automatically. No developer code required and the result is Level A clean core.Option 2 — Wrapper view (developer path)If the key user path is not available, build a minimal custom CDS view that reads the fields directly from the SAP standard table, then extend the released interface view with an association to this wrapper. The wrapper reads unreleased SAP table structures — Level C in the clean core model. It works and can be made stable, but it carries an upgrade risk if SAP restructures the underlying table. Document it explicitly, add the base table to your Simplification List checks before each FPS and track it as technical debt until SAP delivers a clean release.Note on ABAP Cloud mode: In an SAP S/4HANA Cloud Private Edition system configured with ABAP Cloud language version, direct access to unreleased tables like EKPO will be rejected at compile time. Option 1 or Option 3 are the only supported paths in that configuration.– Wrapper view: reads unreleased SAP table directly (Level C in clean core)– Only build this after confirming the field is not already exposed– using Alternative Search in View Browser (F2170)Option 3 — Request SAP to release the fieldSubmit a feature request via . SAP reviews these and adds fields to released CDS views based on demand. The right long-term resolution when the field is strategically important, and the wrapper approach introduces unacceptable upgrade risk.Gap 2: Custom Business DataIf the data was never part of SAP’s standard model — it lives in a Z-table carried over from an SAP ERP landscape, or was built fresh during the current implementation — Alternative Search will return nothing by design. The field isn’t missing from SAP’s views; it simply doesn’t exist in SAP’s data model at all.The resolution here is the developer extension pattern: build a CDS view on your custom table, then extend the relevant SAP interface view with an association to it. The data stays in your Z-table, the CDS layer becomes the bridge. Every consumer above, including OData, SAC, Fiori, Joule, gains access through that association. The worked example later in this post walks through this .The Extension Toolkit: Key User and Developer PathsOnce you know what gap you are filling, you have two supported extension paths in SAP S/4HANA Cloud Private Edition. They are deliberately separate and cannot directly consume each other’s outputs.The Key User LaneCustom Fields app (F1481) — No ABAP, no ADT. Create custom fields, extend data sources, and implement custom logic within a form-based UI. When a view is available as a data source in this app, the platform handles CDS propagation, OData registration, and Fiori field placement automatically. The result is Level A clean core.Custom CDS Views app (F1866A) — A guided SAP Fiori application for building analytical and external API views without code. Select a scenario (Analytical Cube, Standard CDS View, or External API), choose from released SAP data sources, define joins through a form, and activate. The system generates the CDS source.Use it when: your requirement is analytical reporting or a simple external API, all data sources are released SAP views, and the logic fits what the form can express.Hard limits: you cannot use it if you need association-based views also exposed as OData (mutually exclusive in the app) or if your data source is a Z-table. Custom CDS Views created here carry no C1 release contract. In ABAP Cloud development (the standard for Level A clean core), they cannot be consumed as a data source. Classic ABAP can access them, but at the cost of coupling key user and developer extensibility layers, which is worth documenting as a dependency. The reverse also holds: views extended through ADT cannot be used as data sources in the app.The Developer LaneCode-first, full CDS DDL language, managed in your own development project in ADT. This is the path for anything the app can’t handle: extending existing SAP views bottom-up through the full VDM stack, working with RAP business objects, or building the data model foundation that feeds a Joule skill.The template you select in the ADT New Data Definition wizard depends on the base view type:define view → select Extend View template → syntax: extend view Base with ExtensionName { }define view entity → select Extend View Entity template → syntax: extend view entity Base with { }Most standard SAP VDM views in older S/4HANA releases use the classic define view syntax. Newer RAP-based views use define view entity. Always check the first line of the target view in ADT — the two syntaxes are not interchangeable.Before You Extend: Three ChecksWhether you’re coming from Gap 1 or Gap 2, these checks apply to the target view before writing extension code.API State in ADT: C1, C0, or #PUBLIC_LOCAL_API contract. @Metadata.allowExtensions: true indicates direct metadata extension support. Registration in SCFD_REGISTRY (check 2) is the complementary signal for field-list extensions via EXTEND VIEW ENTITY.SCFD_REGISTRY: Views registered here are explicitly designed for extension. The Custom Fields app (F1481) can also drive extensions to them.Structural blockers — Views using GROUP BY, UNION, or UNION ALL cannot have their select list extended. Check @AbapCatalog.viewEnhancementCategory. If it’s #NONE, build a custom view on top instead.The Core Pattern: Extending for Custom Business DataThe following section works through a complete extension for the Gap 2 scenario: custom business data in a Z-table that needs to be visible to Joule, SAC, and a custom OData service.Choosing your methodBefore writing a line of code, understand which of the three developer-side methods applies. They produce different results and are not interchangeable.MethodHowOData / Fiori handledBest forKey User — Custom Fields (F1481)Fiori UI, no ABAPAutomatically — standard UI, OData, and Fiori field placement wired up by the platformSimple fields in released views, where standard Fiori UI placement is the goalDeveloper — Extension IncludeADT: append to an SAP-provided E_* include structure; extend the view to expose itPartially — field is in the view; OData exposure still needs a custom Service BindingViews with a pre-registered extension include (_Extension association visible in ADT); cleanest developer path when availableDeveloper — Z-table + Extend ViewADT: custom Z-table, basic CDS view on it, extend the standard view with a new associationManually — you create a Service Definition and Service Binding in ADTFull developer control; enrichment from external data sources or data with no counterpart in SAP’s modelHow to choose in practice:Open the Custom Fields app (F1481). If the view appears in the data source list as Released, use the key user path.Open the view in ADT. If you see a pre-defined _Extension association pointing to an E_* include view, SAP has pre-wired an extension point. Add an append to the include structure and extend the view to expose the field, and no Z-table is needed.If neither applies, the view is not in the Custom Fields app (F1481) and has no pre-wired extension include, use the Z-table approach below.What the worked example uses: the Z-table + Extend View path. This is the most general approach and the one most commonly needed for custom enrichment scenarios. It requires the most manual steps but gives you complete control over the data model.Worked ExampleA manufacturing company needs to add a sustainability certification reference (ZZ_SUSTAIN_CERT_REF) to purchase order items so it is available for Datasphere replication, custom analytical queries and downstream applications built on the extended CDS view.Step 1, Create the custom extension table. Create a transparent Z-table (ZPOITEM_SUST) with MANDT, EBELN (PurchaseOrder), and EBELP (PurchaseOrderItem) as key fields, plus ZZ_SUSTAIN_CERT_REF as the payload field. Create a basic CDS view (ZI_POItemSustain) on top of it. This table is the data store for the extension; the CDS view makes it joinable from the standard view layer.Step 2, Extend the interface view:@AbapCatalog.sqlViewAppendName: ‘ZEXPOITEMSUST’@EndUserText.label: ‘Extend PO Item — Sustainability Cert’extend view I_PurchaseOrderItemAPI01  with ZEX_I_PurchaseOrderItemAPI01  association [0..1] to ZI_POItemSustain as _ZPOItemSustain    on  $projection.PurchaseOrder     = _ZPOItemSustain.PurchaseOrder    and $projection.PurchaseOrderItem = _ZPOItemSustain.PurchaseOrderItem{  — Expose the field from the extension table  _ZPOItemSustain.ZZ_SustainCertRef,  — Expose the association so path expressions work downstream  _ZPOItemSustain}Syntax note: I_PurchaseOrderItemAPI01 uses the classic define view syntax, so its extension uses extend view Base with ExtensionName { } with a mandatory @AbapCatalog.sqlViewAppendName annotation. Select the Extend View template in ADT. Use $projection.FieldName in association ON conditions to qualify base view fields and avoid ambiguity errors.Step 3a, Verify at the CDS layer:With ZEX_I_PurchaseOrderItemAPI01 activated, ZZ_SustainCertRef is now part of the extended I_PurchaseOrderItemAPI01 view. Verify by opening the view in ADT and pressing F8 (Data Preview). The column should appear alongside standard PO item fields. Add a row to ZPOITEM_SUST for a real PO item first so you have a non-null value to confirm.Step 3b, Expose via a custom OData service:The standard SAP purchase order API (API_PURCHASEORDER_PROCESS_SRV) has an explicit contract and does not inherit CDS view extensions. To expose ZZ_SustainCertRef via OData, you need a custom service definition and binding.Create and Activate the Service DefinitionName: ZSD_POITEMSUSTAIN@EndUserText.label: ‘PO Item Sustainability Extension’define service ZSD_POITEMSUSTAIN {  expose I_PurchaseOrderItemAPI01 as PurchaseOrderItem;}Create, Activate and Publish the Service BindingName: ZSB_POITEMSUSTAINBinding Type: OData V4 – Web APIService Definition: ZSD_POITEMSUSTAINThe editor shows the service URL once published.Append /$metadata to the service URL and search for ZZ_SustainCertRef. It will appear as a property on the PurchaseOrderItem entity type. Query the entity set for a PO item that has a row in ZPOITEM_SUST to confirm the value is returned.Joule: The custom OData service published here is the data source for a Joule skill. Register ZSB_POITEMSUSTAIN as a BTP destination, point a Joule skill at that endpoint, and Joule can surface ZZ_SustainCertRef in natural language responses alongside standard PO item data. The CDS extension is the foundation, one field added at the interface layer, surfaced through every consumer that reads from the service.What this extension does not do automatically: expose the field in SAP’s standard A2X API (API_PURCHASEORDER_PROCESS_SRV) or in the standard Fiori UI. For Fiori UI visibility, the same extend view pattern applies to the item-level consumption view that backs your target app.  Identify it in View Browser (F2170) and add an equivalent extension with @UI annotations. For standard API exposure, the supported path is the Custom Fields app (F1481), which handles the service registration as part of the key user extensibility flow.Performance ConsiderationsA few principles worth stating upfront, before they become debugging sessions later.Use associations, not joins, for optional enrichment data. An association resolves only when a consumer navigates it. A join executes unconditionally on every query. For custom enrichment tables — classification data, custom attributes, legacy reference data — associations are almost always the right choice. A poorly placed join on I_JournalEntryItem (backed by ACDOCA with hundreds of millions of rows in production) can have a significant impact on query response time.Declare cardinality accurately. [0..1] vs [1..1] on an association is not cosmetic. Incorrect cardinality can cause the query optimiser to generate multiply-joining plans, producing duplicate rows or forcing outer joins where inner joins would suffice.Avoid calculated fields in ON and WHERE clauses. Computed expressions in join conditions prevent HANA from pushing predicates to the storage layer. The result is a scan instead of a seek.Validate with ST05 and ADT Dependency Analyser after activation. What runs in 200ms on a sandbox with 50,000 rows may behave differently on a production system with 800 million. Test with realistic data volumes before promoting to quality.Pre-Flight Checklist Before You ExtendBefore writing a line of code on any SAP S/4HANA Cloud Private Edition extension:☐ Base view has C1, C0, or #PUBLIC_LOCAL_API contract, verified in ADT API State tab☐ View registered in SCFD_REGISTRY, or @Metadata.allowExtensions: true present on the base view☐ Enhancement category is not #NONE☐ No GROUP BY or UNION in the base view☐ Gap type confirmed: standard SAP field (Alt Search in View Browser first) or custom data☐ Bottom-up propagation plan mapped out, every layer from DB to consumption☐ Extension object created in ABAP Cloud software component (compiler enforces release contract compliance)☐ Associations used for optional data, no unconditional joins on high-volume views☐ Cardinality declared accurately on all associations☐ Naming convention followed: ZEX_I_*, ZEX_C_*, ZEX_Q_*☐ Transport dependency order documented, extension activates after base viewGovernance Checklist Per ExtensionFor architect sign-off on any extension going to quality:☐ Release contract confirmed (ADT + SCFD_REGISTRY)☐ ABAP Cloud software component used, compiler passes without released-object violations☐ All VDM layers propagated bottom-up, confirmed end-to-end in the Fiori app and OData service☐ Performance reviewed, ST05 trace run on production-scale data☐ Simplification List checked, base objects not deprecated in target release☐ Downstream consumers inventoried: Fiori apps, SAC, Datasphere, OData clients, Joule skills if applicable☐ If OData exposure needed: service definition and binding created, BTP destination configured☐ Transport landscape validated, correct promotion order in dev → QA → prodPart 2 picks up here: six situations you are likely to encounter on SAP S/4HANA Cloud Private Edition projects, with the exact technical detail of what goes wrong and why, and the full architecture chain from CDS extension to working Joule skill, end to end.Official SAP ReferencesCDS View Extension, Language & SyntaxABAP CDS, CDS Entity Extension (EXTEND VIEW ENTITY), ABAP Keyword DocumentationExtending CDS Views (ABAP RAP). SAP Help PortalCDS-Enabling Architecture (extensibility annotations). SAP Help PortalClean Core & Developer ExtensibilityClean Core Extensibility Principles. SAP Developer CenterDeveloper Extensibility in SAP S/4HANA Cloud. SAP Help PortalABAP Extensibility Guide, Clean Core for SAP S/4HANA Cloud. SAP Community (August 2025)Clean Core Extensibility in SAP S/4HANA Cloud SAP S/4HANA Cloud Private Edition, SAP.comKey User ToolsCustom CDS Views App, Key Features. SAP Help PortalCustom CDS Views, FAQ. SAP CommunitySAP S/4HANA Cloud Private Edition Release & UpgradeNavigating Release Upgrades in SAP S/4HANA Cloud Private Edition. SAP LearningFinding Released APIsSAP Business Accelerator Hub, Central catalogue of released APIs and CDS viewsBrought to you by the SAP S/4HANA RIG team.*** This post was written with AI assistance***   Read More Technology Blog Posts by SAP articles 

#SAPCHANNEL