Lesson 11 — Managed RAP Behavior

In Lesson 10, you created the structure of your first RAP Business Object:

ZRESV_###
    ↓
ZR_RESERVATION_###

The root CDS tells RAP what a Reservation looks like.

Today you add the missing transactional contract:

create
update
delete
managed UUID numbering
locking
ETag handling
persistence mapping

By the end of the lesson, the architecture becomes:

ZRESV_###
    ↓
ZR_RESERVATION_###
    ↓
Managed Behavior Definition
    ↓
ZBP_R_RESV_###

You will still not write EML today. Lesson 12 will consume the BO and prove the behavior at runtime.

---

Lesson information

Teacher-led time	About 3 hours
Self-practice time	About 3 hours
Environment	SAP BTP ABAP Trial
Prerequisite	Lesson 10
Persistence	ZRESV_###
Root CDS	ZR_RESERVATION_###
Behavior Pool	ZBP_R_RESV_###
Implementation type	Managed RAP
Main outcome	Transactional behavior contract
EML today?	No — Lesson 12

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

---

Learning objectives

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

• explain what a RAP Behavior Definition is;
• explain why structure and behavior are separate;
• create a Behavior Definition for a root CDS entity;
• explain why this scenario uses managed RAP;
• use strict ( 2 );
• define an entity alias;
• connect the BO to its persistent table;
• enable standard create, update, and delete;
• explain why there is no matching simple read; declaration;
• configure managed UUID numbering;
• protect technical lifecycle fields as read-only;
• configure lock master;
• explain pessimistic locking;
• configure etag master;
• explain optimistic concurrency control;
• map CDS element names to persistence fields;
• create a Behavior Pool with ADT Quick Fix;
• explain why standard managed CRUD needs almost no custom code;
• verify that the RAP artifacts are correctly connected;
• explain why runtime CRUD testing is deferred to EML in Lesson 12.

---

1. Start from the Lesson 10 architecture

You currently have:

ZRESV_###
    ↓
ZR_RESERVATION_###

Interpret this as:

Persistence
    ↓
BO data model

The CDS root defines structure. It does not yet define the transactional operations that consumers may request.

---

2. What is a Behavior Definition?

A RAP Behavior Definition is an ABAP Repository object that describes the behavior contract of a RAP Business Object.

The root CDS answers:

What does a Reservation look like?

The Behavior Definition answers:

What may happen to a Reservation, and how is that behavior technically managed?

Examples:

Can it be created?
Can it be changed?
Can it be deleted?
Who manages the UUID?
Which fields are read-only?
Which table stores the active state?
How is locking handled?
Which field is used as an ETag?
How do BO fields map to table fields?

---

3. Structure plus behavior

Your RAP model is now:

Business Object
=
Structure
+
Behavior

For this course:

Structure
=
ZR_RESERVATION_###

Behavior
=
Behavior Definition

Together they form the transactional BO contract.

---

4. What does managed RAP mean?

For this Reservation scenario, use:

managed RAP

Managed RAP means the framework provides generic transactional handling for standard persistence behavior.

For suitable managed scenarios, RAP can provide standard technical handling for:

create
update
delete
transactional buffering
save processing
locking
ETag handling
managed UUID numbering
administrative fields

You still define the contract and later implement custom business logic such as validations, determinations, actions, authorization, and feature control.

---

5. Why managed fits our Reservation

Our persistence is:

new
simple
owned by our application
stored in a normal custom table
UUID-based
prepared with RAP administrative fields
not dependent on a legacy save API

That makes it a natural managed RAP scenario.

---

6. When would unmanaged make more sense?

Unmanaged RAP is useful when transactional work must be implemented around existing logic such as:

legacy APIs
BAPIs
existing save frameworks
special persistence logic
brownfield applications

That is not today's scenario.

---

7. The architecture we are building

Today:

ZR_RESERVATION_###
       ↓
Behavior Definition
       ↓
Managed RAP Runtime
       ↓
ZRESV_###

The Behavior Pool belongs to the behavior implementation layer:

Behavior Definition
       ↓
ZBP_R_RESV_###

For today's standard managed behavior, the pool needs no custom business rule implementation.

---

8. Create the Behavior Definition

In Project Explorer, locate:

ZR_RESERVATION_###

Right-click it and choose:

New Behavior Definition

