Lesson 11 Practice — Add Managed Behavior to Support Issues

In Lesson 10 Practice, you created:

ZISSUE_###
    ↓
ZR_ISSUE_###

Today you add the transactional behavior contract:

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

This practice is intentionally more independent than the guided Reservation exercise.

Do not copy the complete reference from the Companion until you have attempted the model yourself.

---

Practice information

Time	About 3 hours
Prerequisite	Lesson 11 teacher-led work
Persistence	ZISSUE_###
Root CDS	ZR_ISSUE_###
New Behavior Pool	ZBP_R_ISSUE_###
Implementation type	Managed RAP
EML today?	No
Main goal	Managed transactional contract

---

1. Verify your Lesson 10 starting point

Before creating behavior, confirm that:

ZISSUE_###
ZR_ISSUE_###

both exist and activate.

Your root CDS should expose concepts equivalent to:

Uuid
IssueNo
Title
Description
RequesterEmail
Priority
Status
ReportedOn
EstimatedCost
CurrencyCode
LocalCreatedBy
LocalCreatedAt
LocalLastChangedBy
LocalLastChangedAt
LastChangedAt

Do not redesign the persistence today unless a real defect prevents the RAP behavior from being built.

---

2. Draw the target architecture first

Complete this before touching the BDEF:

Persistence:
________________________

BO root structure:
________________________

Behavior contract:
________________________

Behavior implementation class:
________________________

Then draw the arrows between them.

---

3. Choose the implementation model

Decide between:

managed
unmanaged

For your chosen answer, write three reasons based on the Support Issue scenario.

Your reasoning should consider:

who owns the persistence
whether the table is greenfield or legacy
whether an existing save API must be reused
whether the persistence is a normal database table
whether the key is RAP-ready

---

4. Create the Behavior Definition

Create a Behavior Definition for:

ZR_ISSUE_###

Use ADT from the root CDS entity where possible.

Choose the implementation type that fits your reasoning.

For the course solution, the final result must be:

Managed

---

5. Add strict mode

Use the same strict-mode baseline as the guided exercise:

strict version 2

Do not copy an old RAP example that omits the current strict-mode baseline.

---

6. Choose the entity alias

Use:

Issue

as the RAP entity alias.

Answer:

What is the difference between ZR_ISSUE_### and the alias Issue?

---

7. Connect the persistent table

The managed BO must store active Support Issue state in:

ZISSUE_###

Add the correct BDEF persistence clause.

Then explain:

Is the persistent table the same thing as the root CDS entity?

---

8. Configure locking

The BO is currently single-node/root-only.

Configure the root as the lock owner for this BO.

Then answer:

What type of concurrency control does RAP locking provide?

Why does the single-node root own the lock in this model?

---

9. Configure the authorization baseline

Use the same training-stage authorization baseline as the Reservation BO.

Do not implement authorization logic today.

Record the exact BDEF clause you used.

Then explain why that clause is acceptable for a controlled training stage but not a complete production security design.

---

10. Configure the ETag

Use the field that represents:

local instance last changed timestamp

as the ETag master field.

Do not use:

ReportedOn
LocalCreatedAt

simply because they are date/time fields.

Answer:

What kind of concurrency control does an ETag provide?

What problem is an ETag intended to detect?

---

11. Enable standard operations

Enable the three standard modification operations learned today:

create
update
delete

Do not add:

actions
validations
determinations
feature control

Those are later lessons.

---

12. Explain the missing read;

In your notes, answer:

Why does the BDEF enable Create, Update, and Delete with explicit standard-operation statements but not contain a matching simple read; line?

Use the lesson's RAP consumer model in your explanation.

---

13. Configure managed UUID numbering

Your Issue technical key is:

Uuid

Configure it so that:

RAP generates it
+
normal consumers cannot provide or change it

Do not generate UUIDs manually in a Behavior Pool.

Do not use CL_SYSTEM_UUID in this practice.

---

14. Protect administrative fields

Mark all five lifecycle fields as read-only in the BO contract:

LocalCreatedBy
LocalCreatedAt
LocalLastChangedBy
LocalLastChangedAt
LastChangedAt

Then answer:

Why should a caller not be able to provide arbitrary values for these fields?

---

15. Build the mapping plan before coding it

Complete this table using your own persistence definition:

BO/CDS element	Persistence field
Uuid
IssueNo
Title
Description
RequesterEmail
Priority
Status
ReportedOn
EstimatedCost
CurrencyCode
LocalCreatedBy
LocalCreatedAt
LocalLastChangedBy
LocalLastChangedAt
LastChangedAt

Do not start the BDEF mapping block until you can complete this table confidently.

---

16. Add persistence mapping

Add a mapping block for:

ZISSUE_###

Map every root CDS element that belongs to the persistent state.

Remember the direction:

BO field = persistence field

Do not reverse it.

---

17. Perform the first syntax audit

Run:

Ctrl+F2

Do not immediately copy a solution if you see an error.

Classify the problem first:

BDEF syntax
missing entity field
wrong persistent-table field
wrong ETag field
missing implementation class

Repair one problem at a time.

---

18. Create the Behavior Pool

Your BDEF must use:

ZBP_R_ISSUE_###

as the Behavior Pool.

Create it from the BDEF using:

Ctrl+1

and the ADT Quick Fix.

Do not manually create an ordinary class first.

---

19. Inspect the Behavior Pool

Open:

ZBP_R_ISSUE_###

Verify that it is a behavior implementation class associated with the Issue BO.

Look for the generated relationship based on:

FOR BEHAVIOR OF

Do not add custom SQL CRUD code.

---

20. Explain why the Behavior Pool is almost empty

Write a short explanation using these ideas:

