Lesson 16 — RAP Projection, Value Help, Metadata, and OData V4

By the end of Lesson 15, the Reservation Business Object already has:

Persistence
Business Object structure
Managed behavior
EML
Determinations
Validations
Messages
Actions
Feature control
Authorization

But it still has no consumer-facing business service.

Today you add the service layer.

The architecture becomes:

Persistence
    ↓
ZR_RESERVATION_###
Base RAP Business Object
    ↓
ZC_RESERVATION_###
Transactional Projection
    ↓
Projection Behavior
    ↓
Service Definition
    ↓
Service Binding
    ↓
OData V4 UI Service
    ↓
Fiori Elements Preview

This is a major architectural transition.

Until now, your main consumer was:

ABAP class
→ EML
→ RAP BO

Today you add:

UI / OData consumer
→ OData V4
→ projected RAP BO

---

Lesson information

Teacher-led time	About 3 hours
Self-practice time	About 3 hours
Environment	SAP BTP ABAP Trial
Prerequisite	Lesson 15
Base BO	ZR_RESERVATION_###
Projection view	ZC_RESERVATION_###
Projection BDEF	Behavior Definition for ZC_RESERVATION_###
Projection DCL	Access Control for ZC_RESERVATION_###
Metadata extension	ZC_RESERVATION_###
Service definition	ZUI_RESERVATION_###
Service binding	ZUI_RESV_###_O4
Protocol	OData V4 UI
Main outcome	Expose and preview a protected RAP UI service

Replace:

###

with your own student/group suffix.

---

Learning objectives

After the teacher-led part, you should be able to:

• explain why RAP uses a projection layer;
• distinguish the base BO from a service-specific BO projection;
• create a CDS transactional projection view;
• use provider contract transactional_query;
• explain why the projection must remain a root view;
• understand that projection views cannot add new persistent fields;
• preserve CDS access control at the projection layer;
• create projection-level DCL by inheriting base access conditions;
• create a projection Behavior Definition;
• use projection; and strict ( 2 );
• use use etag;
• expose standard operations with use create, use update, and use delete;
• expose base actions with use action;
• explain that reused operations inherit base behavior implementation and authorization;
• define a simple CDS value help with @Consumption.valueHelpDefinition;
• expose the value-help provider in the service;
• enable metadata extensions with @Metadata.allowExtensions: true;
• create UI metadata in a metadata extension;
• use @UI.headerInfo, @UI.lineItem, @UI.identification, and @UI.selectionField;
• create a Service Definition;
• explain what a Service Definition exposes;
• create an OData V4 UI Service Binding;
• explain what a Service Binding adds;
• publish the local service;
• launch the Fiori Elements preview;
• verify authorization, actions, field control, value help, and messages through the service;
• explain why full draft editing is deferred until Lesson 17.

---

Architecture

1. What changes today?

Before Lesson 16:

ZCL_RESV_AUTH_###
       ↓
      EML
       ↓
ZR_RESERVATION_###
       ↓
Managed RAP

After Lesson 16:

ABAP consumer
    ↓
   EML
    ↓
ZR_RESERVATION_###

and also:

Fiori Elements Preview
        ↓
     OData V4
        ↓
Service Binding
        ↓
Service Definition
        ↓
ZC_RESERVATION_###
        ↓
Projection Behavior
        ↓
ZR_RESERVATION_###
        ↓
Managed RAP

One BO can support multiple consumption channels.

---

2. Why not expose the root directly?

The root BO describes:

general business structure
general business behavior

A service may need a consumer-specific view.

For example:

only selected fields
specific labels
search behavior
value helps
specific actions
UI metadata
service-specific names

That belongs in:

the projection / consumption layer

not the reusable base BO.

---

3. Base BO vs projection BO

Base BO

ZR_RESERVATION_###

Answers:

What is a Reservation?
What can a Reservation do?
What business rules protect it?

Projection

ZC_RESERVATION_###

Answers:

What part of that BO should this service expose?
How should this consumer see it?
Which behavior should this service offer?

---

4. Projection is not a copy

A projection view does not duplicate persistence.

It sits on top of the base CDS entity:

ZRESV_###
    ↓
ZR_RESERVATION_###
    ↓