If that shortcut is not available in your ADT version, use:

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

Choose the Reservation root entity.

---

9. Choose managed behavior

When the wizard asks for the implementation type, choose:

Managed

Do not choose:

Unmanaged

Use a description such as:

Managed Behavior - Reservation

Complete the wizard.

---

10. Why the BDEF belongs to the root CDS

The Behavior Definition is defined for:

ZR_RESERVATION_###

You do not invent an unrelated BDEF name such as:

ZBD_RESERVATION_###

One BDEF is attached to the root data model and covers the BO composition tree.

---

11. Start the BDEF header

Use:

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
{
}

Replace every ###.

If ADT marks the Behavior Pool class as missing, that is expected. We will generate it shortly.

---

12. Read the header as architecture

Do not memorize the header as punctuation.

Read it as:

managed implementation
        ↓
Behavior Pool = ZBP_R_RESV_###

Behavior belongs to
        ↓
ZR_RESERVATION_###

Active persistence
        ↓
ZRESV_###

Root controls locking
        ↓
lock master

No RAP authorization implementation yet
        ↓
authorization master ( none )

Optimistic concurrency field
        ↓
LocalLastChangedAt

---

13. managed implementation in class

This line:

managed implementation in class zbp_r_resv_### unique;

states:

implementation model = managed
Behavior Pool         = ZBP_R_RESV_###

ADT can generate the missing Behavior Pool from this reference.

---

14. What is the Behavior Pool?

A Behavior Pool is a special ABAP class associated with a RAP Behavior Definition.

It is where custom behavior implementation can live.

Later examples include:

validations
determinations
actions
feature control
authorization

Today's standard managed CRUD is supplied by the RAP managed runtime.

---

15. strict ( 2 )

Use:

strict ( 2 );

for the course BDEF.

Strict mode applies current RAP consistency and syntax rules and keeps the model explicit.

---

16. Entity alias

This part:

alias Reservation

creates a concise BO entity name.

Repository object:

ZR_RESERVATION_###

RAP entity alias:

Reservation

Lesson 12 will use this BO vocabulary in EML.

---

17. persistent table

This clause:

persistent table zresv_###

connects the managed BO to the table that stores its active state.

ZR_RESERVATION_###
        ↓
Behavior Definition
        ↓
persistent table
        ↓
ZRESV_###

The CDS root remains the business-object data model. The table remains physical persistence.

---

18. lock master

Use:

lock master

This declares the root entity as the lock master.

RAP locks provide:

pessimistic concurrency control

For a single-node BO:

Reservation
=
root
=
lock master

---

19. Pessimistic concurrency in plain language

Imagine two consumers attempt to change the same Reservation.

A lock protects the current modification process from conflicting concurrent work.

Consumer A
   ↓
locks Reservation
   ↓
modifies it

Consumer B
   ↓
conflicting work is controlled
while the lock is active

You do not implement a custom lock method today. Managed RAP provides standard lock handling for this scenario.

---

20. Authorization baseline

Use:

authorization master ( none )

For this training stage, this explicitly states that no RAP authorization implementation is being added yet.

This is not a production authorization design. Authorization is taught later.

---

21. etag master

Use:

etag master LocalLastChangedAt

This declares:

LocalLastChangedAt

as the entity's ETag field.

ETags support:

optimistic concurrency control

---

22. Optimistic concurrency in plain language

Imagine:

Consumer A reads Reservation at T1

Consumer B changes Reservation
→ current version becomes T2

Consumer A later tries to change the old T1 version

When the consumers use an OData service, the change request supplies the version it read, and the service can reject Consumer A's stale version. This is the OData ETag check.

Lesson 12's direct EML calls will test transactional behavior, but they do not perform this OData stale-version check.

---

23. Lock vs ETag

Do not treat them as the same thing.

Lock

pessimistic concurrency

Protects modification processing through locking.

ETag

optimistic concurrency

Detects whether a consumer is attempting to modify a stale version.

---

24. Why LocalLastChangedAt?

Lesson 10 annotated:

LocalLastChangedAt

with:

@Semantics.systemDateTime.localInstanceLastChangedAt: true

The persistence also uses the RAP-ready timestamp type.

That makes it appropriate as the local ETag field for this entity.

---

25. Add standard operations

Inside the BDEF body, add:

create;
update;
delete;

