CDS Projection

What a CDS Projection Does

A CDS projection is a filtered, purpose-built view over underlying CDS data. It exposes only the fields and relationships needed by a consumer, while hiding the internal persistence model that sits behind the service surface.

That separation matters because CDS projections are not just a technical convenience, they are a governance boundary. They let teams publish a stable external contract without exposing every internal table, association, or annotation that may exist in the source model.

Why CDS Projection Is Used in RAP

In RAP, projection views are commonly used to define the consumable shape of a business object for OData, UI consumption, or other service-facing use cases. The projected layer can rename elements, suppress technical fields, and limit operations so the published interface matches the business purpose rather than the full backend model.

This is especially useful when the internal CDS model contains implementation details that should not leak into consumer-facing APIs. A projection helps teams separate persistence concerns from service design, which reduces coupling and makes later change easier.

Security and Governance Implications

Because a CDS projection controls what is exposed, it directly supports least-privilege design at the data layer. A well-designed projection can reduce overexposure, limit accidental disclosure, and keep consumers from relying on fields that were never meant to be part of the public contract.

That also means the projection becomes part of the security boundary. If sensitive fields, derived data, or administrative associations are projected too broadly, the service may reveal more than intended even when the underlying tables remain protected. For the surrounding access model, NIST Cybersecurity Framework 2.0 is a useful control lens for governing exposed interfaces, and NIST Privacy Framework helps when the projection materially affects personal-data minimisation and downstream disclosure.

When projection design is weak, consumers can also infer internal structure from what is omitted, renamed, or inconsistently filtered. That is why projection design should be treated as part of data governance, not only as a modeling exercise.

CDS Projection Versus the Underlying CDS View

The underlying CDS view usually represents the richer internal model, while the projection represents the published surface. The two should not be treated as interchangeable: the source model can stay expressive for persistence and domain logic, while the projection remains narrow and intentionally consumable.

This distinction is what makes CDS projection useful in layered architecture. It gives developers a way to evolve internal design without forcing every consumer to absorb backend complexity, and it prevents service contracts from becoming accidental mirrors of implementation detail.

Risk and Threat Considerations

CDS projection reduces exposure only when it is maintained with the same discipline as the backend model. If the projection is too broad, it can create unintended data exposure, overbroad API surface area, or business-logic leakage through fields that reveal internal state.

Failure mechanism: Sensitive or unnecessary fields are included in the projection, or consumers gain access to associations and semantics that were supposed to remain internal. That can happen through design drift, rushed reuse of backend entities, or weak review of service exposure.

Impact: The service can disclose data beyond the intended audience, weaken least-privilege boundaries, and make later remediation harder because downstream consumers start depending on the oversized surface.

Practitioner Guidance

What to watch for: Treat the projection as the published contract and review it whenever the underlying CDS model changes. If a field, association, or action is not needed by the consumer, leave it out rather than exposing it by default.

Governance implication: Keep ownership of projection design explicit, because the person maintaining the backend model is not always the right person to approve the external surface. The safest pattern is to review CDS projections as part of service design, not after deployment.

Practitioner takeaway: A good CDS projection is narrow enough to protect the internal model, but complete enough to serve the business need without forcing consumers to depend on implementation detail.

Related resources from NHI Mgmt Group

• Derived Projection
• Code Projection
• Projection-Surface Drift
• Projection Sensor