ZC_RESERVATION_###

The service still reaches the same BO and persistence.

---

Projection View

5. Create the projection Data Definition

Right-click:

ZR_RESERVATION_###

Choose:

New
→ Data Definition

Use:

Name:        ZC_RESERVATION_###
Description: Reservation Service Projection

Choose the projection-view template if available.

---

6. Use a transactional projection

The projection must be:

define root view entity ZC_Reservation_###
  provider contract transactional_query
  as projection on ZR_Reservation_###

Two pieces are important:

root
transactional_query

---

7. Why root remains

The underlying entity is the root of the Business Object.

The service-facing projection must preserve that root role.

For our single-node BO:

ZR_RESERVATION_###
→ base root

ZC_RESERVATION_###
→ projected root

---

8. Why transactional_query

Current CDS projection views use a provider contract to state their use case.

For a service-specific RAP BO projection:

provider contract transactional_query

is the intended contract.

It enables the projection to specialize the underlying transactional RAP BO for consumption.

---

9. Projection views are service-specific

A projection can:

project a subset of elements
rename elements
add service-specific metadata
define value-help annotations
add certain projection-level calculated/virtual elements

But it does not create a new persistence model.

---

10. Projection fields for this lesson

Expose:

Uuid
ReservationNo
CustomerName
CustomerEmail
WorkshopCode
ReservationDate
Status
ResponsibleUser
Fee
CurrencyCode
Notes
LocalCreatedBy
LocalCreatedAt
LocalLastChangedBy
LocalLastChangedAt
LastChangedAt

Keeping all fields visible makes the first service lesson easier to debug.

Later services can intentionally expose less.

---

11. Projection CDS source

Use:

@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: 'Reservation Service Projection'
@Metadata.allowExtensions: true
@Search.searchable: true

define root view entity ZC_Reservation_###
  provider contract transactional_query
  as projection on ZR_Reservation_###
{
  key Uuid,

      @Search.defaultSearchElement: true
      ReservationNo,

      @Search.defaultSearchElement: true
      CustomerName,

      CustomerEmail,
      WorkshopCode,
      ReservationDate,
      Status,
      ResponsibleUser,

      Fee,

      @Consumption.valueHelpDefinition: [
        {
          entity: {
            name: 'I_CurrencyStdVH',
            element: 'Currency'
          },
          useForValidation: true
        }
      ]
      CurrencyCode,

      Notes,
      LocalCreatedBy,
      LocalCreatedAt,
      LocalLastChangedBy,
      LocalLastChangedAt,
      LastChangedAt
}

Replace ###.

---

12. Search annotations

At view level:

@Search.searchable: true

Then selected fields can be:

@Search.defaultSearchElement: true

For this lesson:

ReservationNo
CustomerName

are default search elements.

---

13. Why search belongs here

Search behavior is:

consumer/service-specific

It does not define the core business object itself.

That makes the projection layer an appropriate home.

---

Value Help

14. What is value help?

A value help gives a consumer a list of valid/selectable values for an input field.

Classic user experience:

F4 / value-help button

Example:

CurrencyCode
→ choose from available currencies

---

15. @Consumption.valueHelpDefinition

The projection annotates:

CurrencyCode

with:

@Consumption.valueHelpDefinition: [
  {
    entity: {
      name: 'I_CurrencyStdVH',
      element: 'Currency'
    },
    useForValidation: true
  }
]

Meaning:

value-help provider
→ I_CurrencyStdVH

returned value
→ Currency

---

16. Why value help belongs in the projection

Value help is consumer-facing metadata.

The base business object should not need to know:

which lookup dialog this specific UI service uses

That is one reason projections exist.

---

17. Value help does not replace validation

A value help helps the user choose.

Your backend business rules still protect data.

Think:

Value help
→ assists input

Validation
→ protects business validity

Do not use UI convenience as your only backend protection.

---

18. Value-help provider must be exposed

For OData consumption, the value-help provider must be reachable through the service.

So later the Service Definition will expose:

I_CurrencyStdVH

as a service entity.

---

Preserve Lesson 15 Read Authorization

19. DCL does not automatically propagate upward

This is important.

You protected:

ZR_RESERVATION_###

in Lesson 15.