The BDEF now says that consumers may request these standard modifications.

---

26. What create; means

This line:

create;

adds standard create behavior to the BO contract.

It does not mean you implement:

INSERT zresv_###

inside the Behavior Pool.

For this managed BO, the framework provides standard persistence handling.

---

27. What update; means

This line:

update;

adds standard update behavior.

Future consumers modify the BO through RAP rather than directly updating the table.

---

28. What delete; means

This line:

delete;

adds standard delete behavior to the BO contract.

Again, managed RAP provides the generic technical implementation.

---

29. Why there is no simple read;

You declare:

create
update
delete

as standard modifying behavior.

You do not add a matching:

read;

statement beside them.

Reading BO entities becomes visible when you use:

READ ENTITIES

in Lesson 12.

---

30. Managed UUID numbering

Earlier, you generated UUIDs manually with:

CL_SYSTEM_UUID

Now let RAP manage the technical key.

Add:

field ( numbering : managed, readonly ) Uuid;

Read this as:

numbering : managed
→ RAP generates the UUID

readonly
→ the consumer does not provide or change it

---

31. Why managed numbering fits SYSUUID_X16

Your persistence key uses:

SYSUUID_X16

That persistence design prepared the table for RAP-managed UUID generation.

---

32. Protect administrative fields

Add:

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

These fields describe technical lifecycle state.

Normal consumers should not submit arbitrary values for them.

---

33. Why read-only administrative data matters

The BO contract should prevent ordinary consumers from treating values such as these as user-editable business data:

CreatedBy
CreatedAt
LastChangedBy
LastChangedAt

With the administrative semantics from Lesson 10 and the managed behavior, RAP can maintain the relevant lifecycle fields.

---

34. Persistence names and BO names differ

Your CDS uses names such as:

ReservationNo
CustomerName
LocalCreatedAt

The table uses:

reservation_no
customer_name
local_created_at

Managed RAP needs a clear relationship between those names.

---

35. Add persistence mapping

Add:

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;
}

---

36. Read the mapping direction correctly

For example:

CustomerName = customer_name;

means:

BO/CDS element
CustomerName

maps to persistence field
customer_name

The left side belongs to the BO entity. The right side belongs to the persistent table.

---

37. Why explicit mapping is useful here

We deliberately use different naming styles:

BO / CDS               Persistence
------------------------------------------
ReservationNo          reservation_no
CustomerEmail          customer_email
LocalLastChangedAt     local_last_changed_at

Explicit mapping makes the relationship visible and auditable.

---

38. Complete Behavior Definition

Your complete BDEF should now look like:

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;
  }
}

Replace all ###.

---

39. Create the Behavior Pool with Quick Fix

The BDEF references:

ZBP_R_RESV_###

but the class does not exist yet.

Place the cursor on:

zbp_r_resv_###

Press:

Ctrl+1

Choose the Quick Fix that creates the behavior implementation class.

Follow the wizard, assign the course transport if required, and finish.

---

40. Inspect the generated Behavior Pool

Open:

ZBP_R_RESV_###

The generated global class is a special behavior implementation class.

Confirm that it is associated with the BO through:

FOR BEHAVIOR OF

Do not replace it with a normal standalone application class.

---

41. Why is there almost no code?

You enabled:

create
update
delete
managed UUID numbering
managed lock handling
ETag handling
persistence mapping

without writing SQL implementations for them.

That is the point of managed RAP.

The Behavior Pool becomes more important when you add custom business logic in later lessons.

---

42. Activate the related RAP objects

Use:

Ctrl+Shift+F3

where appropriate to activate related objects.

At minimum, ensure these activate:

ZR_RESERVATION_###
Behavior Definition for ZR_RESERVATION_###
ZBP_R_RESV_###

Read every ADT error before changing source.

---

43. How can you check what you created today?

Lesson 11 adds behavior, but we deliberately have not introduced a consumer yet.

Verification today is mainly structural and declarative.

Check 1 — BDEF syntax

Run:

Ctrl+F2

The BDEF should have no syntax errors.

Check 2 — Activation

Activate the root, BDEF, and Behavior Pool.

Check 3 — Behavior Pool connection

Open:

ZBP_R_RESV_###

Confirm it is a behavior implementation class for the Reservation BO.

Check 4 — Navigate the architecture

