Lesson 11 Companion — Managed RAP Behavior

This companion supports:

Lesson 11 — Managed RAP Behavior

Lesson 10 created the BO structure.

Lesson 11 adds the transactional behavior contract.

Lesson 12 will consume that contract with EML.

---

1. Lesson boundary

Keep the three days distinct:

Lesson 10
Root CDS / BO structure

Lesson 11
Managed Behavior Definition

Lesson 12
EML / transactional buffer

Do not introduce EML into Lesson 11 merely to prove that CRUD works.

The point of Lesson 11 is to understand and build the provider-side contract first.

---

2. What a Behavior Definition is

A Behavior Definition is a RAP repository object written in Behavior Definition Language (BDL).

It describes behavior for a CDS business-object data model.

For this course, it connects:

ZR_RESERVATION_###
        ↓
managed behavior contract
        ↓
ZRESV_###

---

3. Why a BDEF refers to the root entity

A Behavior Definition belongs to one root data model and covers the entities in that BO composition tree.

For the current single-node BO:

Reservation

there is only one entity.

So the BDEF is defined for:

ZR_RESERVATION_###

---

4. Managed provider responsibilities

For a normal managed persistent BO, the RAP managed runtime can provide generic handling for standard operations and technical transaction concerns.

Examples include:

create
update
delete
transactional buffer
save processing
locking
ETag handling
managed UUID numbering
administrative field maintenance

This is why managed RAP is appropriate for the course's greenfield persistence.

---

5. Managed does not remove business logic

Managed RAP does not mean the application has no code.

Later lessons add application-specific behavior such as:

validations
determinations
actions
dynamic feature control
authorization
messages

Managed RAP removes much of the repetitive technical CRUD plumbing.

---

6. Complete Reservation BDEF reference

managed implementation in class zbp_r_resv_### unique;
strict ( 2 );

define behavior for ZR_Reservation_### alias Reservation
persistent table zresv_###
lock master
authorization master ( none )
etag master LocalLastChangedAt
{
  create;
  update;
  delete;

  field ( numbering : managed, readonly ) Uuid;

  field ( readonly )
    LocalCreatedBy,
    LocalCreatedAt,
    LocalLastChangedBy,
    LocalLastChangedAt,
    LastChangedAt;

  mapping for zresv_###
  {
    Uuid               = uuid;
    ReservationNo      = reservation_no;
    CustomerName       = customer_name;
    CustomerEmail      = customer_email;
    WorkshopCode       = workshop_code;
    ReservationDate    = reservation_date;
    Status             = status;
    Fee                = fee;
    CurrencyCode       = currency_code;
    Notes              = notes;
    LocalCreatedBy     = local_created_by;
    LocalCreatedAt     = local_created_at;
    LocalLastChangedBy = local_last_changed_by;
    LocalLastChangedAt = local_last_changed_at;
    LastChangedAt      = last_changed_at;
  }
}

---

7. Header anatomy

Read:

managed implementation in class zbp_r_resv_### unique;

as:

managed provider
+
Behavior Pool class

Read:

strict ( 2 );

as:

current explicit RAP consistency rules

Read:

define behavior for ZR_Reservation_### alias Reservation

as:

this contract belongs to the Reservation root entity

---

8. persistent table

persistent table zresv_###

identifies the table used for the active persistent state.

It does not replace the CDS root.

Layering remains:

BO contract
    ↓
CDS data model
    ↓
persistence

---

9. Standard operations

The standard modification operations are declared as:

create;
update;
delete;

In managed RAP, those declarations allow the generic managed provider to handle standard persistence behavior.

No manual SQL implementation is required for today's scenario.

---

10. Why no read;

There is no parallel simple declaration:

read;

beside standard CUD operations.

Consumers read RAP BO entities through EML read operations or service consumption.

Lesson 12 introduces:

READ ENTITIES

---

11. Managed UUID numbering

Use:

field ( numbering : managed, readonly ) Uuid;

The two characteristics work together.

numbering : managed

The RAP managed runtime generates the UUID value.

readonly

A normal consumer cannot provide or modify that technical key.

This is strict internal numbering.

