Building OData V4 Services with RAP: Step by Step

Exposing a RAP business object as an OData V4 service involves four artifacts, always in the same order. Skipping the order — or the reasoning behind it — is where most first-time confusion comes from.

1. Interface CDS View — The Data Model

The interface view is the "raw" data model, close to the database table, without UI or exposure concerns.

define root view entity ZI_Travel
  as select from ztravel
{
  key travel_id as TravelId,
  description  as Description,
  begin_date   as BeginDate,
  end_date     as EndDate,
  total_price  as TotalPrice
}

This view is not exposed directly to any client. Think of it as internal plumbing.

2. Behavior Definition — The Business Logic

Attached to the interface view, this defines what operations exist (create, update, delete, actions) and where their implementation lives.

managed implementation in class zbp_i_travel unique;
strict(2);

define behavior for ZI_Travel alias Travel
persistent table ztravel
lock master
authorization master(instance)
{
  create;
  update;
  delete;

  mapping for ztravel corresponding;
}

3. Projection CDS View — What Gets Exposed

The projection view sits on top of the interface view and is where @UI and @Consumption annotations for Fiori Elements typically live. This is the layer you're allowed to redesign per-consumer without touching the underlying data model.

@EndUserText.label: 'Travel Projection'
define view entity ZC_Travel
  as projection on ZI_Travel
{
  key TravelId,

  @UI.lineItem: [{ position: 10 }]
  Description,

  @UI.lineItem: [{ position: 20 }]
  @UI.selectionField: [{ position: 10 }]
  BeginDate,

  EndDate,
  TotalPrice
}

4. Projection Behavior Definition

A thinner behavior definition referencing the interface one, exposing only the operations this particular consumer should see:

projection;

define behavior for ZC_Travel alias Travel
{
  use create;
  use update;
  use delete;
}

5. Service Definition and Service Binding

The service definition lists which projection entities form the OData service:

define service ZUI_TRAVEL {
  expose ZC_Travel as Travel;
}

The service binding then activates it as an actual OData V4 (or V2) service and gives you the SAP Fiori preview / service URL. This is the step most people forget is separate from the service definition — the definition just describes the contract, the binding is what makes it reachable over HTTP.

Why the Interface/Projection Split Matters

It's tempting to skip the projection layer and expose the interface view directly. Don't — the split exists so the same underlying business object can be exposed differently to different consumers (an internal back-office app vs. a public API vs. a mobile app) without duplicating the behavior logic. Changes to the actual persistence and business rules stay in one place (the interface behavior definition); each projection only decides what to show and how.

Use the CDS View Generator to scaffold the interface and projection view DDL, and our RAP Quick Reference for the exact syntax of determinations, validations, and actions once your service is bound and running.