From the BDEF, use:

F3

or:

Ctrl+click

where supported to navigate to:

ZR_RESERVATION_###
ZRESV_###
ZBP_R_RESV_###

Check 5 — Root data still previews

Open:

ZR_RESERVATION_###

and press:

F8

The CDS still represents the BO data shape.

---

44. What Data Preview does not prove

CDS Data Preview can prove:

the root CDS activates
the entity can be queried
the field shape is correct
existing rows can be read

It does not prove that:

managed create works
managed UUID numbering works
update works
delete works
ETag behavior works at runtime

Lesson 12 will prove managed create, numbering, update, and delete with EML. Testing stale-version rejection requires an OData consumer and belongs to the later service lessons.

---

45. Why not test CRUD today?

To truly exercise the behavior you need another consumer mechanism such as:

EML
or
service exposure

Both are separate course concepts.

This lesson keeps one clean focus:

define the transactional contract

Lesson 12 then asks:

Does the contract actually work when ABAP consumes it?

---

46. Compare direct SQL with managed RAP

Earlier:

INSERT zresv_### ...
UPDATE zresv_### ...
DELETE FROM zresv_### ...

The application code itself performed persistence operations.

Now:

Behavior Definition
   ├─ create
   ├─ update
   └─ delete

declares what the BO supports.

The managed runtime performs the standard persistence work through the BO.

---

47. Why direct SQL is no longer the normal consumer path

Once the Reservation is owned by the RAP BO, normal application consumers should not bypass it with direct table modifications.

Direct writes can bypass future behavior such as:

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

Keep the earlier SQL class as a learning artifact, not as the future Reservation application API.

---

48. Architecture at the end of Lesson 11

You now have:

ZRESV_###
    ↓
ZR_RESERVATION_###
    ↓
Managed Behavior Definition
    ↓
ZBP_R_RESV_###

Another useful view is:

Persistence
    ↓
BO structure
    ↓
BO behavior contract
    ↓
Behavior implementation container

---

49. What is still missing?

You have defined behavior, but you have not acted as a consumer.

You have not yet written:

READ ENTITIES
MODIFY ENTITIES
COMMIT ENTITIES
ROLLBACK ENTITIES

You also have not inspected:

MAPPED
FAILED
REPORTED

That is Lesson 12.

---

50. Knowledge check

1. What does a Behavior Definition describe?

2. Why is managed RAP appropriate for this Reservation?

3. What does persistent table zresv_### mean?

4. What does alias Reservation provide?

5. What do create;, update;, and delete; declare?

6. Why is there no matching simple read; statement?

7. What does numbering : managed do?

8. Why must Uuid also be read-only?

9. Why are the five administrative fields read-only?

10. What does lock master protect?

11. What is pessimistic concurrency control?

12. What does etag master LocalLastChangedAt mean?

13. What is optimistic concurrency control?

14. Why do we need persistence mapping?

15. What is a Behavior Pool?

16. Why can the Behavior Pool contain almost no custom code today?

17. What can F8 prove today?

18. What can only be proven when a consumer uses the BO?

---

51. Teacher-led completion checklist

• Lesson 10 root CDS exists.
• Behavior Definition exists for ZR_RESERVATION_###.
• Implementation type is managed.
• strict ( 2 ) is present.
• Entity alias is Reservation.
• Persistent table is ZRESV_###.
• Root is lock master.
• Authorization baseline is explicit.
• LocalLastChangedAt is the ETag master.
• create; is enabled.
• update; is enabled.
• delete; is enabled.
• Uuid uses managed numbering.
• Uuid is read-only.
• Administrative fields are read-only.
• Explicit persistence mapping is complete.
• ZBP_R_RESV_### exists.
• Behavior Pool was created with ADT Quick Fix.
• Related objects activate.
• Root CDS still opens in Data Preview.
• Student can explain lock vs ETag.
• Student can explain why runtime CRUD proof waits for Lesson 12.

---

52. End-of-day mental model

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

Consumer
   ↓
[ Lesson 12 ]
   ↓
ZR_RESERVATION_###
   ↓
Managed Behavior
   ↓
ZRESV_###

and explain:

Lesson 10
What does the BO look like?

Lesson 11
What can the BO do?

Lesson 12
How does ABAP consume it?

That progression is the foundation for the rest of RAP.