Lesson 13 Practice — Add Business Rules to Support Issues

In Lesson 12 Practice, you consumed the Support Issue Business Object with EML.

Now make the Business Object enforce its own business rules.

Target architecture:

ZCL_ISSUE_RULES_###
        ↓
       EML
        ↓
ZR_ISSUE_###
        ↓
Managed RAP Behavior
   ├─ determination
   ├─ validations
   └─ messages
        ↓
ZISSUE_###

This practice is deliberately more independent than the guided Reservation lesson.

Do not copy the Reservation method implementations line for line.

Translate the concepts to the Issue domain.

---

Practice information

Time	About 3 hours
Prerequisite	Lesson 13 teacher-led work
Business Object	ZR_ISSUE_###
Behavior Pool	ZBP_R_ISSUE_###
New test class	ZCL_ISSUE_RULES_###
Main focus	Business rules + RAP messages

---

1. Verify the starting point

Before changing behavior, verify that these still activate:

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

Your Lesson 12 BO should already support:

create
update
delete
managed UUID numbering
locking
ETag
persistence mapping

Repair prerequisite defects before adding new rules.

---

2. Business rules to implement

Add one determination:

If a new Issue has no Status
→ set Status = O

Add three validations:

Title
→ required

ReportedOn
→ cannot be in the future

EstimatedCost / CurrencyCode
→ cost cannot be negative
→ if cost is nonzero, CurrencyCode is required

---

3. Decide the mechanisms before coding

Complete:

Rule	Determination or Validation?	Timing
Default Status to O
Title required
Reported date not future
Cost not negative
Currency required for nonzero cost

Explain each choice.

---

4. Add the determination declaration

Add one BDEF determination for:

setInitialStatus

Requirements:

timing = on modify
trigger = create

Do not trigger it on every field change.

---

5. Add the Title validation declaration

Create:

validateTitle

Requirements:

timing = on save
trigger = create or Title change

---

6. Add the ReportedOn validation declaration

Create:

validateReportedOn

Requirements:

timing = on save
trigger = create or ReportedOn change

---

7. Add the cost validation declaration

Create:

validateCost

Requirements:

timing = on save
trigger = create or EstimatedCost/CurrencyCode change

---

8. Preserve the Lesson 11 behavior

Do not remove or replace:

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

The new business rules extend the existing BO.

---

9. Generate handler methods

Use:

Ctrl+1

from the BDEF where appropriate.

Generate/add the required handler methods inside:

ZBP_R_ISSUE_###

Do not create a second Behavior Pool.

---

10. Implement the Status determination

Your method must:

1. read the affected Issue instances with EML in local mode;
2. inspect Status;
3. select only Issues whose Status is initial;
4. update those instances to:

O

5. use RAP EML, not direct SQL.

The final implementation must not overwrite a Status already provided by the consumer.

---

11. Prove the determination is idempotent

Explain why this logic is safe if RAP invokes it more than once:

only set O when Status is initial

What would be wrong with:

always set Status = O

?

---

12. Implement validateTitle

Read:

Title

for the affected instances using:

READ ENTITIES ... IN LOCAL MODE

If Title is initial:

append instance to FAILED
append error message to REPORTED
target Title with %element

Suggested text:

Title is required

---

13. Implement validateReportedOn

Read:

ReportedOn

and compare it with:

current system date

Reject:

ReportedOn > today

Suggested text:

Reported date cannot be in the future

Target:

ReportedOn

---

14. Implement validateCost

Read:

EstimatedCost
CurrencyCode

Business rules:

EstimatedCost < 0
→ invalid

EstimatedCost <> 0
AND CurrencyCode is initial
→ invalid

Suggested messages:

Estimated cost cannot be negative
Currency code is required when cost is provided

Target the corresponding fields.

---

15. Why zero cost is allowed here

For this practice, assume:

EstimatedCost = 0

means:

no estimate entered yet

Therefore:

0 + blank currency

is acceptable.

This is a business assumption for the exercise.

Write it down.

Do not accidentally implement the Reservation fee rule, which was different.

---

16. FAILED vs REPORTED

For every validation implementation, explain:

What goes into FAILED?
What goes into REPORTED?
Why do you need both?

A correct answer must make clear that a message alone does not reject an Issue.

---

17. Field-targeted messages

Your final validation messages should target:

Title
ReportedOn
EstimatedCost
CurrencyCode

where relevant.

Do not return only generic unbound error text.

---

18. Activate the BO

Run:

Ctrl+F2

Then activate related objects:

Ctrl+Shift+F3

