ABAP Cloud Course

Appearance

Lesson 10 Companion — RAP Business Object Structure ​

This companion supports:

text
Lesson 10 — RAP Foundations: Business Object Structure

Lesson 10 intentionally teaches the structural half of the first RAP Business Object.

The transactional behavior contract is deferred to Lesson 11.

1. Core lesson boundary ​

The most important boundary is:

text
Lesson 10
Persistence → Root CDS

Lesson 11
Root CDS → Behavior Definition → Behavior Pool

Do not collapse the two days.

Students should finish Lesson 10 understanding what a root entity is before learning BDEF syntax.

2. Current SAP model of a Business Object ​

A RAP Business Object combines:

text
CDS data model
+
Behavior Definition

The CDS model describes structure.

The Behavior Definition describes transactional behavior.

A BO may consist of one entity or a composition hierarchy.

The hierarchy always has one root.

3. Root entity reference ​

In CDS:

abap
define root view entity ...

marks the entity as the root of a business-object hierarchy.

A root:

text
has no parent
may have composition children
may also be a leaf

Therefore a single-node BO is valid:

text
Reservation

with Reservation as its root.

4. Root vs key ​

These are independent concepts.

text
Root
=
role in BO hierarchy

Key
=
identity of an entity instance

For this lesson:

text
Root entity = Reservation
Key field   = Uuid

5. Persistence reference ​

Lesson 8 created:

abap
@EndUserText.label : 'Workshop Reservations'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #A
@AbapCatalog.dataMaintenance : #RESTRICTED
define table zresv_### {

  key client                : abap.clnt not null;
  key uuid                  : sysuuid_x16 not null;

  reservation_no            : abap.numc(8) not null;
  customer_name             : abap.char(60) not null;
  customer_email            : abap.char(100);
  workshop_code             : abap.char(10) not null;
  reservation_date          : abap.dats not null;
  status                    : zde_rstat_### not null;

  @Semantics.amount.currencyCode : 'zresv_###.currency_code'
  fee                       : abap.curr(10,2);

  currency_code             : abap.cuky;
  notes                     : abap.char(255);

  local_created_by          : abp_creation_user;
  local_created_at          : abp_creation_tstmpl;
  local_last_changed_by     : abp_locinst_lastchange_user;
  local_last_changed_at     : abp_locinst_lastchange_tstmpl;
  last_changed_at           : abp_lastchange_tstmpl;

}

The root CDS is built directly over this persistence.

6. Complete root CDS reference ​

abap
@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
}

7. Why @AccessControl.authorizationCheck: #NOT_REQUIRED? ​

For this controlled training stage:

text
CDS DCL authorization

is intentionally not introduced yet.

#NOT_REQUIRED makes a DCL role optional and suppresses the missing-role warning. If a DCL role exists for the entity, its access rules still apply; the annotation does not disable that role. See SAP: AccessControl annotations.

It does not mean:

text
authorization is unimportant

Authorization is taught later.

Do not present #NOT_REQUIRED as a production-security recommendation.

8. Why omit client? ​

The table is client-dependent.

The physical key is:

text
client + uuid

CDS View Entities handle the client implicitly and prohibit the technical client field in the select list. This is a language restriction as well as a clean business model. See SAP: CDS View Entity select list.

The business object identity is therefore modeled as:

text
Uuid

9. Why preserve the UUID? ​

UUID is suitable for the future RAP entity key because:

text
it is stable
it is technical
it does not depend on business numbering
it supports framework-managed numbering later

The human-facing identifier remains:

text
ReservationNo

10. Why not expose the database field names unchanged? ​

You could technically expose storage-style names.

But this course uses the CDS entity as a business-facing model.

So:

text
reservation_no

becomes:

text
ReservationNo

This makes the distinction between:

text
persistence model

and:

text
business-object data model

visible.

11. Amount/currency reference ​

This annotation:

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

connects:

text
Fee

to:

text
CurrencyCode

The reference uses the CDS element name:

text
CurrencyCode

not the persistence field name:

text
currency_code

12. Administrative semantics reference ​

Created by ​

