CDS · Data Modelling

SAP CDS Views Interview Questions

Q: What is the difference between a CDS association and a join?

A join combines data eagerly in the statement; an association declares a relationship that is only resolved when a consumer navigates it. Associations keep the base model lean, express cardinality, and are what path expressions and service exposure build on — which is why interviewers treat 'it is just a join' as a red flag.

Q: What is a CDS view entity?

The current generation of CDS view: defined entirely in the DDL source, without a generated DDIC view underneath, and with stricter, cleaner semantics. It is the artefact new modelling should use, and knowing what the classic DDIC-based view could not express — typed associations being the everyday example — is the expected follow-up.

Q: Where does authorisation happen for CDS views?

In the model itself, through access control artefacts attached to the view, so every consumer — service, analytical query, or direct read — gets the same filtering. The contrast interviewers want is with authority checks scattered across every calling program.

Q: What are CDS parameters used for?

For inputs the model needs at selection time: a key date, a target currency, a language. Because they are part of the view's contract they push down to the database, unlike a filter applied after the fact in ABAP — that pushdown is the point of the question.

Q: How do CDS views relate to embedded analytics?

Analytical annotations turn a view into a cube or query that the analytical engine can consume directly, which is how embedded reporting on S/4HANA is built. Interviewers check whether you know the modelling conventions that make a view analytically consumable rather than just selectable.

CDS has quietly become the dividing line in ABAP interviews. Candidates who modelled data before HANA think in joins and nested selects; interviewers now listen for associations, annotations and pushdown — whether you think in the layer where the database does the work.

The questions on this page are drawn from ERPClimb's reviewed bank and cover the full arc: what a CDS view entity actually is and how it differs from the classic DDIC-based view, associations versus joins, parameters and where they push down, access control through roles, and the analytical annotations that drive embedded reporting.

The strongest answers here are architectural, not syntactic. Saying where logic belongs — and what it costs when it lands in the wrong layer — is what separates a senior answer from a tutorial answer.

What interviewers actually probe

Associations versus joins

A guaranteed question. The expected answer covers lazy evaluation and exposure to consumers, not just syntax — associations declare a relationship the consumer chooses to navigate.

What the annotations do

Interviewers probe whether you know that annotations carry semantics — UI, analytical, access — rather than decoration, and which annotation families drive Fiori Elements and embedded analytics.

View entities versus classic views

The modern-versus-legacy line: why the view entity is the go-forward artefact, what the DDIC-based view could not express, and what a migration between them involves.

Access control

Where authorisation lives in a CDS world — the expected answer names the access control artefact and explains why filtering at the model beats filtering in every consumer.

23 questions with full answers

Ordered from foundational to advanced. No sign-in required.

easyCDS Views

1. What is an association in CDS?

An association in CDS is a declarative navigation from one view or entity to another, defined with a statement such as association [card] to X on <condition>. The first thing to check is the relationship and the ON condition, because that defines how the target can be reached. It is useful because the join is lazy: it is only generated when a path expression actually consumes the association, which helps keep the model clean and avoids unnecessary joins. A strong candidate also mentions that associations improve semantic modelling and make reuse easier, since consumers can navigate to related data without hard-coding the join logic in every view.

easyCDS Views

2. Five ABAP reports on your project each join VBAK, VBAP and KNA1 themselves, and their totals do not match. How would you use CDS to fix this?

The root cause is duplicated logic: each report re-implements the same joins and rules slightly differently. I would define the shared logic once as CDS view entities in ADT — for example a sales order header/item view with business names, currency references and agreed rules — and let all reports read from it with a normal SELECT. The logic then runs in the database (code pushdown), and any rule change is made in one place. I would first check whether SAP's standard I_ views (I_SalesOrder, I_Customer) already cover the need. Before switching, I compare row counts and totals of old and new reports to prove they now match.

easyCDS Views

3. How do you add calculated fields to a CDS view, and what do you watch out for with CASE, CAST and date calculations?

