When building SAP RAP (RESTful ABAP Programming Model) applications, one of the most important layers in your data model architecture is the Projection Views in SAP RAP. This layer allows you to fine‑tune how your business objects behave for different user roles, services, and UI needs.
In this blog, we’ll break down:
- What projection views are
- Why they are required
- How annotations behave in interface and projection views
- Key rules, restrictions & best practices
- A step‑by‑step walkthrough based on the actual development of our RAP Travel App
Let’s dive in.
What Are Projection Views in SAP RAP?
Projection Views sit on top of Interface Views in the RAP architecture.Projection Views serve as service‑specific consumption views. They:
✔ Provide fields required for a given service
✔ Hide unnecessary fields from the interface view
✔ Customize field names (alias) based on service needs
✔ Add UI annotations
✔ Define service behavior (create, update, delete, approve, reject)
✔ Add read-only associations from external entities
Why Do We Need Projection Views?
In real applications, different roles require different behavior.
Example Use Case: Travel Application
- Processor App
- Can create, update, delete travel, booking, and supplement records
- Approver App
- Can only read and approve/reject records
- Should not see certain fields needed only for processors
To achieve this, both apps use the same Business Object, but different Projection Views.
Projection views help us:
Denormalize the data model
Use only the necessary 5–7 fields from a large interface view.
Control service permissions
Like for our case – Processor projection → Create, Update, Delete enabled; Approver projection → Only Approve/Reject enabled
Add UI annotations at the right layer
All UI behavior such as:
- Value helps
- Default values
- Field labels
- Grouping
…should be applied at the projection layer.
Add additional read-only associations
Example: A booking supplement might want to display Travel details.
This can be added on the projection view — read-only.
Important Constraints of Projection Views in SAP RAP
Projection Views come with strict but useful limitations:
No write operations on new associations
Any association added at projection level is read-only.
Cannot introduce new persistent fields
You cannot create a new field that persists data to the DB. This means if you want any field that should persist data or save data that should be part of your base interface views. Any fields introduced at projection level cannot persist data to Db and is hence read only.
Can rename elements (alias)
Useful when the same field plays different roles in different services.
Example:
- In one service:
customer - In another:
vendor
Interface View annotations propagate automatically
All annotations we define at interface view level are propagated automatically to consumption views. This means you do not need to redefine annotations for the same fields at projection view level, but there is a catch.
If you rename a field in the projection view, you must redefine all its annotations.
Annotation Propagation in Projection Views in SAP RAP
Here’s the rule:
If you keep the same field name → all annotations from interface view are available.
If you rename/alias the field → you must manually re‑define them.
Example:
Interface View:
@Semantics.amount.currencyCode: 'CurrencyCode'
totalPrice,
currencyCode
Projection View:
currencyCode as Currency
Since the field name changed, you must manually apply the annotations again.
Provider Contracts in Projection Views in SAP RAP
The provider contract specifies the scenario in which a CDS projection view is used.
Every Projection View must define a provider contract, such as:
transactional_querytransactional_interfaceanalytical_query
For RAP BO applications, use: provider contract transactional_query;
Child entities inherit the provider contract automatically — no need to specify it again.
Step‑by‑step creation of Projection view for our RAP Travel App
Now we will create projection views for all the three interface views – Travel, Booking and Booking Supplement. The main aim for creating these views is that we want different UIs or fields and services to be available to the processor and approver.
Right click on package and select new data definition.
Give the details.
In reference object we have provided our interface view on top of which we want our consumption view.
Click next select TR and on next screen select Create projection view.
Now we will get two issues. One root keyword is missing and other contract is missing.
So let us give these values to our view.
You might still get errors like below:
| Description | Resource | Path | Location | Type |
| ZC_TRAVEL_ABHI_M-BOOKINGFEE reference information missing or data type wrong, see long text | ZC_TRAVEL_ABHI_M (Data Definition) | /TRL_EN/.adt/ddic/ddlsources/zc_travel_abhi_m | line 13 | ABAP Syntax Check Problem |
But we just discussed that we do not need to give annotations again in our projection view. Don’t worry. If you observe closely @Metadata.ignorePropogatedAnnotations is set as true. Just make it false and Activate.
One more questions which should come up in your mind – Do we also need to use keyword child while defining our child projection views as we have done for our root view.
The answer is no. We will define in different way. Also we will not define the provider contract as discussed already in our child views.
Now we will create projection views for our child views. Create new data definition same way as we did for travel view.
Click next , provide tr, click next.
Select define projection view and finish.
Activate.
Now same way we will create for booking supplement view also.
Click on finish.
Activate.
Now we will get warning that provider contract is missing in our child views. Let us establish the relationship between projection views.
For this we need to use syntax redirected to composition child using the consumption view name in our root view.
Same way we need to indicate in our child view that travel is the parent.
Now activate both the views together. Similarly we will establish relationship between booking and booking supplement.
Activate both the views together. Also note we need to provide the consumption view name and not interface view name while establishing the relationship.
One last thing we need to do is in booking supplement view we have travel entity which we can also establish relationship with although it is not a direct parent but it is the root view.
Also note if you use redirected to parent for both travel and booking then you will get error. This is because one view can have only one parent.
Finally we will just add some description/text fields that we might need to display to user like Customer Name, Agency Name and Status text.
Note the use of localized keyword which helps us get text in local language where there are language dependency.
Key Takeaways
| Concept | Meaning |
|---|---|
| Projection View | Service-specific view used in RAP |
| Purpose | Reduce fields, apply UI annotations, define behavior |
| Role Separation | Processor vs Approver handled via projection views |
| Read-only Associations | Allowed, but cannot modify data |
| Annotations | Auto-propagate unless alias names are used |
In our next blog we will give UI annotations to our projection views using meta data extensions. Stay tuned.
Also Read : SAP RAP Programming : Read Multiple Entities