Lesson 12 Practice — Consume the Support Issue BO with EML

In Lesson 11 Practice, you completed:

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

Now consume that Business Object from ABAP.

Create:

ZCL_ISSUE_EML_###

Your target architecture is:

ZCL_ISSUE_EML_###
        ↓
       EML
        ↓
ZR_ISSUE_###
        ↓
Managed RAP
        ↓
ZISSUE_###

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

Do not copy the Reservation class and simply rename identifiers.

Rebuild the transaction from the requirements.

---

Practice information

Time	About 3 hours
Prerequisite	Lesson 12 teacher-led work
Business Object	ZR_ISSUE_###
Consumer	ZCL_ISSUE_EML_###
Persistence	ZISSUE_###
Main focus	EML + transactional buffer

---

1. Verify your starting BO

Before writing EML, verify that these objects activate:

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

Your BDEF should provide at least:

create
update
delete
managed UUID numbering
read-only UUID
read-only administrative fields
persistent table mapping
lock master
ETag master

If the BO does not activate, repair Lesson 11 first.

---

2. Create the EML consumer class

Create:

ZCL_ISSUE_EML_###

Implement:

IF_OO_ADT_CLASSRUN

Do not put this logic into:

ZBP_R_ISSUE_###

This class is an external BO consumer.

---

3. Write the architecture before the syntax

In your notes, complete:

ABAP consumer:
________________________

EML target root:
________________________

Entity alias:
________________________

Managed persistence:
________________________

Then explain what each arrow means:

Consumer → EML → BO → Persistence

---

4. Reserved practice Issue Numbers

Use:

93000001
93000002

Use them only for this Lesson 12 practice.

Your final result should leave:

93000001

persisted for inspection while:

93000002

is deleted through EML.

---

5. Make the exercise repeatable

A previous run may already contain one or both reserved Issue Numbers.

Build a safe reset.

Requirements:

1. read the root CDS to discover UUIDs belonging to 93000001 or 93000002;
2. if any exist, delete them through EML;
3. inspect the cleanup FAILED and REPORTED responses;
4. commit the cleanup only if the delete succeeded, and check the save responses and return code;
5. do not use direct SQL DELETE against ZISSUE_###.

If deletion or its commit fails, output the responses, roll back, and stop the class before creating new data.

The read-only lookup may use ABAP SQL against:

ZR_ISSUE_###

The modification itself must use EML.

---

6. CREATE two Issues through EML

Use one:

MODIFY ENTITIES

create request to create two Issue instances.

Use %cid values such as:

ISSUE_A
ISSUE_B

Do not provide:

Uuid
administrative fields

RAP owns those technical values.

---

7. Required Issue A values

Use values equivalent to:

IssueNo:        93000001
Title:          EML practice issue A
Description:    Transaction buffer exercise
RequesterEmail: issue.a@example.com
Priority:       H
Status:         O
ReportedOn:     current system date
EstimatedCost:  80.00
CurrencyCode:   EUR

Adapt only if your own persistence uses a slightly different field definition.

---

8. Required Issue B values

Use values equivalent to:

IssueNo:        93000002
Title:          EML practice issue B
Description:    Delete exercise
RequesterEmail: issue.b@example.com
Priority:       M
Status:         O
ReportedOn:     current system date
EstimatedCost:  40.00
CurrencyCode:   EUR

---

9. Inspect CREATE responses

Request all three relevant response channels:

MAPPED
FAILED
REPORTED

Output them.

Then answer:

Why should MAPPED contain two Issue entries?

Why should the generated UUIDs already be available before COMMIT?

What would make you stop the lifecycle instead of continuing?

---

10. Retrieve the generated UUIDs safely

Do not assume the mapped table order unless you can prove it.

Locate the mapping for:

ISSUE_A
ISSUE_B

using %cid.

Save the generated UUIDs in normal variables such as:

uuid_a
uuid_b

Do not manually generate UUIDs.

---

11. READ Issue A before COMMIT

Before committing the create, use:

READ ENTITIES

with:

uuid_a

Read at least:

Uuid
IssueNo
Title
Priority
Status
EstimatedCost
CurrencyCode

Output the result.