But:

ZC_RESERVATION_###

is a new CDS entity.

CDS access controls are not automatically inherited by higher-layer CDS entities.

Without projection-level protection, exposing the projection could reopen read access.

---

20. Create projection Access Control

Create an Access Control object for:

ZC_RESERVATION_###

Use:

@EndUserText.label: 'Reservation Projection Access'
@MappingRole: true
define role ZC_Reservation_###
{
  grant select on ZC_Reservation_###
    where inheriting conditions from entity ZR_Reservation_###;
}

This reuses the Lesson 15 access condition.

---

21. Why inherit instead of duplicate?

You could repeat:

ResponsibleUser = aspect user

But then you would maintain the same authorization rule in two places.

Inheritance keeps:

ZR_RESERVATION_###

as the source of the read-access condition.

Projection DCL reuses it.

---

22. Root and projection now both use #CHECK

Base:

ZR_RESERVATION_###
→ #CHECK

Projection:

ZC_RESERVATION_###
→ #CHECK

Each protected CDS entity has an appropriate access control.

---

23. Activate and test the projection

Activate:

projection CDS
projection Access Control

Use:

F8

Expected:

only Reservations permitted by inherited DCL

The projection should not reveal the Lesson 15 unassigned/unauthorized rows.

---

Projection Behavior

24. Why a projection BDEF?

The projection CDS controls:

service-facing data shape

The projection Behavior Definition controls:

service-facing behavior surface

It answers:

Which operations from the base BO should this service expose?

---

25. Create projection behavior

Right-click:

ZC_RESERVATION_###

Choose:

New
→ Behavior Definition

Select:

Implementation Type: Projection

---

26. Projection BDEF header

Use:

projection;
strict ( 2 );

This BDEF does not implement a new managed BO.

It projects existing behavior.

---

27. Reuse ETag behavior

Add:

use etag

to the entity behavior.

The underlying BO already defines:

LocalLastChangedAt

as ETag master.

The projection explicitly reuses the ETag for the service.

---

28. Reuse standard operations

Expose:

use create;
use update;
use delete;

These do not create new CRUD implementations.

They expose the underlying BO operations through this projection.

---

29. Reuse actions

Expose:

use action confirm;
use action cancel;

The action implementation remains in:

ZBP_R_RESV_###

There is no new action implementation class for the projection.

---

30. Complete projection BDEF

Use:

projection;
strict ( 2 );

define behavior for ZC_Reservation_### alias Reservation
use etag
{
  use create;
  use update;
  use delete;

  use action confirm;
  use action cancel;
}

Replace ###.

---

31. What gets inherited?

Reused operations/actions continue to rely on the base BO for:

implementation
validations
determinations
messages
feature control
authorization
transaction handling

The projection decides:

expose it
or
do not expose it

---

32. Projection behavior can expose less

Suppose a read-only service should not allow deletes.

Its projection BDEF could omit:

use delete;

even though the base BO supports delete.

This is one purpose of the service-specific behavior layer.

---

33. Authorization is still active

Reused CRUD operations and reused actions inherit authorization control from the base behavior.

Lesson 15 therefore remains relevant through the service.

You are not creating a second authorization implementation.

---

Metadata Extension

34. What is UI metadata?

The service now knows:

data
behavior
authorization

But a UI also needs presentation hints.

Examples:

which fields appear in the list
which fields appear on the object page
which fields are filter fields
what title represents an object
how fields are ordered

These are:

UI annotations

---

35. Why use a metadata extension?

You could place many UI annotations directly in the projection CDS.

SAP recommends separating UI annotations into a metadata extension where practical.

Benefits:

projection source stays readable
UI metadata can evolve independently
separation of concerns

---

36. Enable metadata extensions

The projection already contains:

@Metadata.allowExtensions: true

Without it, the external metadata extension cannot annotate the projection.

---

37. Create Metadata Extension

In ADT:

Right-click projection Data Definition
→ New
→ Metadata Extension

Use a name based on:

ZC_RESERVATION_###

Choose the core metadata layer.

---

38. Metadata extension header

Use:

@Metadata.layer: #CORE

@UI.headerInfo: {
  typeName: 'Reservation',
  typeNamePlural: 'Reservations',
  title: {
    type: #STANDARD,
    value: 'ReservationNo'
  }
}