abap
@Semantics.user.createdBy: true

Created at ​

abap
@Semantics.systemDateTime.createdAt: true

Local instance last changed by ​

abap
@Semantics.user.localInstanceLastChangedBy: true

Local instance last changed at ​

abap
@Semantics.systemDateTime.localInstanceLastChangedAt: true

Last changed at ​

abap
@Semantics.systemDateTime.lastChangedAt: true

These semantics are important because the managed RAP framework can recognize administrative-field purposes. The SAP RAP reuse data elements reference explains their types and automatic maintenance in managed BOs.

13. LocalLastChangedAt vs LastChangedAt ​

These fields sound similar but serve different future purposes.

LocalLastChangedAt ​

Represents the timestamp of a local entity-instance change.

It is commonly used as:

text
ETag field

for optimistic concurrency control.

Lesson 11 will declare:

text
etag master LocalLastChangedAt

LastChangedAt ​

Represents the last change to this instance or its compositional subtree. LocalLastChangedAt tracks the instance itself, without changes confined to child instances.

It becomes particularly important for:

text
total ETag
draft
composition-aware change tracking

Do not overload Lesson 10 with draft details.

Students should simply know the distinction exists.

14. Why direct SQL left admin fields initial ​

Lesson 9 intentionally demonstrated direct persistence writes.

Those writes did not run RAP managed behavior.

Therefore fields such as:

text
LocalCreatedBy
LocalCreatedAt
LocalLastChangedBy
LocalLastChangedAt
LastChangedAt

could remain initial.

This is expected.

After managed behavior is introduced, the framework can maintain appropriate administrative fields when configured correctly.

15. Root CDS is not the persistence ​

A common misunderstanding:

text
ZR_RESERVATION_###

is not a replacement table.

It is a CDS entity over:

text
ZRESV_###

So:

text
ZRESV_###
=
stored state

ZR_RESERVATION_###
=
modeled entity structure

16. Root CDS is not yet a service ​

Another common misunderstanding:

text
root entity

does not mean:

text
OData endpoint

There is currently no:

text
Service Definition
Service Binding
OData exposure
Fiori UI

Those belong later.

17. Root CDS alone does not define write permissions ​

The root entity may be queryable as CDS.

But it does not yet say:

text
create allowed
update allowed
delete allowed

Those operations are declared in the Behavior Definition.

This is why Lesson 10 should not describe the result as a complete transactional BO contract.

18. Managed RAP reference ​

Current RAP provides a managed implementation model in which the framework handles standardized transactional mechanics.

For greenfield persistence, managed RAP is normally the first choice.

The future architecture is:

text
Consumer
   ↓
RAP transactional contract
   ↓
Managed provider
   ↓
Persistence

Managed does not remove the need for:

text
business rules
validations
actions
authorization design
field control

It standardizes much of the technical transaction handling.

19. Unmanaged RAP reference ​

Unmanaged RAP puts more responsibility into application implementation.

Typical scenarios include:

text
legacy save logic
BAPIs
existing APIs
non-standard persistence
brownfield frameworks

Students only need conceptual recognition in Lesson 10.

The hands-on sequence in this course uses managed RAP.

20. Why managed fits Reservation ​

Reservation is intentionally a textbook managed scenario:

text
new persistence
simple single-node entity
normal database table
UUID technical key
RAP admin fields already present
no legacy save API

So the later BDEF will be:

text
managed

not unmanaged.

21. What strict ( 2 ) is doing in future examples ​

Lesson 10 does not create a BDEF.

However, students may see:

abap
strict ( 2 );

in SAP examples.

Current SAP guidance uses the strictest current syntax mode for new BDEFs.

Lesson 11 will explain it.

Do not make students memorize it today.

22. Why no Behavior Pool today? ​

The Behavior Pool belongs to the behavior layer.

Today we are only creating:

text
data structure

A Behavior Pool without the corresponding behavior lesson would add terminology without a useful mental model.

23. Common error — normal View Entity instead of root ​

Wrong for this exercise:

abap
define view entity ZR_Reservation_###

Required:

abap
define root view entity ZR_Reservation_###

