CDS Layering: Basic, Composite and Consumption Views

Explanation

A clean CDS architecture usually has layers. Basic or interface views expose database tables in a reusable and controlled way. Composite views join and combine multiple basic views into business models. Consumption views are designed for a specific UI, analytics query, API or report. This layered approach prevents one giant CDS from becoming unmanageable. It also supports reuse, testing and authorization design. In S/4HANA projects, this pattern is important for Fiori elements, embedded analytics and RAP-based applications.

Code example

// Basic view: close to table and reusable.@EndUserText.label: 'Billing Item Basic'define view entity ZI_BillingItem as select from vbrp{ key vbeln as BillingDocument, key posnr as BillingItem, matnr as Material, netwr as NetValue} // Composite view: business combination or aggregation.@EndUserText.label: 'Billing Revenue Composite'define view entity ZI_BillingRevenue as select from ZI_BillingItem{ BillingDocument, sum( NetValue ) as TotalNetValue}group by BillingDocument // Consumption view:// Add UI/analytics annotations here instead of overloading basic view.

Real project scenario

A CFO KPI tile was built using basic CDS views for billing header and item, a composite CDS for customer-level revenue, and a consumption CDS with analytical annotations for the Fiori KPI app.

Common mistakes

- Creating one huge CDS view with everything. - Putting UI annotations in low-level reusable views. - Not separating database model from consumption requirement. - Making basic views report-specific.

Best practices

- Use ZI or interface views for reusable base models. - Use composite views for business combination. - Use ZC consumption views for UI/API/report-specific output. - Keep annotations at the right layer.

Interview angle

A senior answer should explain layered CDS design and why it improves reuse and maintainability.