Lesson 14 Practice — Add Actions and Feature Control to Support Issues

In Lesson 13 Practice, your Support Issue BO gained:

default Status
validations
messages

Now make it state-aware.

Target behavior:

Open
 └─ startProcessing → In Progress
                      └─ close → Closed

Target architecture:

ZCL_ISSUE_ACTIONS_###
        ↓
       EML
        ↓
ZR_ISSUE_###
        ↓
Managed RAP Behavior
   ├─ actions
   ├─ static field control
   └─ instance feature control
        ↓
ZISSUE_###

---

Practice information

Time	About 3 hours
Prerequisite	Lesson 14 teacher-led work
Business Object	ZR_ISSUE_###
Behavior Pool	ZBP_R_ISSUE_###
New test class	ZCL_ISSUE_ACTIONS_###
Actions	startProcessing, close
Main goal	State-aware Issue behavior

---

1. Verify the starting BO

Confirm these activate:

ZR_ISSUE_###
Behavior Definition
ZBP_R_ISSUE_###
ZCL_ISSUE_RULES_###

Your current BO should already contain:

managed CRUD
managed UUID numbering
locking
ETag
determination
validations
messages

---

2. Issue state model

Your status values are:

O = Open
I = In Progress
C = Closed

Use only these action-driven transitions:

O → I
I → C

Do not create:

C → O
C → I
I → O

actions.

---

3. Choose the action names

Use:

startProcessing
close

Explain why these are clearer business commands than:

set Status = I
set Status = C

---

4. Define the feature rules first

Use this matrix:

Status	Start Processing	Close	EstimatedCost	CurrencyCode
O	Enabled	Disabled	Editable	Editable
I	Disabled	Enabled	Editable	Editable
C	Disabled	Disabled	Read-only	Read-only

Do not code until you understand every row.

---

5. Add static Issue Number control

Make:

IssueNo

both:

mandatory on create
read-only on update

Use BDEF field characteristics.

Do not implement this rule in get_instance_features.

---

6. Add dynamic field declarations

Add instance feature control for:

EstimatedCost
CurrencyCode

These fields are dynamically read-only only when:

Status = C

---

7. Declare startProcessing

Declare an instance action that:

uses instance feature control
returns [1] $self

Do not add an input parameter.

---

8. Declare close

Declare a second instance action with the same action characteristics:

features : instance
result [1] $self

---

9. Preserve earlier behavior

Do not remove:

create
update
delete
numbering
locking
ETag
determination
validations
mapping

Lesson 14 extends the BO.

---

10. Generate handler methods

Use:

Ctrl+1

where ADT offers Quick Fix.

You need methods for:

startProcessing
close
get_instance_features

inside:

ZBP_R_ISSUE_###

---

11. Implement startProcessing

Requirements:

provider-side EML
IN LOCAL MODE
set Status = I
return the changed Issue
no direct SQL

Use the action keys as the identity of the affected instances.

---

12. Implement close

Requirements:

provider-side EML
IN LOCAL MODE
set Status = C
return the changed Issue
no direct SQL

The result must match:

result [1] $self

---

13. Explain the action result

For each action, answer:

What does %param contain?

Why does the handler read the Issue again after updating it?

Is the action result already proof that persistence completed?

---

14. Implement instance feature control

Read:

Status

for the requested Issue instances.

Then calculate:

startProcessing feature
close feature
EstimatedCost field feature
CurrencyCode field feature

---

15. startProcessing feature

Return:

enabled

only when:

Status = O

Otherwise:

disabled

---

16. close feature

Return:

enabled

only when:

Status = I

Otherwise:

disabled

---

17. Cost field features

Return:

unrestricted

for:

O
I

Return:

read-only

for:

C

for both:

EstimatedCost
CurrencyCode

---

18. Use the correct constant families

For actions:

if_abap_behv=>fc-o-enabled
if_abap_behv=>fc-o-disabled

For fields:

if_abap_behv=>fc-f-unrestricted
if_abap_behv=>fc-f-read_only

Do not swap them.

---

19. Activate the BO

Run:

Ctrl+F2
Ctrl+Shift+F3

Repair all BDEF/handler errors before runtime testing.

---

20. Create the test class

Create:

ZCL_ISSUE_ACTIONS_###

Implement:

IF_OO_ADT_CLASSRUN

This class is an external consumer.

Do not use:

IN LOCAL MODE

there.

---

21. Reserved practice Issue Number

Use:

97000001

for Lesson 14 Practice.

Make the exercise repeatable:

discover old UUID
delete only that instance through EML
commit cleanup

---

22. Create one Open Issue

Create:

IssueNo        = 97000001
Title          = Dynamic feature control
Description    = Lesson 14 practice
RequesterEmail = actions@example.com
Priority       = H
Status         = omitted
ReportedOn     = today
EstimatedCost  = 100.00
CurrencyCode   = EUR

The Lesson 13 determination should default:

Status = O

Commit it.

Save the generated UUID.

---

23. Read the starting state

Expected:

IssueNo = 97000001
Status  = O

Do not continue if the starting Status is not O.

---

24. Request instance permissions

Use EML:

GET PERMISSIONS ONLY INSTANCE FEATURES

Request only:

startProcessing
close
EstimatedCost
CurrencyCode

Output:

RESULT
FAILED
REPORTED

---

25. Expected permissions for O

Record:

startProcessing:
close:
EstimatedCost:
CurrencyCode:

Expected conceptually:

enabled
disabled
editable
editable

