Lesson 10 — RAP Foundations: Business Object Structure

Until now, your application architecture has looked roughly like this:

Runner
  ↓
Reader
  ↓
CDS / ABAP SQL
  ↓
Database Table

For controlled persistence exercises, you also used:

SQL Lifecycle Class
       ↓
ABAP SQL
       ↓
Database Table

That taught you what persistence actually looks like.

Now the architecture changes.

We begin the ABAP RESTful Application Programming Model (RAP).

Today we will not build a service.

We will not build a UI.

We will not write EML.

We will not define create, update, or delete behavior.

Today is about the first RAP question:

What is the business object, structurally?

---

Lesson information

Teacher-led time	About 3 hours
Self-practice time	About 3 hours
Environment	SAP BTP ABAP Trial
Prerequisites	Lessons 1–9 + checkpoint project
Existing persistence	ZRESV_###
New CDS root	ZR_RESERVATION_###
Main outcome	RAP Business Object root data model
Behavior Definition today?	No — Lesson 11

Replace ### with your own student/group suffix.

---

Learning objectives

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

• explain what RAP adds above raw persistence;
• distinguish persistence from a RAP Business Object data model;
• explain the two major parts of a RAP Business Object;
• explain the role of the root entity;
• distinguish define view entity from define root view entity;
• explain why a single-node BO can still have a root;
• create a RAP root CDS View Entity over custom persistence;
• expose business fields with clear CDS names;
• omit the technical client field from the BO model;
• preserve amount/currency semantics;
• add RAP administrative-field semantics;
• explain managed vs unmanaged RAP at a conceptual level;
• explain why managed RAP is the natural first choice for new course persistence;
• explain why Lesson 10 deliberately stops before the Behavior Definition.

---

1. What is RAP and what is it for?

RAP stands for:

ABAP RESTful Application Programming Model

It is SAP's application programming model for building modern transactional applications and APIs in ABAP Cloud.

RAP gives you a structured way to turn application data into business objects that have:

data structure
transactional behavior
business rules
authorization
concurrency control
service exposure

Instead of every application inventing its own way to:

create data
change data
delete data
validate changes
protect data
report errors
expose APIs

RAP provides a consistent framework for doing those things.

A RAP Business Object can later be consumed through different entry points.

For example:

ABAP code
   ↓
EML
   ↓
RAP Business Object

or:

Fiori application
      ↓
OData V4 service
      ↓
RAP Business Object

or:

External service consumer
          ↓
      OData service
          ↓
RAP Business Object

The important idea is:

Consumers work with the business object contract rather than directly changing the database table.

RAP is therefore not just:

another way to define a CDS view

It is the framework that connects:

Persistence
    ↓
Business Object structure
    ↓
Business Object behavior
    ↓
Application / API consumption

In this course, we will build those layers gradually.

Today we begin with:

Business Object structure

---

2. Where RAP begins

You already own this persistence:

ZRESV_###

It stores Workshop Reservations.

But a database table is not a complete application-level business contract.

A table knows:

columns
types
keys
stored rows

It does not, by itself, define application behavior such as:

which operations are allowed
which fields are read-only
which fields are mandatory
how IDs are generated
how locking works
how optimistic concurrency works
how validation works
which actions exist
how authorization is checked
how transactional changes are saved

RAP introduces a business-object abstraction above persistence.

---

3. The architecture transition

Before RAP, your write exercise looked like:

Consumer Class
      ↓
ABAP SQL
      ↓
ZRESV_###

Later in RAP, normal consumers will work through the business object:

Consumer
   ↓
EML / Business Service
   ↓
RAP Business Object
   ↓
Persistence

The persistence still exists.

RAP does not make the database table disappear.

Instead, RAP gives application code a controlled business contract above it.

---

4. What is a RAP Business Object?

Conceptually, a RAP Business Object has two major parts:

Structure
+
Behavior

Structure

The structure is modeled in CDS.

It describes:

entities
fields
keys
relationships
root / child hierarchy
business-facing data model

Behavior

The Behavior Definition describes what consumers may do with those entities.

Examples include:

create
update
delete
actions
validations
determinations
field control
locking
authorization

Today we build only:

Structure

Lesson 11 adds:

Behavior

---

5. Do we have a complete transactional BO today?

Not yet.

At the end of Lesson 10 you will have:

persistence
+
RAP root CDS data model

You will not yet have the complete transactional behavior contract.

That arrives when the Behavior Definition is added.