---

12. Why SYSUUID_X16 mattered

The persistence was designed with:

uuid : SYSUUID_X16

before RAP was introduced.

That design decision now enables managed UUID numbering cleanly.

---

13. Administrative fields

The course persistence includes:

LocalCreatedBy
LocalCreatedAt
LocalLastChangedBy
LocalLastChangedAt
LastChangedAt

The root CDS gives them semantic annotations.

The BDEF marks them read-only:

field ( readonly )
  LocalCreatedBy,
  LocalCreatedAt,
  LocalLastChangedBy,
  LocalLastChangedAt,
  LastChangedAt;

In a managed scenario, the corresponding semantics allow RAP to maintain the relevant administrative values automatically.

---

14. Why the fields are read-only

Read-only protects technical lifecycle state from normal consumer input.

For example, an external caller should not be able to claim:

LocalCreatedBy = ADMIN
LocalCreatedAt = 2020...

These values belong to framework/application lifecycle management.

---

15. Locking reference

Use:

lock master

on the root.

RAP locks are used for pessimistic concurrency control.

For future compositions:

Root
  └─ Child

the root is normally the lock master and child nodes are lock-dependent.

The current BO has only the root.

---

16. ETag reference

Use:

etag master LocalLastChangedAt

RAP ETags provide optimistic concurrency control for OData consumers: the request supplies its version, which is compared with the current one. See SAP: Optimistic Concurrency Control.

The ETag field must change when the entity is created or modified for stale-version checks to be meaningful.

The managed administrative timestamp is therefore a natural ETag field.

Direct EML in Lesson 12 can demonstrate CRUD and timestamp maintenance. It does not test an OData stale-version rejection.

---

17. Lock vs ETag reference

Concept	Role
Lock	Pessimistic concurrency control during modification processing
ETag	Optimistic detection of stale versions

Do not describe ETags as database locks.

Do not describe locks as version tokens.

---

18. Why LocalLastChangedAt and not LastChangedAt?

For the current active single-node entity:

LocalLastChangedAt

is the local entity ETag.

The separate:

LastChangedAt

is retained because it becomes relevant for later total-ETag/draft and composition-aware scenarios.

Draft is not part of Lesson 11.

---

19. Authorization baseline

The course uses:

authorization master ( none )

for this controlled stage.

This is a deliberate teaching baseline, not a recommendation to ship production BOs without authorization design.

Later lessons introduce RAP authorization and CDS access control.

---

20. Persistence mapping

The BDEF mapping connects business-object field names with persistence field names.

Example:

ReservationNo = reservation_no;

Read it as:

BO field
=
persistence field

---

21. Why explicit mapping is ideal for the first BO

The course intentionally uses:

CamelCase BO names
snake_case persistence names

Examples:

CustomerEmail       ↔ customer_email
LocalCreatedAt      ↔ local_created_at
LocalLastChangedAt  ↔ local_last_changed_at

Explicit mapping makes the architecture easy to audit.

---

22. Mapping must be complete

Every persistent field exposed in the root model and needed by managed persistence should be mapped consistently.

A missing or wrong target can prevent activation or produce an incorrect persistence relationship.

Students should compare:

root CDS
BDEF mapping
persistence table

field by field.

---

23. Behavior Pool reference

The Behavior Pool is the ABAP behavior implementation class.

ADT creates it from the BDEF with Quick Fix.

Use:

Ctrl+1

on the missing implementation-class reference.

The generated class contains the special addition:

FOR BEHAVIOR OF

which distinguishes it from an ordinary application class.

---

24. Why the Behavior Pool may be nearly empty

Today's BDEF declares only standard managed behavior.

The framework supplies the generic CRUD implementation.

Therefore you do not need to implement custom handler methods simply to make:

create
update
delete

work.

Later BDEF features generate or require handler methods.

---

25. Future handler logic

The Behavior Pool becomes visibly important when the BDEF declares behavior such as:

validation
determination
action
instance feature control
authorization

ADT Quick Fix can generate required method declarations for many of those features.

---

26. Transactional buffer preview

Managed RAP does not mean every consumer modification is equivalent to an immediate SQL statement.