managed provider
standard create/update/delete
generic framework behavior
custom business logic comes later

Your explanation should make clear why an almost-empty Behavior Pool is not evidence that the BO does nothing.

---

21. Activate related objects

Activate:

ZR_ISSUE_###
Behavior Definition for ZR_ISSUE_###
ZBP_R_ISSUE_###

Use:

Ctrl+Shift+F3

where useful for related activation.

All final submitted objects must be active.

---

22. Navigate the BO architecture

From the Behavior Definition, practice navigating to:

ZR_ISSUE_###
ZISSUE_###
ZBP_R_ISSUE_###

Use:

F3

or:

Ctrl+click

where supported.

Do not rely only on Project Explorer searching.

---

23. Preview the root CDS

Open:

ZR_ISSUE_###

Run:

F8

Confirm that the root CDS remains queryable.

The table may contain zero rows.

That is acceptable.

---

24. Explain what F8 proves

Complete:

F8 proves:
____________________________________
____________________________________

F8 does NOT prove:
____________________________________
____________________________________

Your second section should mention transactional behavior.

---

25. Repair exercise A — wrong persistence mapping target

Temporarily misspell one mapping target.

For example, make one right-hand-side table field incorrect.

Then:

1. Ctrl+F2
2. read the ADT error
3. navigate to ZISSUE_###
4. find the real field name
5. repair the mapping
6. activate

Record the error message in your notes.

---

26. Repair exercise B — wrong ETag field

Temporarily replace the ETag field with LocalCreatedAt.

Run syntax check and inspect the result. Record whether ADT rejects the choice; do not assume every semantically unsuitable field produces a syntax error.

Restore:

LocalLastChangedAt

Explain why a creation timestamp cannot reliably detect later changes, even if the syntax is accepted. A valid ETag value must change when the instance changes.

---

27. Repair exercise C — remove readonly from the UUID

Temporarily change the UUID field characteristic so that managed numbering remains but the key is no longer declared read-only.

Run syntax check.

Read the strict-mode/managed-numbering feedback from ADT.

Restore the correct model.

Explain why internal managed numbering and a consumer-editable key conflict conceptually.

---

28. Repair exercise D — break the Behavior Pool reference

Temporarily misspell the Behavior Pool class name in the BDEF.

Observe the ADT marker and Quick Fix behavior.

Restore:

ZBP_R_ISSUE_###

Make sure the correct implementation class is still active.

---

29. Repair exercise E — remove the persistent table clause

Temporarily remove the persistence connection from the managed BDEF.

Run syntax check.

Observe what the managed behavior model now lacks.

Restore the final correct source.

Explain:

Why does a managed persistent BO need to know where active state is stored?

---

30. Architecture audit

Fill in:

Physical persistence:
____________________________

BO structure:
____________________________

BO behavior contract:
____________________________

Implementation container:
____________________________

Technical entity key:
____________________________

ETag field:
____________________________

Lock owner:
____________________________

---

31. Compare SQL and RAP behavior

Earlier, your Issue lifecycle class performed direct SQL.

Complete:

Earlier write path:
____________________________

Current provider architecture:
____________________________

Then answer:

Why should future normal consumers stop directly updating ZISSUE_###?

Give at least four RAP concerns that direct SQL could bypass.

---

32. Certification-style repair task

Imagine you receive a project where:

root CDS activates
BDEF does not activate
Behavior Pool exists

ADT reports a problem around one mapping field.

Describe the fastest investigation path using:

Ctrl+F2
F3 / Ctrl+click
persistence table definition
root CDS definition
BDEF mapping

Write the order you would inspect the artifacts.

---

33. Explain lock vs ETag without notes

In your own words, explain the difference between:

lock master

and:

etag master LocalLastChangedAt

Your explanation must include:

pessimistic
optimistic
concurrent modification
stale version

---

34. Explain managed behavior without saying “automatic” only

Write a better explanation than:

RAP does it automatically.

Your explanation should state what you still configure and what the managed runtime provides.

---

35. No tomorrow concepts in the final submission

Do not add:

READ ENTITIES
MODIFY ENTITIES
COMMIT ENTITIES
ROLLBACK ENTITIES
MAPPED
FAILED
REPORTED
validations
determinations
actions
Service Definition
Service Binding

Those belong to later lessons.

---

36. Submission checklist

Starting model

• ZISSUE_### exists.
• ZR_ISSUE_### exists and activates.

Behavior Definition

• BDEF is managed.
• strict ( 2 ) is present.
• Alias is Issue.
• Persistent table is ZISSUE_###.
• Root is lock master.
• Authorization baseline is explicit.
• LocalLastChangedAt is ETag master.
• Create is enabled.
• Update is enabled.
• Delete is enabled.
• Uuid uses managed numbering.
• Uuid is read-only.
• Five administrative fields are read-only.
• Persistence mapping is complete.

Behavior Pool

• ZBP_R_ISSUE_### exists.
• It was generated as a behavior implementation.
• It is associated with the Issue BO.
• No manual CRUD SQL was added.

Verification

• BDEF passes syntax check.
• Related objects activate.
• Root CDS opens in Data Preview.
• Navigation between root, table, BDEF, and Behavior Pool works.
• Repair exercises were restored to the correct final state.
• Student can explain lock vs ETag.
• Student can explain why runtime CRUD proof belongs to Lesson 12.

---

37. End-of-practice model

Your final architecture should be:

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

Now add a blank consumer box above it:

[ EML Consumer — Lesson 12 ]
           ↓
      ZR_ISSUE_###
           ↓
     Managed Behavior
           ↓
       ZISSUE_###

If you can explain every arrow, you are ready for EML and the RAP transactional buffer.