Use this mental model:

Lesson 10
BO data model / structure

Lesson 11
BO behavior contract

---

6. Business Object structure can be hierarchical

A RAP Business Object may contain:

Root
 ├─ Child
 ├─ Child
 │   └─ Grandchild
 └─ Child

For example:

Travel
 └─ Booking
     └─ Booking Supplement

Those internal parent/child relationships are modeled later using:

composition
association to parent

We are not learning composition today.

---

7. A Business Object can also have one node

A BO does not need children.

Our first BO will contain only:

Reservation

So structurally:

Reservation

is both:

root entity
+
leaf entity

It is still declared as a root because every BO hierarchy begins at one root.

---

8. Root does not mean primary key

Do not confuse:

root entity

with:

key field

They describe different ideas.

Root

Describes the entity's role in the BO hierarchy.

Reservation
=
top of the Business Object

Key

Identifies one entity instance.

Uuid
=
identity of one Reservation instance

---

9. Root does not mean database root

The root designation belongs to the CDS business-object model.

The physical persistence remains:

ZRESV_###

The root entity will be:

ZR_RESERVATION_###

Architecture:

ZR_RESERVATION_###
        ↓
    ZRESV_###

The CDS root is not another physical database table.

---

10. Normal CDS View Entity vs root CDS View Entity

You already know:

define view entity ...

Today you add:

define root view entity ...

A normal View Entity can be used for many query/data-model purposes.

A root View Entity specifically declares:

This entity is the root of a business-object hierarchy.

---

11. Naming convention

Create:

ZR_RESERVATION_###

For this course:

ZR_

means:

RAP root/base entity

This is a project naming convention.

The important language feature is not the ZR_ prefix.

It is:

define root view entity

---

12. Inspect the existing persistence

Open:

ZRESV_###

Recall the structure:

client
uuid

reservation_no
customer_name
customer_email
workshop_code
reservation_date
status

fee
currency_code
notes

local_created_by
local_created_at
local_last_changed_by
local_last_changed_at
last_changed_at

The technical key is:

client + uuid

Our root CDS will transform this storage-oriented structure into a cleaner business-facing entity.

---

13. Create the root CDS Data Definition

Right-click your package.

Choose:

New
  → Other ABAP Repository Object
  → Core Data Services
  → Data Definition

Use:

Name:        ZR_RESERVATION_###
Description: Reservation RAP Root

Choose the course transport if required.

Choose Finish.

---

14. Start with the root declaration

Use:

@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Reservation'

define root view entity ZR_Reservation_###
  as select from zresv_### as Reservation
{
}

Do not copy an old-style CDS View template containing:

@AbapCatalog.sqlViewName

This course uses CDS View Entities.

---

15. Understand define root view entity

The declaration:

define root view entity ZR_Reservation_###

states that this CDS entity is intended to be the root entity of a business-object hierarchy.

For today:

Reservation
=
root
=
only node

Later, a root can have compositions.

---

16. Why select directly from the persistence table?

For this first managed RAP scenario:

ZR_RESERVATION_###

is a transactional base data model over:

ZRESV_###

The direct relationship keeps the first BO easy to reason about:

CDS field
↔
persistence field

Lesson 11 will make that connection explicit in the Behavior Definition.

---

17. Do not expose the client field

The table contains:

client

Do not expose it as an ordinary BO property.

The CDS root should not contain:

Reservation.client as Client

Why?

Because client handling is technical data separation managed by the ABAP platform.

This is also a CDS View Entity language rule: the technical client field cannot appear in its select list. Client filtering is implicit. See SAP: CDS View Entity select list.

Consumers should think in terms of:

Reservation

not:

Reservation + SAP client number

---

18. Expose the UUID as the CDS key

Use:

key Reservation.uuid as Uuid,

The table key contains:

client + uuid

but the business-object entity key exposed to normal consumers is:

Uuid

The current client is handled implicitly.

---

19. Expose the business fields

Add:

Reservation.reservation_no   as ReservationNo,
Reservation.customer_name    as CustomerName,
Reservation.customer_email   as CustomerEmail,
Reservation.workshop_code    as WorkshopCode,
Reservation.reservation_date as ReservationDate,
Reservation.status           as Status,

These aliases create a cleaner CDS vocabulary.

Compare:

Database field        CDS element
reservation_no   →    ReservationNo
customer_name    →    CustomerName
workshop_code    →    WorkshopCode

---

20. Preserve Fee semantics

The table already expresses:

Fee
→ Currency Code

The root CDS must also make the relationship explicit.

Use:

@Semantics.amount.currencyCode: 'CurrencyCode'
Reservation.fee as Fee,

Reservation.currency_code as CurrencyCode,

A monetary value without its currency context is incomplete business information.

---

21. Expose Notes

Add:

Reservation.notes as Notes,

At this stage it is simply another business property.

Later behavior can control how fields may be modified.

---

22. Administrative fields need semantic meaning

The persistence contains five RAP-ready fields:

local_created_by
local_created_at
local_last_changed_by
local_last_changed_at
last_changed_at

Today we expose them with semantic annotations.

These annotations tell RAP/framework consumers what each field represents.

---

23. Created-by field

Use:

@Semantics.user.createdBy: true
Reservation.local_created_by as LocalCreatedBy,

This field represents the user that created the instance.

---

24. Created-at field

Use:

@Semantics.systemDateTime.createdAt: true
Reservation.local_created_at as LocalCreatedAt,

This field represents the creation timestamp.

---

25. Local last-changed user

Use:

@Semantics.user.localInstanceLastChangedBy: true
Reservation.local_last_changed_by as LocalLastChangedBy,

This identifies the user responsible for the latest local-instance change.

---

26. Local last-changed timestamp

Use:

@Semantics.systemDateTime.localInstanceLastChangedAt: true
Reservation.local_last_changed_at as LocalLastChangedAt,

This field becomes especially important later.

It can be used as the entity's:

ETag

for optimistic concurrency control.

We will configure that in Lesson 11.

---

27. Total last-changed timestamp

Use:

@Semantics.systemDateTime.lastChangedAt: true
Reservation.last_changed_at as LastChangedAt

This represents the last change to the instance or its compositional subtree. Our current root has no children, so the distinction from the local timestamp becomes useful later.

It becomes especially relevant in more advanced scenarios such as draft and composed Business Objects.

Today, recognize its semantic role.

---

28. Complete root CDS

Your final source should look like:

@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Reservation'

define root view entity ZR_Reservation_###
  as select from zresv_### as Reservation
{
  key Reservation.uuid                  as Uuid,

      Reservation.reservation_no        as ReservationNo,
      Reservation.customer_name         as CustomerName,
      Reservation.customer_email        as CustomerEmail,
      Reservation.workshop_code         as WorkshopCode,
      Reservation.reservation_date      as ReservationDate,
      Reservation.status                as Status,

      @Semantics.amount.currencyCode: 'CurrencyCode'
      Reservation.fee                   as Fee,

      Reservation.currency_code         as CurrencyCode,
      Reservation.notes                 as Notes,

      @Semantics.user.createdBy: true
      Reservation.local_created_by      as LocalCreatedBy,

      @Semantics.systemDateTime.createdAt: true
      Reservation.local_created_at      as LocalCreatedAt,

      @Semantics.user.localInstanceLastChangedBy: true
      Reservation.local_last_changed_by as LocalLastChangedBy,

      @Semantics.systemDateTime.localInstanceLastChangedAt: true
      Reservation.local_last_changed_at as LocalLastChangedAt,

      @Semantics.systemDateTime.lastChangedAt: true
      Reservation.last_changed_at       as LastChangedAt
}

Replace every ###.

---

29. Syntax check and activate

Use:

Ctrl+F2

for syntax check.

Then:

Ctrl+F3

to activate.

If activation fails, inspect the exact ADT error before changing code.

---

30. Preview the root entity

Run CDS Data Preview:

F8

Depending on whether you cleaned up Lesson 9 data, the result may be:

0 rows

That is fine.

Use Data Preview to inspect:

fields
aliases
key
shape

Inspect the CDS source and syntax-check results separately for amount/currency and administrative semantics. Data Preview does not prove that RAP maintains those fields or supports write operations.

---

31. Compare table and root CDS

Persistence:

ZRESV_###

contains technical storage names such as:

uuid
reservation_no
customer_name

The root entity exposes business-facing CDS names such as:

Uuid
ReservationNo
CustomerName

Architecture:

Persistence Table
      ↓
RAP Root CDS

The root entity is the business-object data model.

The table is physical persistence.

---

32. Why keep the UUID?

The UUID remains the technical entity identity.

It gives the future BO:

stable technical key
consumer-independent identity
managed-numbering potential

The human-readable:

ReservationNo

remains a business property.

Do not replace one with the other.

---

33. What does the root entity allow us to do now?