Calculated fields are expressions in the field list and run in the database. CASE (simple or searched) derives values like a status text, CAST fixes the type — e.g. cast( 'OPEN' as abap.char(10) ) so all CASE branches return one type — and built-in functions handle strings (concat, substring) and dates (dats_days_between, dats_add_days). For runtime context I use session variables such as $session.system_date instead of parameters. Watch-outs: CASE branches with literals of different lengths need CAST, integer division truncates unless cast to decimal, and consumers should not filter on calculated fields in large views because the filter cannot use base-table indexes.

mediumCDS Views

4. Data appears wrong in a consumption CDS view. Approach?

First check each layer independently in ADT, starting with the underlying basic or interface view before the consumption view, so you can isolate where the wrong data is introduced. Then review joins and associations for cardinality or filter issues, and verify aggregation types plus unit and currency handling, because these often change the displayed result even when the source data is correct. After that, inspect the generated SQL in ST05 to confirm what actually runs at database level and whether the CDS definition matches the runtime result. A strong candidate also compares the preview result with the business expectation and checks whether the issue is caused by a missing join condition, incorrect grouping, or inconsistent master data.

mediumCDS Views

5. How do you expose a CDS view as OData?

First check the system release, because the exposure method depends on whether you are on S/4HANA with RAP available or on an older stack. On S/4HANA, annotate the CDS view with the relevant @ObjectModel.query: true and @UI annotations, then create a service definition and service binding in RAP to publish it as an OData service for Fiori. This is the preferred approach because it keeps the model, service, and UI metadata aligned and reduces manual coding. On older systems, use ODATA_V2_UI to reference the CDS view and expose it through classic OData V2 handling. A strong candidate also mentions checking the service activation and testing the endpoint before handing it to the UI team.

easyCDS Views

6. What is the difference between CDS view entity and classic CDS view?

First check the definition type. A classic CDS view is created with define view and typically needs a generated SQL view name, because the runtime object is based on that separate SQL view. A CDS view entity is created with define view entity and does not require a separate SQL view name, so the model is more direct and streamlined. For that reason, on supported releases, view entities are generally preferred for new development. A strong candidate would add that the choice affects how the object is managed and evolved, and that entities are the modern CDS option when starting fresh, while classic views may still be encountered in existing solutions.

hardCDS Views

7. How do you secure data exposed by CDS Views?

First I would check whether the CDS view exposes data that needs row-level protection and whether an authorization check is already enabled on the view. If access must be restricted, I would create the relevant DCL roles so the view returns only the records a user is allowed to see. I would also review the selected fields and avoid exposing sensitive data unless it is really required. A strong candidate also validates the result with users who have different authorisations, so both the data scope and the field-level exposure are tested from an end-to-end security perspective.

mediumCDS Views

8. A CDS-based Fiori app shows duplicate rows. What would you check?

First I would check the CDS joins and associations to see whether any one-to-many relationship is being consumed as if it were one-to-one. Duplicate rows often come from a join that multiplies the result set, so I would review the cardinality, the key fields in the view, and whether the grouping logic is actually preventing repeated records. I would then compare the underlying data to confirm whether the duplicates are already present there or are introduced by the CDS layer. A strong candidate also checks the consumption view carefully, because exposing associations or joins incorrectly can cause record multiplication in the Fiori app even when the base data is clean.

mediumCDS Views

9. What is DCL?

First check whether the question is about CDS access control, because in SAP DCL usually means Data Control Language. It is the CDS artefact used to apply row-level authorisation to a view by linking the result set to authorisation objects. In practice, DCL is evaluated as filter conditions when the CDS view is queried, so users only see the records they are allowed to access. A strong candidate adds that this is part of securing CDS consumption cleanly at the data model level, rather than handling the restriction later in the application.

mediumCDS Views

10. A backlog report reads VBAP and VBAK in nested SELECTs and calculates order age and rejection status in ABAP loops. It runs 25 minutes. How would you redesign it with CDS?

