Lesson 10 Practice — Model the Support Issue RAP Root

Today you learned how to build the structural root of a RAP Business Object.

Now apply the same architecture to the Support Issue persistence you created earlier.

You already own:

ZISSUE_###

Your task is to create:

ZR_ISSUE_###

This is a requirements-based practice.

You will not receive the complete source up front.

---

Practice information

Time	About 3 hours
Prerequisite	Lesson 10 teacher-led work
Existing persistence	ZISSUE_###
New object	ZR_ISSUE_###
Behavior Definition today?	No
Main goal	RAP root data model

---

1. Scenario

The Support Issue table stores application-owned issue data.

The persistence includes concepts such as:

UUID
Issue Number
Title
Description
Requester Email
Priority
Status
Reported On
Estimated Cost
Currency
administrative fields

Today you will turn that persistence structure into the root data model of a future RAP Business Object.

---

2. Architecture target

Build:

ZISSUE_###
    ↓
ZR_ISSUE_###

Interpret this as:

physical persistence
    ↓
RAP BO root data model

Do not create the Behavior Definition.

---

3. Create the root Data Definition

Create:

ZR_ISSUE_###

Use a description such as:

Support Issue RAP Root

The CDS entity must use:

define root view entity

not:

define view entity

---

4. Source object

Select directly from:

ZISSUE_###

Give the data source a clear alias.

For example:

Issue

Do not add joins or associations today.

The purpose of this practice is BO structure.

---

5. Authorization annotation

Use the same training-stage authorization baseline as the guided exercise:

authorization check not required

This makes DCL optional. An existing DCL role would still apply; this annotation does not disable it.

This is not a production authorization design.

Authorization is taught later.

---

6. CDS key

Expose:

Uuid

as the CDS key.

Do not expose:

client

as an ordinary property.

Before coding, answer:

Why is the physical table key not exposed exactly as client + uuid?

---

7. Business-facing aliases

Expose business fields with clear CDS names.

Your root should contain concepts equivalent to:

IssueNo
Title
Description
RequesterEmail
Priority
Status
ReportedOn
EstimatedCost
CurrencyCode

Use the database fields from your own ZISSUE_### implementation.

Keep naming consistent.

---

8. Amount/currency semantics

Your persistence contains:

Estimated Cost
Currency Code

The CDS root must preserve the semantic relationship:

EstimatedCost
→
CurrencyCode

Do not reference the database field name if your CDS element has a different alias.

---

9. Administrative fields

Expose all five fields:

LocalCreatedBy
LocalCreatedAt
LocalLastChangedBy
LocalLastChangedAt
LastChangedAt

Apply the appropriate semantics for:

created user
created timestamp
local last-changed user
local last-changed timestamp
total last-changed timestamp

Use the guided Reservation root as a pattern.

Do not copy blindly.

---

10. Root-entity reasoning

Before activation, answer:

Why is ZR_ISSUE_### a root entity even though it has no children?

What makes Uuid different from the root designation?

Is ZR_ISSUE_### a new database table?

Does the root CDS already enable create/update/delete through RAP?

---

11. Activate

Run:

Ctrl+F2

for syntax check.

Then:

Ctrl+F3

to activate.

Repair any syntax or semantic errors.

Do not create a Behavior Definition to work around a CDS problem.

---

12. Preview

Open CDS Data Preview:

F8

The result may contain zero rows.

That is acceptable.

Inspect:

column names
key
administrative fields

Verify the amount/currency reference and administrative annotations in the CDS source and syntax-check results. Data Preview alone does not verify their runtime behavior.

---

13. Architecture audit

Complete:

Persistence:
____________________

RAP root entity:
____________________

Technical entity key:
____________________

Business-facing issue identifier:
____________________

Then draw:

__________
    ↓
__________
    ↓
[ Behavior Definition — not created yet ]

---

14. Managed vs unmanaged decision

Based only on what you know today, choose which future implementation model best fits this Issue scenario:

managed
or
unmanaged

Justify the choice using at least three facts about the scenario.

Possible facts to think about:

Who owns the persistence?
Is it new or legacy?
Is there an existing save API?
Is it normal database persistence?
Does it already have a UUID key?

Do not create the BDEF.

---

15. Repair exercise A — missing root

Temporarily change:

define root view entity

to:

define view entity

Run syntax check/activate.

Then restore the correct source.

Answer:

Does the CDS still represent data?

What architectural meaning was lost?

---

16. Repair exercise B — expose client

Temporarily add the technical client field from your source table to the select list. For the alias Issue, use:

key Issue.client as Client,

Run the syntax check and read the error. CDS View Entities handle clients implicitly and do not permit the technical client field in their select lists. Remove the invalid field, then reactivate the correct source.

Explain:

How does implicit client handling explain both the error and the absence of Client from the BO key?

---

17. Repair exercise C — remove the CDS key

Temporarily remove:

key

from Uuid.

Run syntax check/activate and observe the result.

Restore the final correct model.

Record:

What happened:
Why:

---

18. Repair exercise D — break the currency reference

Temporarily make the amount annotation point to a name that does not exist.

For example, if your element is:

CurrencyCode

reference a wrong name.

Run syntax check.

Read the ADT message.

Repair it.

Explain:

Does the semantic annotation reference the persistence field name or the CDS element name?

---

19. Compare storage and business model

Create a small mapping table in your notes:

Persistence field	CDS element
uuid	Uuid
issue_no
title
description
requester_email
priority
status
reported_on
estimated_cost
currency_code

Complete the missing values.

Then answer:

Why is this mapping useful before we add behavior?

---

20. Explain the admin fields

In one sentence each, explain:

LocalCreatedBy
LocalCreatedAt
LocalLastChangedBy
LocalLastChangedAt
LastChangedAt

Then mark which one you expect to become the local ETag field in the next lesson.

---

21. Do not implement tomorrow's concepts today

Your final practice submission must not contain:

Behavior Definition
Behavior Pool
managed implementation
strict ( 2 )
persistent table mapping
lock master
etag master
create;
update;
delete;
EML
Service Definition
Service Binding

If you already created any of those while experimenting, remove/defer them so the submitted Lesson 10 state remains focused.

---

22. Certification-style explanation

Without looking at your notes, explain aloud or in writing:

A database table stores Support Issue state. ZR_ISSUE_### does not replace that table. It models the Support Issue as the root entity of a future RAP Business Object. The CDS root defines structure; the Behavior Definition will later define the transactional behavior.

Do not memorize the wording.

Make sure you can explain the idea.

---

23. Optional challenge — inspect an SAP RAP root

Find one SAP-delivered RAP root entity available in your Trial system.

Look for:

define root view entity

Record:

Object:
Persistence source:
Key:
One business field:
One administrative field:
One association or composition, if present:

Do not copy the object.

The goal is architectural recognition.

---

24. Submission checklist

• ZISSUE_### exists.
• ZR_ISSUE_### exists.
• Root CDS uses define root view entity.
• CDS selects from ZISSUE_###.
• Uuid is the key.
• client is not exposed.
• Business fields have clear aliases.
• Estimated Cost references Currency Code.
• All five administrative fields are exposed.
• Administrative semantics are correct.
• CDS activates.
• Data Preview opens.
• Repair exercises were completed and restored.
• Managed vs unmanaged choice is justified.
• No Behavior Definition has been submitted yet.

---

25. End-of-practice model

Your final architecture should be:

ZISSUE_###
    ↓
ZR_ISSUE_###
    ↓
[ Behavior Definition — Lesson 11 ]

If you can explain every line in that diagram, you are ready for managed behavior.