SAP ABAP RAP: Projection Views vs. Standard Views - A Deep Dive with Code

The SAP ABAP RESTful Application Programming Model (RAP) has revolutionized backend development, offering a modern, efficient, and standardized way to build Fiori applications. A key concept within RAP is the use of CDS views, but specifically, the distinction between standard CDS views and projection views often raises questions. Why do we predominantly use projection views in RAP and expose them, rather than directly using our standard data models?

Understanding the Foundation: Standard CDS Views

Standard CDS (Core Data Services) views form the backbone of our data models. They are designed to encapsulate business logic, perform joins, aggregations, and provide a rich semantic layer over database tables. These views represent the "source of truth" for our business objects.

Consider a simple scenario where we manage flight bookings. Our standard CDS view might look like this:

@AbapCatalog.sqlViewName: '''z_i_flightbooking'''
@AbapCatalog.compiler.compareFilter: true
@AbapCatalog.preserveKey: true
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: '''Flight Booking'''
define view Z_I_FlightBooking as select from zflight_booking
{
  key booking_uuid as BookingUUID,
  booking_id as BookingID,
  flight_id as FlightID,
  customer_id as CustomerID,
  booking_date as BookingDate,
  travel_status as TravelStatus,
  amount as Amount,
  currency_code as CurrencyCode
}

This view exposes all the essential fields for a flight booking. It''s perfectly valid for data retrieval and reporting.

The RAP Context: Why Projection Views?

While standard CDS views define our business objects, RAP requires an additional layer for consumption – the projection view. The primary reasons for this approach are:

1. Consumption Layer Control: Projection views act as a dedicated consumption layer. They allow us to tailor the exposed interface of a business object for a specific application or use case without altering the underlying core business object. We can select a subset of fields, rename them, add virtual elements, or define specific associations relevant only for the UI.
2. Adaptability and Flexibility: Business requirements evolve. If a UI needs to display only certain fields, or if we need to deprecate a field from the UI without removing it from the core data model, a projection view provides this flexibility. Changes to the projection view have minimal impact on the underlying business object and other consumers.
3. Security and Authorization: Projection views are critical for implementing field-level security and read/write authorizations. We can restrict access to specific fields or even entire entities based on the logged-in user''s role, without embedding this logic directly into the core business object.
4. Enhancements (Unmanaged, Managed, Draft): In RAP, business objects often involve draft capabilities, unmanaged saves, or managed saves. Projection views are where these behaviors are defined and exposed through annotations (e.g., `@ObjectModel.semanticKey`, `@ObjectModel.readOnly`). They are the gateway to the RAP framework''s features.
5. Service Definition and Exposure: When you create a Service Definition in RAP, you define which entities (from your projection views) will be exposed as part of your OData service. This clean separation ensures that your core business logic remains independent of its consumption interface.

Real Case Scenario: Flight Booking Management

Let''s extend our flight booking example. For a flight booking management application, a user might only need to see the `BookingID`, `CustomerID`, `BookingDate`, and `TravelStatus`. The `Amount` and `CurrencyCode` might be sensitive and only visible to an administrator. Furthermore, we might want to expose an association to the `Customer` details.

Here''s how a projection view for the flight booking would look, built on top of our `Z_I_FlightBooking` standard view:

@EndUserText.label: '''Flight Booking Projection'''
@ObjectModel.resultSet.sizeCategory: #XL
@ObjectModel.semanticKey: ['''BookingID''']
define root view entity Z_C_FlightBooking
  as projection on Z_I_FlightBooking
{
  key BookingUUID as BookingUUID,
      BookingID   as BookingID,
      CustomerID  as CustomerID,
      BookingDate as BookingDate,
      TravelStatus as TravelStatus,
      // Amount and CurrencyCode might be excluded or restricted via authorizations
      // Amount,
      // CurrencyCode,
      _Customer : redirected to parent Z_C_Customer // Assuming Z_C_Customer is the projection view for Customer
}

In this `Z_C_FlightBooking` projection view:

• We selected only the fields relevant for the general user.
• We added `@ObjectModel.semanticKey: ['''BookingID''']` to define the business key for the UI.
• We introduced a redirected association `_Customer` to link to the customer projection view, making it consumable via OData.
• If `Amount` and `CurrencyCode` were needed for an admin role, a separate projection view or authorization control on this one would handle it.

Conclusion

In essence, while standard CDS views model the core business data and logic, projection views serve as the public face of your business object in the RAP world. They provide the necessary flexibility, control, and separation of concerns required for building robust, secure, and adaptable Fiori applications. By exposing projection views, we are defining the specific API that our frontend applications will consume, ensuring a clean and manageable interface to our powerful backend services.