I would move the join and the calculations into one CDS view entity: VBAP inner join VBAK on VBELN, a searched CASE on ABGRU returning a cast status ('OPEN'/'REJECTED'), and dats_days_between( erdat, $session.system_date ) for the age. The report then becomes one SELECT with a WHERE on the status, reading only the needed fields. The database processes the set in one statement instead of millions of single reads, which typically reduces runtime from minutes to seconds. I keep fixed rules (order type TA) in the view and variable filters in the report, and compare results with the old report before go-live.

mediumCDS Views

11. A Fiori list report generated from CDS annotations shows amounts without currency and order types only as codes with technical labels. What would you change in the CDS model?

Amounts need @Semantics.amount.currencyCode pointing to the currency field so the UI shows and formats them correctly. For order types I add a text view over TVAKT (@ObjectModel.dataCategory: #TEXT, keys code and language), a text association from the consumption view, a language-filtered path via $session.system_language and @ObjectModel.text.element on the code field. Labels come from @EndUserText.label or data elements. UI layout (lineItem, selectionField) I put into a metadata extension with @Metadata.allowExtensions: true, so column changes do not touch the data model.

mediumCDS Views

12. How would you design CDS views for a Fiori list report?

I would design layered CDS views. A basic/interface view exposes reusable table-level fields, a composite view combines and prepares business data, and a consumption view adds UI annotations, selection fields, semantic annotations and authorization checks. I would avoid putting all logic and annotations into one giant CDS view.

mediumCDS Views

13. A sales-order header view has association [1..1] to its items and shows item material in the field list. The totals are doubled. Explain and fix.

Two problems. The cardinality is wrong — an order can have many items, so it should be [0..*] (or [1..*]). And the path expression to a to-many association in the field list creates one row per item; summing header NetAmount over those rows counts each header several times. Fix: correct the cardinality, remove the item path from the header view, expose _Item as an association for navigation, and build a separate item-level view for material analysis. Then compare row counts and totals with SD reports.

mediumCDS Views

14. A condition validity report must always evaluate data as of one key date, and the age of each record depends on that date. How would you model this in CDS?

Here the value changes the calculation, so a CDS parameter is justified: define view entity … with parameters p_keydate : abap.dats. Inside, $parameters.p_keydate is used in WHERE (valid-from <= key date <= valid-to) and in calculations like dats_days_between( … , $parameters.p_keydate ). A language parameter can be defaulted with @Environment.systemField: #SYSTEM_LANGUAGE. The ABAP report passes the date with strict SQL: FROM zview( p_keydate = @p_date ). Plain filters like sales org stay normal fields filtered by the consumer's WHERE.

mediumCDS Views

15. A CDS-based sales dashboard shows a customer total of 40 million, but the customer orders in EUR and JPY. What went wrong and how do you fix it?

The view summed NETWR across currencies — euros and yen were added into one meaningless number. In CDS every aggregated amount must be grouped by its currency field: GROUP BY kunnr, waerk, with @Semantics.amount.currencyCode on the sum. If management needs one total, I convert to a group currency with currency_conversion and then aggregate — ideally aggregating per currency first and converting the reduced set for performance, after agreeing the exchange-rate date with the business. Finally I reconcile the totals with an FI or SD report.

mediumCDS Views

16. Users want to drill a sales KPI by sales org, customer and month in any combination. Would you build a GROUP BY CDS view or an analytical cube? Explain.

A GROUP BY view returns fixed totals for one fixed combination of fields — good for a report with a known layout. For flexible drill-down I would build an analytical model: a view with @Analytics.dataCategory: #CUBE holding the detail rows and measures with @Aggregation.default: #SUM, dimensions for customer and sales org, and an analytical query on top. The analytical engine then aggregates at runtime for whatever dimensions the user chooses, in Analysis for Office, SAC or Fiori. I would check SAP's standard cubes first and test in RSRT.

mediumCDS Views

17. Your system has 400 classic DDIC-based CDS views and some reports read their SE11 SQL view names. What risks do you see and what is your plan?

Reading the SQL view name bypasses CDS features such as DCL access control, so users may see data they are not authorized for; it also ties code to an object SAP treats as obsolete. Classic views need two names and slower activation. Plan: first change all consumers to the CDS names; enforce "define view entity only" for new development in code review; then migrate the heavily used classic views step by step with SAP's migration tooling for the release, testing each consumer with row-count and total comparisons. Remaining classic views are documented with a reason.

hardCDS Views

18. A CDS view is slow in production. How would you analyze and improve it?

I would first identify the consumer and selection criteria, then analyze generated SQL, execution plan, data volume, joins, associations, filters and aggregation. I would reduce unnecessary fields and associations, add selective filters, correct cardinality, push aggregation to DB where suitable and split a monster view into layered reusable views if required.

hardCDS Views

19. Legacy report on SE11 views performs badly. Migrate to CDS?

Yes, but start by checking the existing SE11 views, the report logic, and where the bottleneck is before changing anything. If the report is doing row-by-row ABAP processing, move the data model to interface CDS views and use composite CDS views for the calculations and joins. This lets you push filtering and aggregation down to the database instead of handling large volumes in ABAP loops, which is usually the main performance gain. A strong candidate also validates the new result set against the old report, retests performance with realistic data, and only retires the SE11 views once no dependent programs or interfaces remain.

hardCDS Views

20. How would you structure a CDS model for a domain?

I would start by identifying the domain entities and then structure the CDS model in three clear layers. The interface layer exposes the raw tables and basic joins, so it stays close to the source and provides a stable foundation. On top of that, the composite layer adds the business logic, richer joins and associations needed to represent the domain consistently. Finally, the consumption layer is designed for the actual use case, such as UI or analytics, with the relevant annotations applied there. A strong point is to apply DCL at the interface level, so access control is enforced centrally and inherited by all consuming views. This keeps the model reusable, easier to govern, and simpler to extend without duplicating checks in every consumer.

hardCDS Views

21. After go-live, a Brazil user sees German sales orders in a custom Fiori app. The CDS view has @AccessControl.authorizationCheck: #CHECK. What happened and how do you fix it?

The annotation alone does not protect data — it only says a DCL role is expected. Most likely no DCL role exists for this view, or the consumption view has no role (consumption views do not inherit protection automatically), or the app reads a base table / SQL view name that bypasses DCL. Fix: create a DCL role mapping sales area fields to V_VBAK_VKO via aspect pfcg_auth with ACTVT '03', add inheriting-condition roles for every view in the stack, make sure consumers read CDS names, and test with restricted users. Add a review rule: #CHECK without a role fails.

hardCDS Views

22. A team built all sales CDS views with parameters for sales org, customer and date range "for performance". Fiori apps now show a parameter dialog and other reports cannot reuse the views. Evaluate the design.

The design uses parameters for plain row filters, which gives no performance benefit — HANA pushes consumer WHERE conditions down to the base tables anyway. It does cost reuse: every consumer must pass all parameters, views on top must propagate them, and OData/Fiori elements expose them as mandatory inputs. I would convert these to normal fields filtered by the consumer (WHERE, Fiori filter bar) and keep parameters only where the value drives a calculation, like a key date for ageing or a target currency. Then I would compare runtimes to show performance stayed the same.

hardCDS Views

23. A Fiori consumption view exposes many associations and path fields and takes 90 seconds to load. How do you analyse and speed it up?

I reproduce with the real consumer query and trace it with ST05, check the view stack in the ADT Dependency Analyzer and the generated SQL, and use HANA PlanViz to see where rows explode or filters apply late. Typical findings: path fields to to-many associations multiplying rows, joins/paths the list never displays, currency conversion on all rows before filtering, filters on calculated fields. Fixes: keep only needed fields in the list view, expose associations for navigation instead of flattening them, keep filter fields as plain columns, aggregate before conversion. After each change I re-measure and compare row counts and totals.

Practise by experience level

Fresher1-3 years4-7 years8-12 yearsArchitect

The questions above are tagged by the experience levels they are normally asked at, so the same page works for a first interview and for a lead-developer round.