The root keyword is the architectural point of the lesson.

24. Common error — expose client ​

Avoid:

abap
key Reservation.client as Client,
key Reservation.uuid   as Uuid,

For this RAP root, expose:

abap
key Reservation.uuid as Uuid,

The platform handles client-dependent data access. The first example fails the CDS View Entity syntax check because it exposes the technical client field.

25. Common error — omit CDS key ​

Wrong:

abap
Reservation.uuid as Uuid,

Required:

abap
key Reservation.uuid as Uuid,

The entity must have its instance identity.

26. Common error — wrong currency reference ​

Incorrect:

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

if the CDS element is named:

text
CurrencyCode

Correct:

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

The annotation references the CDS element.

27. Common error — old CDS syntax ​

Do not add:

text
@AbapCatalog.sqlViewName

to a CDS View Entity.

The course uses:

abap
define root view entity

28. Common error — trying to create the BDEF early ​

If students immediately create:

text
New Behavior Definition

they will encounter new syntax such as:

text
managed
strict ( 2 )
persistent table
lock master
authorization master

before the data-model layer is understood.

Have them stop and return to the root CDS.

29. Data Preview shows zero rows ​

This is not a defect if Lesson 9 or the checkpoint cleaned up its test data.

Lesson 10 is primarily validating:

text
shape
activation
semantics
key
aliases

not row count.

Check semantics in the source and with the syntax check. An empty Data Preview can confirm the queryable field shape, but it cannot demonstrate administrative-field maintenance.

30. Direct SQL class still exists ​

ZCL_RESV_SQL_### does not need to be deleted.

It remains useful evidence of what students learned:

text
low-level persistence mechanics

But after the RAP BO becomes transactional, it will no longer represent the normal consumer architecture.

31. Instructor explanation — table vs root vs behavior ​

A useful three-line board diagram:

text
ZRESV_###
=
where state is stored

ZR_RESERVATION_###
=
what the business entity looks like

Behavior Definition
=
what the business entity can do

This is the core Lesson 10 model.

32. Instructor explanation — why behavior is separate ​

Ask:

If the database table contains a Status field, does the table know that only certain users may change it?

No.

Ask:

Does the table know that a create operation should generate a UUID?

No.

Ask:

Does the root CDS alone say update is permitted?

No.

Those belong to the behavior contract.

33. Instructor explanation — root as future composition anchor ​

Today:

text
Reservation

Later composition examples may look like:

text
Order
 └─ Item

The root is where the business-object hierarchy begins.

Students should understand root before compositions are introduced.

34. Certification relevance ​

Current ABAP Cloud backend work expects practical understanding of RAP structures and behavior.

Students should be able to recognize and build:

text
root CDS entity
behavior definition
managed RAP model
persistence relationship

Lesson 10 isolates the first of those practical steps.

35. Reference answers to knowledge check ​

1. Persistence vs root entity ​

Persistence stores rows.

The root CDS models the business-facing entity structure over that persistence.

2. Two major BO parts ​

text
CDS data model
Behavior Definition

3. What does root describe? ​

The entity's position at the top of the BO hierarchy.

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

Yes.

It is both root and leaf.

5. Why omit client? ​

Client handling is implicit in CDS View Entities, and their select lists must not expose the technical client field.

6. Why UUID key? ​

It provides stable technical identity independent of business numbering.

7. Why Fee/Currency semantics? ​

An amount needs its currency context.

8. Role of LocalLastChangedAt ​

It represents local change timing and can be used as an ETag field.

9. Managed vs unmanaged ​

Managed delegates standardized transactional mechanics to RAP; unmanaged requires more application implementation.

10. Why no BDEF today? ​

To learn the BO data-model layer before adding transactional behavior concepts.

36. Final instructor validation ​

Before moving to Lesson 11, verify:

text
ZR_RESERVATION_### activates
Uuid is key
client is absent
Fee points to CurrencyCode
all five admin fields exist
admin semantics are correct
student knows root ≠ key
student knows CDS structure ≠ behavior
student can explain why managed fits this scenario

If those are stable, Lesson 11 can focus entirely on behavior.