SAP RAP / CDS / OData Interview Questions

First, I would explain that RAP stands for ABAP RESTful Application Programming Model and is SAP’s modern framework for building transactional OData services and Fiori applications. It combines CDS views for the data model with behavior definitions, behavior implementations, service definitions and service bindings to expose business logic in a structured way. The reason it matters is that it standardises how you build, expose and maintain applications on the ABAP platform. A strong candidate adds that RAP supports clean separation between data, business rules and service exposure, making solutions easier to extend, test and align with modern SAP application development.

A strong first step is to explain that a CDS View is a semantic data model defined in ABAP CDS, not just a simple SQL select. It is used to model database data with fields, joins, associations, annotations and built-in authorization support. The reason this matters is that CDS lets you describe the business meaning of the data close to the database layer, which improves reuse, consistency and performance. A strong candidate also adds that CDS views are widely used in S/4HANA for reporting, Fiori apps, OData services, analytics and RAP applications, making them a core part of modern ABAP development.

Models: OData V4 model for backend data, JSONModel for UI state/local data, ResourceModel for i18n; named models separate concerns ({view>/busy}). Binding types: property ({Description}), element/context (bindElement) and list/aggregation (items="{/PurchaseRequest}"); relative paths resolve against contexts. Modes: one-way, two-way (V4 inputs default), one-time. Formatters and expression binding handle display logic declaratively.

Confirm both are hitting the same physical tables and clients; compare the WHERE clauses generated by SQL trace (ST05). Common causes: unit-conversion in the CDS view (currency / quantity conversions add sign flips), authorization-managed CDS (DCLs filter rows the ABAP report reads directly), or NULL vs 0 semantics for outer joins. Add a WHERE that isolates one document and reconcile row-by-row.

I would verify that the RAP OData V4 service returns data and then inspect the UI annotations, especially lineItem and selectionField metadata, plus the projection and metadata extension. If the service is healthy, missing columns are usually a metadata/presentation issue rather than a reason to build custom controllers.

The metadata is the public service contract. It tells the client the entity-set names, keys, property names and types, navigation properties, actions/functions and annotations. Guessing names from the CDS source can produce invalid requests because the public projection/service can expose a different contract.

Business validations belong in the RAP business object behavior layer, not duplicated in frontend JavaScript. Fiori Elements consumes the service metadata and messages and should present the result. UI-only checks can improve usability, but the authoritative business rule must remain on the backend.

I would start with the service metadata and reproduce the exact POST outside the UI. Then I would compare the HTTP status and RAP messages. If an equivalent EML create succeeds, the business object is likely healthy and I would focus on the OData path, payload shape, authentication, entity-set name, draft state and concurrency headers. If EML also fails, I would investigate the RAP behavior, validation, authorization or data state.

First, check that the change is being made through the RAP behavior layer rather than by updating tables directly. Direct database updates bypass the managed lifecycle, so validations, determinations, locking, authorization checks and transactional consistency are not executed. That means the data may be saved in a technically successful way but still violate business rules or leave the object in an inconsistent state. A strong candidate adds that RAP business objects should be accessed via EML or the framework behavior so the complete business logic is triggered, the update is properly controlled, and the object remains safe for concurrent use and future extensions.

For new S/4HANA development, RAP/CDS OData is usually preferred when the requirement fits managed or unmanaged RAP patterns, needs modern Fiori integration, draft, behavior definitions or clean-core aligned development. SEGW remains useful for legacy services, ECC, custom wrappers and support of existing Gateway services.