The high-level model is:

consumer request
      ↓
RAP interaction phase
      ↓
transactional buffer
      ↓
save sequence
      ↓
persistence

Lesson 12 makes this visible with EML.

---

27. Why direct SQL becomes the wrong normal API

Direct modification of a RAP-owned table can bypass the BO contract.

That can bypass later features such as:

validations
determinations
authorization
actions
feature control
messages
locking expectations
ETag handling
save sequencing

Application consumers should move to:

EML

or later:

business service / OData

---

28. Verification without EML

Lesson 11 deliberately stops before runtime BO consumption.

Students can still verify the provider model with:

Ctrl+F2   BDEF syntax check
Ctrl+F3   activation
Ctrl+1    Behavior Pool Quick Fix
F3        navigation
F8        root CDS Data Preview

They can also inspect the Behavior Pool and confirm FOR BEHAVIOR OF.

---

29. What F8 can and cannot prove

F8 can prove

root CDS activates
fields are queryable
existing persistence data is visible

F8 cannot prove

managed create runtime behavior
managed UUID generation
managed update/delete behavior
transactional buffering
MAPPED / FAILED / REPORTED responses

Those need a BO consumer.

Lesson 12 supplies that consumer with EML.

---

30. Common error — BDEF created for the wrong entity

The BDEF must be tied to:

ZR_RESERVATION_###

not directly to:

ZRESV_###

The database table is persistence, not the BO data model.

---

31. Common error — unmanaged selected accidentally

Wrong for this scenario:

Unmanaged

Use:

Managed

Unmanaged would introduce implementation responsibility not needed for this greenfield table.

---

32. Common error — omit strict ( 2 )

The course uses:

strict ( 2 );

Students should keep the current strict-mode baseline rather than copying older BDEF examples without strict mode.

---

33. Common error — consumer supplies UUID

If the key is framework-numbered, do not design normal consumer input around a caller-provided UUID.

The BDEF says:

field ( numbering : managed, readonly ) Uuid;

Lesson 12 will observe the generated key through the EML response.

---

34. Common error — admin fields editable

Do not leave the administrative fields as normal editable consumer data.

Mark them:

readonly

The framework/application lifecycle owns their values.

---

35. Common error — wrong mapping direction

Wrong mental model:

persistence = BO

Correct mental model:

BO field = persistence field

Example:

CustomerEmail = customer_email;

---

36. Common error — wrong mapping target

If you write:

CustomerEmail = customer_mail;

but the table contains:

customer_email

ADT should report the invalid persistence relationship.

Use the actual table definition as the source of truth.

---

37. Common error — wrong ETag field

Do not choose an arbitrary date/time field.

The course uses:

LocalLastChangedAt

because its semantic role is the local instance last-change timestamp.

A syntactically accepted field is not automatically a suitable version field. For example, LocalCreatedAt stays unchanged after creation and cannot identify later versions.

---

38. Common error — custom SQL inside the Behavior Pool

Do not implement manual CRUD SQL just because a Behavior Pool exists.

For the standard managed case, the framework already supplies CRUD persistence mechanics.

Custom SQL would defeat the purpose of this lesson and could conflict with RAP transaction handling.

---

39. Common error — expecting Data Preview to show behavior

A BDEF is not a UI.

A Behavior Pool is not a UI.

F8 on the root shows data, not create/update/delete controls.

The behavior needs a consumer.

---

40. Practice model

Lesson 10 Practice created:

ZISSUE_###
    ↓
ZR_ISSUE_###

Lesson 11 Practice adds:

ZISSUE_###
    ↓
ZR_ISSUE_###
    ↓
Managed Behavior Definition
    ↓
ZBP_R_ISSUE_###

---

41. Support Issue BDEF reference

Use this only after attempting the practice independently.

managed implementation in class zbp_r_issue_### unique;
strict ( 2 );