Final active objects must include:

ZR_ISSUE_###
Behavior Definition
ZBP_R_ISSUE_###

---

19. Create the runtime test class

Create:

ZCL_ISSUE_RULES_###

Implement:

IF_OO_ADT_CLASSRUN

This is an external consumer.

Do not use:

IN LOCAL MODE

in this class.

---

20. Reserved Lesson 13 Issue Numbers

Use:

95000001
95000002

Meaning:

95000001
→ valid determination test

95000002
→ invalid validation test

Do not reuse Lesson 12 practice numbers.

---

21. Make the test repeatable

Before creating new test data:

1. discover old 95000001 / 95000002 rows;
2. retrieve their UUIDs;
3. delete them through EML;
4. commit the cleanup;
5. inspect cleanup failures.

Continue only if both the delete and its commit succeed. On failure, output the responses, execute ROLLBACK ENTITIES, and stop the class. Capture sy-subrc immediately after each COMMIT ENTITIES before other operations.

Do not use direct SQL modification.

---

22. Test A — valid create without Status

Create Issue:

IssueNo        = 95000001
Title          = RAP rule practice
Description    = Determination test
RequesterEmail = practice@example.com
Priority       = H
Status         = omitted
ReportedOn     = today
EstimatedCost  = 100.00
CurrencyCode   = EUR

Do not provide:

Uuid
Status
administrative fields

---

23. Inspect the interaction response

Request:

MAPPED
FAILED
REPORTED

for the create.

Check that the create has a generated UUID.

Do not commit yet.

---

24. Read before COMMIT

Use:

READ ENTITIES

to read Issue 95000001 from the current RAP transaction.

Expected:

Status = O

Record:

Status supplied by consumer:
Status read before commit:

Explain what caused the difference.

---

25. Commit the valid Issue

Use:

COMMIT ENTITIES

with save responses.

Inspect:

FAILED
REPORTED
sy-subrc

Expected:

successful save

---

26. Verify valid persistence

Use:

F8

on:

ZR_ISSUE_###

Confirm:

95000001 exists
Status = O

---

27. Test B — create an invalid Issue

Prepare a date-typed test value:

DATA tomorrow TYPE d.
tomorrow = cl_abap_context_info=>get_system_date( ) + 1.

Create 95000002 with:

Title          = blank
ReportedOn     = tomorrow
EstimatedCost  = -25.00
CurrencyCode   = blank
Status         = omitted

Use reasonable values for the other fields.

---

28. Inspect MODIFY responses before save

After:

MODIFY ENTITIES

record:

MAPPED:
FAILED:
REPORTED:

Then answer:

Why can the create reach the interaction phase even though the data will later fail validation?

---

29. Commit the invalid Issue

Now run:

COMMIT ENTITIES

with:

FAILED
REPORTED

save responses.

Expected business problems:

Title is required
Reported date cannot be in the future
Estimated cost cannot be negative

Because cost is nonzero and CurrencyCode is blank, also expect:

Currency code is required when cost is provided

Use two independent checks in validateCost so that a negative cost with blank currency produces both cost messages. Add one FAILED row per invalid instance within that method. Validation execution order is not fixed, so compare the message contents and targets rather than their order.

Expect the commit return code to be 4 and the save FAILED response to identify the invalid Issue. If the commit unexpectedly succeeds, repair the rules and remove the saved test row through EML before rerunning; rollback cannot undo an earlier successful commit.

---

30. Prove the failed instance

Do not rely only on message text.

Identify the invalid instance in:

FAILED

Then identify the detailed problems in:

REPORTED

Record:

Failed instance key:
Message 1:
Target:
Message 2:
Target:
Message 3:
Target:
Message 4:
Target:

---

31. Roll back the failed test

After inspecting the save response:

ROLLBACK ENTITIES

Then verify with CDS Data Preview:

95000002 is not persisted

---

32. Test C — invalid update

Take the valid surviving Issue:

95000001

Attempt to update:

ReportedOn = tomorrow

Do not change anything else.

Run:

MODIFY ENTITIES

then:

COMMIT ENTITIES

Inspect the save validation response.

---

33. Roll back the invalid update

Use:

ROLLBACK ENTITIES

Read the Issue again.

Expected:

ReportedOn = original valid date

Document:

Attempted date:
Persisted date after rollback:

---

34. Test D — valid update

Now perform a valid update:

EstimatedCost = 125.00
CurrencyCode  = EUR

Commit it.

Verify through:

READ ENTITIES
F8 Data Preview

This proves the cost validation allows valid changes.

---