---

26. Execute startProcessing

Use EML EXECUTE.

Inspect:

RESULT
FAILED
REPORTED

Expected action result:

Status = I

Commit it.

---

27. Request permissions for I

Run the same permission request.

Expected:

startProcessing disabled
close           enabled
EstimatedCost   editable
CurrencyCode    editable

Explain why the feature method returned a different result without changing its code.

---

28. Execute close

Execute:

close

for the same UUID.

Expected action result:

Status = C

Commit it.

---

29. Request final permissions

Expected for:

Status = C

is:

startProcessing disabled
close           disabled
EstimatedCost   read-only
CurrencyCode    read-only

---

30. Verify with CDS Data Preview

Open:

ZR_ISSUE_###

Press:

F8

Find:

97000001

Expected:

Status = C

---

31. Verify static field control

Inspect the BDEF declaration for:

IssueNo

It should express:

mandatory:create
readonly:update

As a repair exercise, temporarily try to include IssueNo in a normal external EML update.

Observe the contract problem.

Restore the valid source.

---

32. Explain action vs update

Complete:

Generic update says:
________________________

startProcessing says:
________________________

close says:
________________________

Then explain why a business action can remain stable even if its implementation becomes more complex later.

---

33. Explain static vs dynamic field control

Use your actual model:

IssueNo
→ ________________________

EstimatedCost
→ ________________________

Explain why one belongs in a static field characteristic and the other belongs in instance features.

---

34. Explain feature control vs validation

Consider:

Status = I
EstimatedCost = -50

Answer:

Is EstimatedCost editable?

Is -50 business-valid?

Which RAP mechanism answers each question?

---

35. Explain feature control vs authorization

Consider:

Status = I

so:

close = enabled

Could authorization still deny the operation?

Explain.

Do not implement authorization yet.

---

36. Repair exercise A — wrong action state

Temporarily imagine:

startProcessing enabled when Status = C

Explain why this conflicts with the state model.

Restore the correct matrix.

---

37. Repair exercise B — wrong constant family

Temporarily replace a field feature constant with an operation feature constant.

Run syntax check.

Restore the correct source.

Record:

Action feature constant family:
Field feature constant family:

---

38. Repair exercise C — forget features : instance

Remove the BDEF feature declaration from one action or field temporarily.

Observe the resulting mismatch with the handler implementation.

Restore the correct BDEF.

Explain why behavior declaration and implementation must agree.

---

39. Repair exercise D — direct SQL action

Do not execute direct SQL.

Explain why this would be architecturally wrong:

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

Your answer must mention:

transactional buffer
RAP validations
save sequence
ETag
business messages

---

40. Repair exercise E — no action result

Suppose the BDEF declares:

result [1] $self

but the implementation leaves:

result

empty.

Explain what the consumer would lose.

Restore the correct implementation.

---

41. Permission audit table

Complete from your real run:

Status	Start Processing	Close	EstimatedCost	CurrencyCode
O
I
C

Do not copy the expected matrix.

Use the program output.

---

42. Action audit table

Complete:

Action	Before	Action result	After COMMIT
startProcessing
close

---

43. Consumer/provider audit

Complete:

Action declaration lives in:
____________________

Action implementation lives in:
____________________

Feature declaration lives in:
____________________

Feature calculation lives in:
____________________

Runtime permission request lives in:
____________________

---

44. Certification-style mini task

Add one extra action:

reopen

Rules:

C → O

Requirements:

instance action
result [1] $self
enabled only when Status = C
implemented with local-mode EML
tested with GET PERMISSIONS
executed through external EML
committed and verified

This is a stretch/certification-style task.

Do not keep it in the final submitted BO if your instructor wants the required state model to remain only:

O → I → C

---

45. Optional challenge — parameterized action

Research a RAP action with an input parameter.

Design:

closeWithComment

that could conceptually receive:

ClosingComment

Do not implement it unless you understand how RAP action parameter types are modeled.

Record:

Why would a parameterized action be better than adding an arbitrary temporary field to the BO?

---

46. Optional challenge — global feature control

Research:

features : global

Explain one scenario where:

an action is globally disabled for all instances

would make more sense than instance feature control.

Do not replace the required instance-feature solution.

---

47. Submission checklist

• Lesson 13 Issue behavior still activates.
• IssueNo is mandatory on create.
• IssueNo is read-only on update.
• EstimatedCost uses instance feature control.
• CurrencyCode uses instance feature control.
• startProcessing action exists.
• close action exists.
• Both actions return [1] $self.
• Both actions use instance features.
• startProcessing handler exists.
• close handler exists.
• get_instance_features exists.
• Feature handler reads Status.
• Action constants use fc-o.
• Field constants use fc-f.
• ZCL_ISSUE_ACTIONS_### exists.
• GET PERMISSIONS proves state O.
• startProcessing produces I.
• GET PERMISSIONS proves state I.
• close produces C.
• GET PERMISSIONS proves state C.
• Final cost fields are read-only.
• F8 shows 97000001 with Status C.

---

48. End-of-practice explanation

Explain without looking at the guided lesson:

Actions express named business operations.

Static field control expresses rules that never depend on instance state.

Instance feature control calculates availability from current BO state.

GET PERMISSIONS lets an ABAP consumer inspect those dynamic features.

Feature control is not validation.

Feature control is not authorization.

The BO remains the source of truth for all of these rules.

If you can demonstrate:

O → I → C

while the action/field permissions change at every state, you are ready for Lesson 15.