RAP Basics Part 3: Projection Layer and Metadata Extensions

📌 KEY POINTS
✅ The projection layer is the app-specific view of a BO: it selects fields, adds value helps, search and texts, and restricts operations — it adds no business logic.
✅ Projection views use "as projection on" and, for transactional services, provider contract transactional_query.
✅ Compositions must be redirected in the projection (redirected to composition child ZC_Booking) so navigation stays inside the projection layer.
⚠️ Putting @UI annotations directly into the projection view makes it hard to read and to adapt — use a metadata extension (@Metadata.allowExtensions: true).
💡 One interface BO, many projections: a UI projection for Fiori and an API projection for integration.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Part 2 built tables and interface views. The projection layer sits on top and is what services expose.

━━━━━━━━━━━━━━━━━━━━
▶ 1. PROJECTION VIEW ENTITY

• define root view entity ZC_Travel provider contract transactional_query as projection on ZI_Travel.
• Only list the fields the app needs.
• Add @Consumption.valueHelpDefinition for fields like AgencyID, CustomerID.

━━━━━━━━━━━━━━━━━━━━
▶ 2. SEARCH AND TEXTS

• @Search.searchable: true on the view, @Search.defaultSearchElement on fields.
• @ObjectModel.text.element: ['AgencyName'] shows text next to the ID.
• Denormalise names through associations (_Agency.Name).

━━━━━━━━━━━━━━━━━━━━
▶ 3. REDIRECTING COMPOSITIONS

• Interface: composition [0..*] of ZI_Booking as _Booking.
• Projection: _Booking : redirected to composition child ZC_Booking.
• Child projection: _Travel : redirected to parent ZC_Travel.

━━━━━━━━━━━━━━━━━━━━
▶ 4. METADATA EXTENSIONS

• @Metadata.layer: #CORE (or #CUSTOMER) annotate view ZC_Travel with { … }.
• Holds @UI.headerInfo, @UI.facet, @UI.lineItem, @UI.identification, @UI.selectionField.
• Layers allow partner/customer overrides without changing the view.

━━━━━━━━━━━━━━━━━━━━
▶ 5. PROJECTION BDEF

• projection; strict ( 2 ); use draft; define behavior for ZC_Travel { use create; use update; use action … }
• Leaving out "use delete" removes delete from this app only.

━━━━━━━━━━━━━━━━━━━━
▶ STEP BY STEP

1. Create ZC_Travel as projection on ZI_Travel with provider contract.
2. Add value helps, search and text annotations.
3. Redirect compositions in root and child projections.
4. Create a metadata extension with UI annotations.
5. Create the projection BDEF with "use" statements.

✅ CHECKPOINT: you can explain why UI annotations belong in a metadata extension and business logic in the interface BDEF.

A consumer-health client needed two apps on the same promotion BO: a planner app with full editing and a read-mostly approver app. The first build duplicated the BO — two interface stacks with copied validations, which drifted apart within a month. The architect consolidated to one interface BO with two projections: ZC_PromoPlanner (use create/update/delete, all actions) and ZC_PromoApprover (only use action approve/reject), each with its own metadata extension. Validations now exist once, and a later rule change needed one edit instead of two.

• Writing validations or determinations for a projection instead of the interface BO.
• Forgetting to redirect compositions, so navigation leaves the projection layer and activation fails.
• Missing provider contract transactional_query on transactional projections.
• Putting all UI annotations into the projection view instead of a metadata extension.
• Copying a whole BO to get a second app instead of adding a second projection.

• Keep projections thin: field selection, value helps, texts, search, "use" statements.
• Use metadata extensions for all @UI annotations.
• Create separate projections for UI and API consumers.
• Denormalise display texts in the projection via associations.
• Restrict operations per app in the projection BDEF rather than with code.

Questions: "What is the purpose of the projection layer in RAP?", "Why use metadata extensions?", "How do you give two apps different operations on one BO?"
Strong answer: the projection is the consumer-specific view — fields, value helps, texts, search and a subset of operations via "use" statements — with provider contract transactional_query and redirected compositions. Metadata extensions separate UI annotations and support layering. Two apps = one interface BO + two projections + two projection BDEFs, not two BOs.