annotate entity ZC_Reservation_### with
{
  ...
}

---

39. List report fields

Annotate key business fields with:

@UI.lineItem

Recommended list order:

ReservationNo
CustomerName
WorkshopCode
ReservationDate
Status
Fee
CurrencyCode
ResponsibleUser

---

40. Object-page fields

Use:

@UI.identification

for the same important fields plus:

CustomerEmail
Notes

This helps Fiori Elements construct the object page.

---

41. Selection fields

Use:

@UI.selectionField

for fields such as:

Status
ReservationDate
CurrencyCode

These become useful filters in the generated UI.

---

42. Metadata extension reference

Use a source equivalent to:

@Metadata.layer: #CORE

@UI.headerInfo: {
  typeName: 'Reservation',
  typeNamePlural: 'Reservations',
  title: {
    type: #STANDARD,
    value: 'ReservationNo'
  }
}

annotate entity ZC_Reservation_### with
{
  @UI.facet: [
    {
      id: 'Reservation',
      purpose: #STANDARD,
      type: #IDENTIFICATION_REFERENCE,
      label: 'Reservation',
      position: 10
    }
  ]
  @UI.lineItem: [
    { position: 10, label: 'Reservation' }
  ]
  @UI.identification: [
    { position: 10, label: 'Reservation' }
  ]
  ReservationNo;

  @UI.lineItem: [
    { position: 20, label: 'Customer' }
  ]
  @UI.identification: [
    { position: 20, label: 'Customer' }
  ]
  CustomerName;

  @UI.identification: [
    { position: 30, label: 'Customer Email' }
  ]
  CustomerEmail;

  @UI.lineItem: [
    { position: 30, label: 'Workshop' }
  ]
  @UI.identification: [
    { position: 40, label: 'Workshop' }
  ]
  WorkshopCode;

  @UI.lineItem: [
    { position: 40, label: 'Reservation Date' }
  ]
  @UI.identification: [
    { position: 50, label: 'Reservation Date' }
  ]
  @UI.selectionField: [
    { position: 20 }
  ]
  ReservationDate;

  @UI.lineItem: [
    { position: 50, label: 'Status' },
    { position: 90, type: #FOR_ACTION, dataAction: 'confirm', label: 'Confirm' },
    { position: 100, type: #FOR_ACTION, dataAction: 'cancel', label: 'Cancel' }
  ]
  @UI.identification: [
    { position: 60, label: 'Status' },
    { position: 110, type: #FOR_ACTION, dataAction: 'confirm', label: 'Confirm' },
    { position: 120, type: #FOR_ACTION, dataAction: 'cancel', label: 'Cancel' }
  ]
  @UI.selectionField: [
    { position: 10 }
  ]
  Status;

  @UI.lineItem: [
    { position: 60, label: 'Fee' }
  ]
  @UI.identification: [
    { position: 70, label: 'Fee' }
  ]
  Fee;

  @UI.lineItem: [
    { position: 70, label: 'Currency' }
  ]
  @UI.identification: [
    { position: 80, label: 'Currency' }
  ]
  @UI.selectionField: [
    { position: 30 }
  ]
  CurrencyCode;

  @UI.lineItem: [
    { position: 80, label: 'Responsible User' }
  ]
  @UI.identification: [
    { position: 90, label: 'Responsible User' }
  ]
  ResponsibleUser;

  @UI.identification: [
    { position: 100, label: 'Notes' }
  ]
  Notes;
}

---

43. Expose action buttons in UI metadata

The projection behavior exposes:

confirm
cancel

For Fiori Elements to render action buttons, add action records to UI metadata using:

type: #FOR_ACTION
dataAction: '<action name>'

The Lesson 16 metadata extension attaches confirm and cancel action records to the Status element for both:

@UI.lineItem
@UI.identification

The element used as the annotation carrier does not determine where the action appears; the UI renders the action in the appropriate action area.

---

Service Definition

44. What is a Service Definition?

A Service Definition answers:

What CDS entities are part of this business service?

It is:

protocol-independent

It does not decide:

OData V2
OData V4
UI
Web API

That comes later in the Service Binding.

---

45. Create Service Definition

Right-click your package.

Choose:

New
→ Other ABAP Repository Object
→ Business Services
→ Service Definition

Use:

Name:        ZUI_RESERVATION_###
Description: Reservation UI Service

---

46. Expose the projection

Use:

@EndUserText.label: 'Reservation UI Service'
define service ZUI_RESERVATION_###
{
  expose ZC_Reservation_### as Reservations;
  expose I_CurrencyStdVH    as Currencies;
}

---

47. Why expose Currencies?

Your projection references:

I_CurrencyStdVH

as the value-help provider.

For the OData value help to work, expose the provider through the service.

---

48. Service Definition = what

Remember:

Service Definition
→ WHAT is exposed

It chooses the CDS entities.

It does not choose the transport protocol.

---

Service Binding

49. What is a Service Binding?

A Service Binding answers:

HOW is this service exposed?

It binds the Service Definition to a communication protocol and service category.

For this lesson:

OData V4
UI

---

50. Why OData V4?

SAP recommends OData V4 wherever possible for transactional services.

It supports modern RAP capabilities such as:

feature control exposure
value help
Fiori Elements preview

Lesson 17 will add Draft, which is especially important for full transactional Fiori Elements editing with OData V4.

---

51. Create the Service Binding

In ADT:

Right-click package
→ New
→ Other ABAP Repository Object
→ Business Services
→ Service Binding

Use:

Name:               ZUI_RESV_###_O4
Description:        Reservation OData V4 UI
Service Definition: ZUI_RESERVATION_###
Binding Type:       OData V4 - UI

The exact wizard wording may appear as:

OData V4
UI Service

depending on ADT version.

---

52. Activate before publishing

Activate:

Ctrl+F3

The binding must be active before local publishing/preview.

---

53. Publish the service

Open the Service Binding editor.

Choose:

Publish

This enables the local service endpoint in the development system.

Publishing locally is not the same thing as deploying a productive application to another system.

---

54. Inspect the entity sets

The binding should expose service entities equivalent to:

Reservations
Currencies

The service-facing aliases come from the Service Definition.

---

55. Service Binding = how

Remember:

Service Definition
→ WHAT

Service Binding
→ HOW

For this project:

WHAT
Reservations + Currencies

HOW
OData V4 UI service

---

Fiori Elements Preview

56. Launch Preview

In the Service Binding editor:

select Reservations
→ Preview

The exact button arrangement can vary by ADT version.

The preview opens a generated Fiori Elements application.

---

57. What the preview proves

It proves that these layers work together:

projection
projection behavior
DCL
base RAP authorization
UI metadata
value help
service definition
service binding
OData V4 runtime

This is much more than simply proving that a CDS view activates.

---

58. Verify list fields

Expected list fields include:

Reservation
Customer
Workshop
Reservation Date
Status
Fee
Currency
Responsible User

If the list is empty, remember Lesson 15:

DCL may hide older rows

Use a Reservation owned by the current user.

---

59. Verify search

Use the search field.

Try a value from:

ReservationNo
or
CustomerName

The projection marked those fields as default search elements.

---

60. Verify selection fields

Look for filters corresponding to:

Status
ReservationDate
CurrencyCode

Their UI location comes from the metadata extension.

---

61. Verify Currency value help

Open the value help for:

CurrencyCode

The service should use:

I_CurrencyStdVH

as its provider.

Choose a value and verify that the currency code is transferred to the field.

---

62. Verify actions

On an authorized New Reservation:

confirm
cancel

should reflect the Lesson 14 feature-control rules.

Example:

Status = N
→ confirm available
→ cancel available

After confirm:

Status = C
→ confirm unavailable
→ cancel available

The UI consumes behavior already implemented in the base BO.

---

63. Verify dynamic field control

For:

Status = N

Fee/Currency can be editable.

After:

Status = C
or
Status = X

they should reflect the read-only feature result.

You did not write new UI logic for this.

The service exposes RAP feature control.

---

64. Verify authorization

Use a row whose:

ResponsibleUser = current user

It should be readable and modifiable according to Lesson 15.

Unauthorized rows should not simply appear because a new projection/service was created.

That is why projection DCL matters.

---

65. Verify validation messages

Attempt to create or change data that violates Lesson 13 rules.

Examples:

blank CustomerName
past ReservationDate
Fee <= 0
missing CurrencyCode

The service consumer should receive backend validation messages.

Again:

UI does not own the rules
BO owns the rules

---

Non-Draft Limitation

66. Lesson 16 is deliberately non-draft

The BO is still:

non-draft

You are exposing it through OData V4 so you can understand:

projection
service
metadata
value help
behavior exposure

before adding Draft.

---

67. Why Draft comes next

SAP notes that full Fiori Elements support for transactional OData V4 UI services is tied strongly to draft-enabled scenarios.

Lesson 17 will add:

draft persistence
draft actions
active vs draft state
edit
save
discard

That will make the UI editing lifecycle more complete.

---

68. Do not fake Draft with a Status value

A field such as:

Status = New

is business state.

RAP Draft is framework-managed transactional editing state.

They are not the same thing.

This distinction is why Checkpoint 3 uses:

N = New

rather than:

D = Draft

---

Service-Layer Responsibilities

69. What belongs in the projection?

Good projection concerns:

service-specific field subset
search annotations
value help
text arrangement
consumer-specific aliases
UI-facing semantics

---

70. What belongs in metadata extension?

Good metadata-extension concerns:

header information
line-item positions
identification fields
selection fields
facets
UI labels

---

71. What belongs in the base BO?

Keep business logic in:

base behavior / Behavior Pool

Examples:

validations
determinations
workflow actions
feature logic
authorization logic

Do not move those into the UI metadata layer.

---

72. What belongs in Service Definition?

Only:

which entities the business service exposes

The Service Definition is not the place for:

validation code
behavior implementation
protocol configuration

---

73. What belongs in Service Binding?

Protocol/service-category configuration:

OData V4
UI
local publish
service endpoint
preview

The binding does not redefine business rules.

---

Common Mistakes

74. Mistake — exposing the base root directly

Technically, service definitions can expose CDS entities.

But for a structured RAP application, use the projection layer to keep:

base BO reusable
service specifics separate

---

75. Mistake — no provider contract

Current projection-view modeling should explicitly specify:

provider contract transactional_query

Do not rely on old implicit behavior.

---

76. Mistake — forget root

Your projected root must remain:

define root view entity

not merely:

define view entity

---

77. Mistake — projection with no projection BDEF

The projection CDS may show data.

But to expose transactional BO behavior through the service, create the projection Behavior Definition and explicitly reuse the operations/actions required by the service.

---

78. Mistake — assume behavior is automatically exposed

Projection BDEF uses:

use create
use update
use delete
use action ...

The base supports behavior.

The projection decides what the service exposes.

---

79. Mistake — forget use etag

The base BO has ETag behavior.

The service projection should explicitly reuse:

use etag

for concurrency-aware service behavior.

---

80. Mistake — DCL only on the base view

CDS access controls do not automatically propagate to higher CDS entities.

If the service exposes:

ZC_RESERVATION_###

protect:

ZC_RESERVATION_###

too.

This is a security-critical modeling point.

---

81. Mistake — duplicate DCL manually

You could repeat the same user rule.

Prefer:

inheriting conditions from entity

when the projection should reuse the base rule unchanged.

---

82. Mistake — value-help provider not exposed

The projection can contain:

@Consumption.valueHelpDefinition

but the OData service also needs access to the referenced provider.

Expose:

I_CurrencyStdVH

in the Service Definition.

---

83. Mistake — Service Definition vs Binding confusion

Remember:

Definition
→ what

Binding
→ how

A Service Definition alone does not create an OData endpoint.

---

84. Mistake — annotations everywhere

Do not put every UI annotation into:

ZR_RESERVATION_###

Keep service/UI concerns near the projection layer.

Prefer a metadata extension for substantial UI metadata.

---

85. Mistake — UI validation instead of BO validation

A value help or field control improves user experience.

It does not replace:

backend validation
authorization
business rules

Lesson 13–15 behavior remains authoritative.

---

86. Mistake — expect full draft-style edit flow

This is still a non-draft BO.

Do not confuse:

OData V4 service exists

with:

RAP Draft exists

Draft comes in Lesson 17.

---

Certification Alignment

87. Why this lesson matters

A practical RAP task can require you to navigate and repair several connected repository objects:

root CDS
projection CDS
projection BDEF
DCL
metadata extension
service definition
service binding

You need to understand which object owns which responsibility.

---

88. Certification repair map

If:

fields missing from service
→ projection / Service Definition

create/update/delete missing
→ projection BDEF

action missing
→ projection BDEF

wrong rows visible
→ projection DCL

value help missing
→ valueHelp annotation / provider exposure

list columns wrong
→ metadata extension

service endpoint missing
→ Service Binding / publish

business rule wrong
→ base Behavior Pool

---

89. BTP Trial reproducibility

This lesson is designed to be reproducible in BTP Trial:

projection view
projection behavior
DCL
metadata extension
Service Definition
OData V4 UI binding
local publish
Fiori Elements preview

Productive launchpad deployment and enterprise role administration remain outside the Trial exercise.

---

Knowledge Check

90. Questions

1. Why do we create ZC_RESERVATION_### instead of exposing only ZR_RESERVATION_###?

2. What does provider contract transactional_query mean?

3. Why must the projection remain a root view?

4. What is the purpose of a projection Behavior Definition?

5. What does use create mean?

6. Where is the actual create implementation?

7. Why do we use use etag?

8. Do reused operations lose Lesson 15 authorization?

9. Why does the projection need its own DCL?

10. What does inheriting conditions from entity solve?

11. What does @Consumption.valueHelpDefinition do?

12. Why must the value-help provider be exposed in the service?

13. What does @Metadata.allowExtensions: true enable?

14. Why place UI annotations in a metadata extension?

15. Service Definition: what or how?

16. Service Binding: what or how?

17. Why use OData V4 UI?

18. What does Fiori Elements Preview prove?

19. Why are validations still implemented in the base BO?

20. Why is Draft not part of this lesson?

---

Teacher-Led Completion Checklist

91. Checklist

• ZC_RESERVATION_### created.
• Projection uses define root view entity.
• Projection uses provider contract transactional_query.
• Projection selects from ZR_RESERVATION_###.
• Projection uses #CHECK.
• @Metadata.allowExtensions: true present.
• Search enabled.
• ReservationNo and CustomerName default-searchable.
• CurrencyCode has value help.
• Projection DCL created.
• Projection DCL inherits from root DCL.
• Projection Data Preview respects read authorization.
• Projection BDEF created.
• Projection BDEF uses projection;.
• Projection BDEF uses strict ( 2 ).
• use etag present.
• Create projected.
• Update projected.
• Delete projected.
• Confirm action projected.
• Cancel action projected.
• Metadata extension created.
• Header info added.
• Line items added.
• Identification fields added.
• Selection fields added.
• ZUI_RESERVATION_### created.
• Reservation projection exposed.
• Currency value-help provider exposed.
• ZUI_RESV_###_O4 created.
• Binding type is OData V4 UI.
• Service binding activated.
• Service locally published.
• Fiori Elements Preview opens.
• Search works.
• Currency value help works.
• Authorized data is visible.
• Unauthorized data is not reopened by projection.
• Actions are exposed.
• Feature control remains effective.
• Validation messages remain effective.
• No RAP Draft artifacts created yet.

---

End-of-Day Mental Model

92. Final model

                    Consumer
                       ↓
                 OData V4 UI
                       ↓
                 Service Binding
                       ↓
                Service Definition
                       ↓
           ZC_RESERVATION_###
              Projection View
              + Projection DCL
                       ↓
              Projection Behavior
                       ↓
           ZR_RESERVATION_###
                Base RAP BO
                       ↓
      Rules / Actions / Authorization
                       ↓
                 Persistence

Remember:

Projection
→ consumer-specific BO shape

Projection BDEF
→ consumer-specific behavior surface

Metadata Extension
→ UI presentation metadata

Service Definition
→ WHAT is exposed

Service Binding
→ HOW it is exposed

OData V4
→ protocol

Fiori Elements Preview
→ generated consumer/test surface

Lesson 17 adds:

RAP Draft
→ edit lifecycle
→ active/draft instances
→ save/discard
→ draft-aware OData V4 UI