By itself, the CDS root can be:

activated
previewed
queried
used as the structural basis for RAP behavior

But we have not yet declared:

create
update
delete
locking
ETag
authorization behavior
managed UUID numbering
field characteristics
persistence mapping

So the transactional contract is still missing.

---

34. Why not put behavior into CDS annotations?

RAP deliberately separates:

data structure

from:

transactional behavior

The root CDS says:

what the entity looks like

The Behavior Definition will say:

what can happen to it

This separation is central to RAP.

---

35. Managed vs unmanaged RAP — concept only

When we create the Behavior Definition, RAP asks how much generic transactional work the framework should provide.

Two major implementation types are:

managed
unmanaged

Today, understand the difference conceptually.

Do not create the Behavior Definition yet.

---

36. Managed RAP

In a managed RAP Business Object, the RAP provider handles standard transactional mechanics for normal persistence scenarios.

Depending on the model, managed RAP can provide standardized handling for:

transactional buffer
create
update
delete
save processing
locking
managed numbering
administrative fields

You still define the business contract.

You can still implement custom business logic.

---

37. Unmanaged RAP

In unmanaged RAP, the application implements much more of the transactional behavior itself.

Typical reasons include:

existing save logic
legacy APIs
special persistence
existing business frameworks
brownfield scenarios

Unmanaged does not mean:

better
more modern
more advanced

It means the implementation responsibility is different.

---

38. Which one fits our Reservation scenario?

Our Reservation persistence is:

new
simple
owned by us
normal database persistence
UUID-based
prepared for RAP

So our first implementation will use:

managed RAP

This is the natural greenfield model for this course scenario.

---

39. Do not confuse managed RAP with managed database tables

The word:

managed

describes the RAP behavior implementation model.

It does not mean:

the database table is a different kind of table

Our persistence remains:

ZRESV_###

The RAP managed provider will later work with it through the BO behavior contract.

---

40. Why we stop before the Behavior Definition

It would be possible to create the root CDS and Behavior Definition in the same lesson.

We deliberately do not.

Today's mental model is:

Persistence
    ↓
Root CDS

You should be able to explain this layer cleanly before adding:

Behavior Definition
Behavior Pool
locking
ETag
mapping
numbering

Lesson 11 adds those concepts.

---

41. Architecture at the end of Lesson 10

You now have:

ZRESV_###
    ↓
ZR_RESERVATION_###

Interpret it as:

physical persistence
    ↓
RAP BO data model / root structure

You do not yet have:

complete transactional behavior

---

42. Preview of Lesson 11

Lesson 11 will add:

ZR_RESERVATION_###
        ↓
Managed Behavior Definition
        ↓
Behavior Pool

The Behavior Definition will introduce concepts such as:

managed
strict ( 2 )
persistent table
alias
create
update
delete
managed UUID numbering
readonly fields
mapping
lock master
authorization baseline
etag master

Do not implement them yet.

---

43. Knowledge check

1. What is the difference between persistence and a RAP root entity?

2. What are the two major parts of a RAP Business Object?

3. What does root describe?

4. Can a one-node BO still have a root?

5. Why is client not exposed as an ordinary BO field?

6. Why is Uuid the CDS key?

7. Why does Fee need Currency Code semantics?

8. What is the role of LocalLastChangedAt?

9. What is the high-level difference between managed and unmanaged RAP?

10. Why are we not creating the Behavior Definition today?

---

44. Teacher-led completion checklist

• ZRESV_### exists from Lesson 8.
• Student can distinguish table persistence from a BO data model.
• ZR_RESERVATION_### exists.
• It uses define root view entity.
• Uuid is the CDS key.
• client is not exposed.
• Business fields use clear aliases.
• Fee has amount/currency semantics.
• Five administrative fields are exposed.
• Administrative semantics are present.
• Root CDS activates.
• CDS Data Preview opens.
• No Behavior Definition has been created yet.
• Student can explain managed vs unmanaged conceptually.
• Student can explain why managed RAP fits this scenario.

---

45. End-of-day mental model

Before leaving Lesson 10, you should be able to draw:

ZRESV_###
    ↓
ZR_RESERVATION_###

and explain:

ZRESV_###
=
stored Reservation state

ZR_RESERVATION_###
=
RAP Business Object root data model

Then add one blank box underneath:

ZRESV_###
    ↓
ZR_RESERVATION_###
    ↓
[ Behavior Definition ]

That blank box is Lesson 11.