Then explain:

What does this prove about the RAP transactional buffer?

---

12. Commit the creates

Use the long response form of:

COMMIT ENTITIES

for:

ZR_ISSUE_###

Retrieve:

FAILED
REPORTED

for the save phase.

Check:

sy-subrc

Capture it immediately after COMMIT ENTITIES, before console output or further operations. If it is nonzero or FAILED is not initial, output the responses, execute ROLLBACK ENTITIES, and stop. Apply this guard to every commit in the exercise.

Do not use sy-dbcnt as the RAP transaction result.

---

13. READ Issue A after COMMIT

Read all fields of Issue A.

Inspect:

IssueNo
Status
LocalCreatedBy
LocalCreatedAt
LocalLastChangedBy
LocalLastChangedAt
LastChangedAt

Compare this with your direct-SQL experience from Lesson 9.

---

14. First UPDATE — buffer only

Change Issue A from:

Status = O

to:

Status = I

Also change one ordinary business field, for example:

Description = Buffered update - rollback

Use:

MODIFY ENTITIES
UPDATE FIELDS

Do not commit.

---

15. READ the uncommitted update

Use EML to read Issue A again before commit.

Expected buffer state:

Status      = I
Description = Buffered update - rollback

Output the result.

---

16. Roll back the UPDATE

Use:

ROLLBACK ENTITIES

Then read Issue A again.

Expected state:

Status = O

and the original Description should be restored.

Document:

Before rollback:
After rollback:

---

17. Explain what rollback proved

Write a short explanation using all of these terms:

persistent state
transactional buffer
interaction phase
ROLLBACK ENTITIES

Do not describe rollback merely as:

undo

Explain what was undone and where it existed.

---

18. UPDATE again and commit

Repeat the update to:

Status = I

This time use a Description such as:

Updated through EML

Inspect:

FAILED
REPORTED

Then commit successfully.

---

19. Prove the committed UPDATE

Read Issue A again.

Expected:

IssueNo      = 93000001
Status       = I
Description  = Updated through EML

Inspect whether the last-change timestamp changed.

---

20. DELETE Issue B

Delete only:

uuid_b

through EML.

Do not delete by:

IssueNo

inside the actual EML delete request.

The technical BO key is the UUID.

---

21. Commit the DELETE

Use:

COMMIT ENTITIES

and inspect:

FAILED
REPORTED
sy-subrc

Do not continue silently if the delete fails.

---

22. READ the deleted key

Try to read:

uuid_b

through EML after the delete commit.

Record:

RESULT:
FAILED:

Explain how the read response indicates that the instance is no longer available.

---

23. Final READ of Issue A

Read all fields of:

uuid_a

Output the result.

This is the final surviving practice instance.

---

24. Verify with CDS Data Preview

Open:

ZR_ISSUE_###

Press:

F8

Verify:

93000001 exists
Status = I

Verify:

93000002 does not exist

---

25. Verify physical persistence

Open:

ZISSUE_###

Use:

Alt+F8

Compare:

CDS business-facing names

with:

physical table fields

Do not edit the row through table tools.

---

26. Response audit table

Complete this table from your actual run:

Operation	MAPPED	FAILED	REPORTED	Commit?
CREATE two Issues
Buffered UPDATE	n/a			No
Committed UPDATE	n/a			Yes
DELETE Issue B	n/a			Yes

Do not write what you expected.

Record what your program actually returned.

---

27. Transaction-state audit

Complete:

State 1 — before CREATE
Issue A:
Issue B:

State 2 — after CREATE, before COMMIT
Issue A:
Issue B:

State 3 — after CREATE COMMIT
Issue A:
Issue B:

State 4 — after first UPDATE, before ROLLBACK
Issue A:

State 5 — after ROLLBACK
Issue A:

State 6 — after committed UPDATE
Issue A:

State 7 — after DELETE commit
Issue A:
Issue B:

This is more important than memorizing EML syntax.

---

28. Repair exercise A — wrong entity alias

Temporarily replace the correct alias with an incorrect entity name in one EML statement.

Run:

Ctrl+F2

Read the ADT error.

Restore the correct source.

Explain:

Where does the EML entity alias come from?

---

29. Repair exercise B — try to provide Uuid

Temporarily attempt to include:

Uuid

as a normal create field/value.

Observe the syntax/contract problem caused by the BDEF's managed read-only key.

Restore the correct create request.

Explain:

Which artifact made Uuid read-only and managed-numbered?

---

30. Repair exercise C — remove COMMIT

Temporarily reason through what would happen if you removed the commit after a successful modification.

Do not leave the final solution broken.

Explain:

Why is a successful MODIFY ENTITIES not the same thing as completing the RAP transaction?

---

31. Repair exercise D — use direct SQL UPDATE

Do not execute an unsafe write.

Instead, write down why this would be architecturally wrong:

UPDATE zissue_###
  SET status = 'I'
  WHERE uuid = @uuid_a.

Your explanation must mention at least four RAP concerns that direct SQL could bypass.

---

32. IN LOCAL MODE check

Search your consumer class.

It should not contain:

IN LOCAL MODE

Explain why a normal external BO consumer should respect the BO contract rather than bypass parts of it.

---

33. Explain the managed UUID lifecycle

Complete:

Before CREATE request:
Consumer knows ____________________

During managed CREATE:
RAP generates ____________________

MAPPED connects:
____________________ to ____________________

After COMMIT:
The persistent technical key is ____________________

---

34. Explain interaction vs save phase

Using your own words, distinguish:

MODIFY ENTITIES responses

from:

COMMIT ENTITIES responses

Why might a future business rule allow the first step but reject the final save?

You do not need validation syntax yet.

That is Lesson 13.

---

35. Explain EML vs SQL

Write a short comparison:

ABAP SQL
→ operates on persistence/data sources

EML
→ operates on RAP Business Objects

Then explain why that distinction matters after business behavior exists.

---

36. Certification-style task

Without looking at the guided Reservation code, perform this mini-task:

Create one temporary Issue with EML, retrieve its generated UUID from MAPPED, read it before commit, roll back the transaction, and prove the Issue is not persisted.

Use a different Issue Number from:

93000001
93000002

Do not leave the temporary Issue behind.

---

37. Optional challenge — use BDEF-derived types explicitly

Instead of only inline VALUE #( ) expressions, declare one request table using a BDEF-derived type such as:

TYPE TABLE FOR CREATE

Populate it first.

Then pass it to the EML create request.

Compare the readability with the inline form.

---

38. Optional challenge — commit simulation research

SAP RAP also provides a commit simulation mode.

Research:

COMMIT ENTITIES IN SIMULATION MODE

Answer:

What does it trigger?

What does it deliberately not do?

Do not replace the main lesson's normal commit with simulation mode.

---

39. Submission checklist

• ZCL_ISSUE_EML_### exists.
• Class implements IF_OO_ADT_CLASSRUN.
• No direct SQL writes modify ZISSUE_###.
• Repeatable cleanup uses EML for deletion.
• Two Issues are created with EML.
• %cid is used for both create requests.
• UUIDs are generated by RAP.
• UUIDs are retrieved from MAPPED.
• FAILED is inspected.
• REPORTED is inspected.
• Issue A is read before CREATE commit.
• CREATE is committed.
• Administrative fields are inspected after commit.
• First UPDATE is visible before rollback.
• ROLLBACK ENTITIES is used.
• Rollback is proven with a read.
• Second UPDATE is committed.
• Issue B is deleted through EML by UUID.
• DELETE is committed.
• Deleted key is tested with EML READ.
• Issue A remains persisted.
• F8 confirms Issue A.
• F8 confirms Issue B is absent.
• Response audit is completed.
• Transaction-state audit is completed.
• Repair exercises are completed and restored.
• Consumer does not use IN LOCAL MODE.

---

40. End-of-practice model

You should now be able to explain this from memory:

ABAP consumer
    ↓
MODIFY ENTITIES
    ↓
MAPPED / FAILED / REPORTED
    ↓
RAP transactional buffer
    ↓
READ own changes
    ↓
COMMIT ENTITIES
or
ROLLBACK ENTITIES
    ↓
persistent state

If that model is clear, you are ready for business rules and RAP messages.