define behavior for ZR_Issue_### alias Issue
persistent table zissue_###
lock master
authorization master ( none )
etag master LocalLastChangedAt
{
  create;
  update;
  delete;

  field ( numbering : managed, readonly ) Uuid;

  field ( readonly )
    LocalCreatedBy,
    LocalCreatedAt,
    LocalLastChangedBy,
    LocalLastChangedAt,
    LastChangedAt;

  mapping for zissue_###
  {
    Uuid               = uuid;
    IssueNo            = issue_no;
    Title              = title;
    Description        = description;
    RequesterEmail     = requester_email;
    Priority           = priority;
    Status             = status;
    ReportedOn         = reported_on;
    EstimatedCost      = estimated_cost;
    CurrencyCode       = currency_code;
    LocalCreatedBy     = local_created_by;
    LocalCreatedAt     = local_created_at;
    LocalLastChangedBy = local_last_changed_by;
    LocalLastChangedAt = local_last_changed_at;
    LastChangedAt      = last_changed_at;
  }
}

---

42. Why Issue also fits managed RAP

The Issue persistence is also:

application-owned
normal custom persistence
UUID-based
RAP-ready
not a wrapper around an existing legacy save API

So the same managed implementation decision is justified.

---

43. Expected practice Behavior Pool

The practice Behavior Pool is:

ZBP_R_ISSUE_###

Create it with:

Ctrl+1

from the BDEF implementation-class reference.

Do not manually create an ordinary class and then try to retrofit it.

---

44. Instructor check — read the BDEF aloud

Ask students to translate:

persistent table zresv_###

into English.

Then:

field ( numbering : managed, readonly ) Uuid;

Then:

etag master LocalLastChangedAt

If they can explain those lines without reading notes, the mental model is forming.

---

45. Instructor check — navigate instead of memorize

Have students use ADT navigation between:

ZR_RESERVATION_###
Behavior Definition
ZRESV_###
ZBP_R_RESV_###

A practical system-based assessment rewards repository navigation and repair skills, not only syntax recall.

---

46. Instructor check — force one safe error

A useful repair exercise is to misspell one mapping target temporarily.

Then:

Ctrl+F2
read the ADT message
navigate to the table
repair the target
activate

This is more valuable than asking students to memorize the mapping block.

---

47. Reference answers to Lesson 11 knowledge check

What does the BDEF describe?

The BO transactional behavior contract.

Why managed?

The application owns simple greenfield persistence and does not need to delegate saves to legacy logic.

What does persistent table do?

It identifies the active persistence used by managed behavior.

What is the alias?

The concise RAP entity name used in the behavior model and later EML.

What do create, update, and delete do?

They enable those standard BO modification operations.

Why no read;?

BO reads are consumed through RAP read APIs rather than enabled by a parallel standard-operation declaration.

What does managed numbering do?

The RAP runtime supplies the UUID key internally.

Why readonly UUID?

The consumer must not provide or alter a framework-managed technical key.

Why readonly admin fields?

They are lifecycle metadata, not ordinary business input.

What is lock master?

The root controls the BO's pessimistic locking behavior.

What is etag master?

It identifies the version field used for optimistic concurrency control.

Why mapping?

The BO/CDS names differ from the persistence field names.

What is the Behavior Pool?

The special ABAP implementation class associated with the RAP behavior.

Why little custom code today?

The managed provider implements the standard CRUD mechanics generically.

---

48. SAP references

• Defining Elementary Behavior covers managed standard operations, locking, mapping, and the explicit training authorization baseline.
• Strict Mode — Implementation Requirements explains the checks enabled by strict mode.
• Internal Early Numbering explains managed UUID generation and its read-only key requirement.
• ETag Definition and ETag Implementation explain the version field and its maintenance.
• Quick Fixes for Creating Behavior Implementations explains generating the Behavior Pool and handler methods.

Use SAP Help as the authority when ADT behavior differs by release.

---

49. Final instructor validation

Before Lesson 12, verify:

Reservation BDEF activates
Issue BDEF activates
both use managed behavior
both use strict ( 2 )
UUID keys use managed numbering
administrative fields are read-only
lock master exists
LocalLastChangedAt is ETag master
mapping is complete
Behavior Pools exist
students understand F8 does not test CRUD
students know EML is next

If those points are stable, the class is ready to work with the RAP transactional buffer.