35. Explain provider vs consumer

Complete:

Business rule implementation:
____________________________

External runtime test:
____________________________

Which class owns the rules?
____________________________

Which class merely proves them?
____________________________

---

36. Explain IN LOCAL MODE

Why is it appropriate in:

ZBP_R_ISSUE_###

but not in:

ZCL_ISSUE_RULES_###

?

Use:

provider
consumer
BO contract

in your explanation.

---

37. Repair exercise A — remove FAILED

Temporarily reason about this broken validation:

message added to REPORTED
but instance not added to FAILED

Do not leave your final code broken.

Answer:

Would the message alone be a reliable instruction to reject the instance?

---

38. Repair exercise B — wrong field target

Temporarily target the Title validation message at:

CurrencyCode

Review the result conceptually.

Restore:

Title

Explain why %element quality matters for future UI consumers.

---

39. Repair exercise C — overwrite Status

Temporarily change your determination logic to:

always set Status = O

Think through this create:

consumer explicitly provides Status = I

Restore the correct default-only implementation.

Explain why determinations should preserve valid explicit input unless the business rule requires otherwise.

---

40. Repair exercise D — direct SQL in provider

Do not execute this.

Explain why this would be wrong inside the determination:

UPDATE zissue_###
  SET status = 'O'
  WHERE uuid = ...

Your answer must mention:

transactional buffer
RAP provider
EML
business-object state

---

41. Repair exercise E — validate persistence instead of BO state

Suppose the consumer changes:

ReportedOn

in the current transaction but the validation selects only the database table.

Explain why the validation could inspect stale data.

What should it use instead?

---

42. Trigger audit

For each behavior rule, record exactly what triggers it:

Rule	Create	Field trigger	Timing
setInitialStatus
validateTitle
validateReportedOn
validateCost

Do not guess.

Read your BDEF.

---

43. Response audit

Complete from your actual test run:

Test	Interaction FAILED	Save FAILED	REPORTED messages	Persisted?
Valid create
Invalid create
Invalid update
Valid update

---

44. Business-rule audit

For each rule, answer:

Could the database type alone enforce it?

Could a UI enforce it?

Why should the RAP BO still own it?

---

45. Certification-style mini task

Without looking at the guided Reservation implementation:

Add one new validation called validatePriority that accepts only L, M, or H, returns a field-targeted error message for any other value, and rejects the invalid instance during save.

Requirements:

declare it in BDEF
generate handler method
read Priority in local mode
fill FAILED
fill REPORTED
target Priority
test with Priority = Z
prove no invalid persistence

If your practice persistence already uses a Domain with fixed values for Priority, still explain why a backend business validation can provide clearer RAP failure/message behavior.

---

46. Optional challenge — message class

Research how RAP messages can be created from an ABAP message class instead of:

new_message_with_text

Do not replace the guided solution unless you understand:

message class
message number
severity
variables
translation

Record one advantage of a message class.

---

47. Optional challenge — state messages

Research:

%state_area

and answer:

What makes a RAP state message different from the transition-style messages used in this lesson?

Why might state messages become more relevant with draft/Fiori scenarios?

Do not add state-message handling to the required solution.

---

48. Submission checklist

• Lesson 12 Issue BO still activates.
• setInitialStatus determination declared.
• Determination is on modify.
• Create triggers the determination.
• Status defaults to O only when initial.
• validateTitle declared on save.
• validateReportedOn declared on save.
• validateCost declared on save.
• Handler methods exist in ZBP_R_ISSUE_###.
• Provider-side EML uses IN LOCAL MODE.
• No direct SQL modification exists in the handlers.
• Title validation fills FAILED.
• Title validation fills REPORTED.
• Title message targets Title.
• Future ReportedOn is rejected.
• Negative EstimatedCost is rejected.
• Missing Currency for nonzero cost is rejected.
• ZCL_ISSUE_RULES_### exists.
• Valid create proves default Status O.
• Invalid create fails during save.
• Multiple messages are visible.
• Invalid Issue is not persisted.
• Invalid update is rejected.
• Valid update succeeds.
• 95000001 remains visible for inspection.
• 95000002 is absent.

---

49. End-of-practice explanation

Without looking at the lesson, explain:

A determination derives data automatically.

A validation protects business invariants.

FAILED tells RAP which instance failed.

REPORTED explains the problem.

%ELEMENT connects a message to a field.

Provider implementation reads the current BO state
with EML in local mode.

External consumers see the resulting behavior
through normal EML or, later, OData.

If you can explain and demonstrate those ideas, you are ready for Lesson 14.