Lesson 15 Practice — Secure the Support Issue Business Object

You already built a state-aware Support Issue BO.

Current flow:

O = Open
I = In Progress
C = Closed

Actions:

startProcessing
close

Now secure it.

Target architecture:

User
 ↓
CDS DCL
 ↓
ZR_ISSUE_###
 ↓
RAP Authorization
 ├─ Global
 └─ Instance
 ↓
Managed Behavior
 ↓
ZISSUE_###

---

Practice information

Time	About 3 hours
Prerequisite	Lesson 15 teacher-led work
Business Object	ZR_ISSUE_###
Behavior Pool	ZBP_R_ISSUE_###
Test class	ZCL_ISSUE_AUTH_###
New field	ResponsibleUser
New object	CDS Access Control

---

1. Verify the starting point

Confirm these activate:

ZISSUE_###
ZR_ISSUE_###
Behavior Definition
ZBP_R_ISSUE_###
ZCL_ISSUE_ACTIONS_###

Your BO should already include:

managed CRUD
managed UUID numbering
determination
validations
messages
actions
feature control

---

2. Authorization requirements

Implement:

Read:
only rows whose ResponsibleUser = current user

Global create/update/delete:
allowed in the Trial exercise

Instance update:
allowed only for ResponsibleUser

Action authorization:
reuse update authorization

Delete:
allowed for classroom cleanup

---

3. Add persistence ownership

Add:

responsible_user

to:

ZISSUE_###

Use:

ABP_CREATION_USER

or the equivalent source type used in the guided lesson.

Keep it nullable.

Explain why that matters for rows created before Lesson 15.

---

4. Extend the root CDS

Expose:

ResponsibleUser

Change:

@AccessControl.authorizationCheck: #NOT_REQUIRED

to:

@AccessControl.authorizationCheck: #CHECK

Activate.

---

5. Create CDS Access Control

Create an Access Control object for:

ZR_ISSUE_###

Requirements:

@MappingRole: true
define role
grant select on ZR_ISSUE_###
ResponsibleUser = aspect user

Do not hard-code a user.

---

6. DCL reasoning

Answer:

Does the DCL delete unauthorized Issues?

Does DCL replace RAP update authorization?

Does define role mean the same thing as a PFCG/business role?

---

7. Change RAP authorization

Replace:

authorization master ( none )

with:

authorization master ( global, instance )

Use:

Ctrl+F2

before continuing.

---

8. Update persistence mapping

Map:

ResponsibleUser

to:

responsible_user

---

9. Protect ResponsibleUser

Make:

ResponsibleUser

read-only on update.

It must remain writable during create for this exercise.

---

10. Protect Status if required

If a normal external consumer can still directly update:

Status

make it read-only.

Status should be controlled by:

initial Status determination
startProcessing
close

---

11. Delegate action authorization

Modify:

startProcessing
close

so both delegate authorization to:

update

Keep their existing:

features : instance

logic.

---

12. Generate authorization methods

Use:

Ctrl+1

Generate:

get_global_authorizations
get_instance_authorizations

Prefer ADT-generated signatures.

---

13. Implement global authorization

For the Trial exercise:

requested create
→ auth-allowed

requested update
→ auth-allowed

requested delete
→ auth-allowed

Use authorization constants.

Do not use:

fc-o-enabled

here.

---

14. Explain the global Trial simplification

Write one sentence explaining why:

allow-all global authorization

is not a production authorization model.

Mention:

authorization objects
business roles

---

15. Implement instance authorization

Read:

ResponsibleUser

using:

READ ENTITIES ... IN LOCAL MODE

Rule:

ResponsibleUser = current technical user
→ update allowed

otherwise
→ update unauthorized

For this practice:

delete
→ allowed

---

16. Obtain the current user

Use the same ABAP Cloud API as the guided lesson:

CL_ABAP_CONTEXT_INFO

and its technical-user getter.

Store the result in a compatible user variable.

---

17. Report an authorization message

For unauthorized update, report a message equivalent to:

You are not responsible for this issue

The authorization result must still be:

auth-unauthorized

A message is not the decision itself.

---

18. Activate all changed objects

Activate:

ZISSUE_###
ZR_ISSUE_###
Access Control
Behavior Definition
ZBP_R_ISSUE_###

Do not create the runtime consumer until everything activates cleanly.

---

19. Create the test class

Create:

ZCL_ISSUE_AUTH_###

Implement:

IF_OO_ADT_CLASSRUN

This is an external consumer.

It must not use:

IN LOCAL MODE

---

20. Reserved Issue numbers

Use:

99010001
99010002

Meaning:

99010001
→ owned by current user

99010002
→ ResponsibleUser initial

Use valid values so all Lesson 13 validations pass.

---

21. Repeatable reset

Because DCL will hide one test row, use the guided reset approach:

read UUIDs for exactly 99010001 / 99010002
delete those UUIDs through EML
commit

Do not use direct SQL writes.

---

22. Display current user

Output the current technical user at the beginning of the test.

Record:

Current user:
____________________

---

23. Create owned Issue

Create:

IssueNo         = 99010001
ResponsibleUser = current user
Status          = omitted

Expected determination:

Status = O

Save its generated UUID.

---

24. Create unassigned Issue

Create:

IssueNo         = 99010002
ResponsibleUser = initial
Status          = omitted

Expected:

Status = O

Save its generated UUID before commit.

---

25. Commit both creates

Inspect:

MAPPED
FAILED
REPORTED

Both create requests should save successfully in the training global-authorization model.

---

26. Prove DCL filtering

Open:

ZR_ISSUE_###

with:

F8

Expected:

99010001 visible
99010002 hidden

Then open:

ZISSUE_###

with:

Alt+F8

Expected:

both physical rows exist

Explain why.

---

27. Test global authorization

Build a permission request for:

create
update
delete

Run:

GET PERMISSIONS ONLY GLOBAL AUTHORIZATION

Record:

create:
update:
delete:

---

28. Test owned instance authorization

Request:

update
delete

for:

99010001 UUID

using:

GET PERMISSIONS ONLY INSTANCE AUTHORIZATION

Expected:

update allowed
delete allowed

---

29. Test unassigned instance authorization

Repeat for:

99010002 UUID

Expected:

update unauthorized
delete allowed

---

30. Compare feature control with authorization

For unassigned Issue:

Status = O

Lesson 14 feature control should say:

startProcessing enabled

But authorization says:

update unauthorized

Record:

Feature result:
____________________

Authorization result:
____________________

---

31. Owned action test

Execute:

startProcessing

for owned Issue.

Expected:

O → I

Commit.

---

32. Unauthorized action test

Execute:

startProcessing

for the unassigned Issue using its known UUID.

Expected:

action denied
Status remains O
authorization message returned

Explain why this happens even though state-based feature control enables the action.

---

33. Unauthorized update test

Attempt:

Notes = 'Should not persist'

on the unassigned Issue.

Expected:

update denied
Notes unchanged

Inspect RAP responses.

---

34. Owned close test

For the owned Issue now in:

I

execute:

close

Expected:

I → C

Commit.

---

35. Cleanup the unassigned Issue

Delete it using its known UUID through EML.

Because delete is deliberately allowed for training cleanup, the delete should succeed.

Commit.

---

36. Final visible state

Root CDS should show:

99010001
Status = C
ResponsibleUser = current user

The unassigned test row should be gone after cleanup.

---

37. Repair exercise — wrong access annotation

Temporarily reason about leaving:

#NOT_REQUIRED

after creating the DCL.

Restore:

#CHECK

Explain the intended difference.

---

38. Repair exercise — missing @MappingRole

Inspect what happens if the DCL source is incomplete.

Restore:

@MappingRole: true

Explain its purpose.

---

39. Repair exercise — hard-coded user

Wrong:

ResponsibleUser = 'MYUSER'

Correct concept:

ResponsibleUser = aspect user

Explain why hard-coded identity is not a scalable authorization design.

---

40. Repair exercise — wrong constant family

Wrong:

fc-o-disabled

Correct authorization result:

auth-unauthorized

Explain:

feature availability
vs
user authorization

---

41. Repair exercise — IN LOCAL MODE in consumer

Search:

ZCL_ISSUE_AUTH_###

It should not contain:

IN LOCAL MODE

Explain why the Behavior Pool may use it but the consumer may not.

---

42. Repair exercise — DCL only

Imagine you keep DCL but remove RAP authorization.

Explain why read filtering alone is not a complete write-protection strategy.

Use:

read
update
action

in your explanation.

---

43. Certification-style mini task

Temporarily change the Issue authorization policy so:

delete

is also owner-only.

Requirements:

check requested delete authorization
compare ResponsibleUser with current user
return auth-allowed or auth-unauthorized
test owned permission
test unassigned permission

Restore delete-allowed behavior afterward if you still need repeatable classroom cleanup.

---

44. Certification knowledge — PFCG

Research only:

aspect pfcg_auth
AUTHORITY-CHECK
ACTVT

Answer:

Which mechanism belongs in CDS DCL?

Which mechanism can appear inside RAP authorization implementation?

Why does this Trial lesson not create a complete custom PFCG authorization lifecycle?

---

45. Authorization audit

Complete:

Concern	Mechanism	Result
Owned Issue visible
Unassigned Issue hidden
Global create
Owned update
Unassigned update
Owned startProcessing
Unassigned startProcessing
Delete cleanup

---

46. Feature vs authorization audit

Complete:

Instance	Status	Action feature	Update authorization	Final action result
Owned	O before action
Unassigned	O

Explain why the unassigned row can have:

enabled feature
+
unauthorized operation

---

47. Submission checklist

• responsible_user added to persistence.
• ResponsibleUser exposed in root.
• Root uses #CHECK.
• Access Control created.
• DCL uses @MappingRole: true.
• DCL uses aspect user.
• BDEF uses global + instance authorization.
• ResponsibleUser mapped.
• ResponsibleUser read-only on update.
• Status protected from arbitrary external update.
• startProcessing delegates authorization to update.
• close delegates authorization to update.
• Global authorization handler exists.
• Instance authorization handler exists.
• Correct authorization constants used.
• Current technical user obtained with ABAP Cloud API.
• Owned update allowed.
• Unassigned update unauthorized.
• Global GET PERMISSIONS test works.
• Instance GET PERMISSIONS test works.
• Root F8 proves DCL filtering.
• Table preview proves hidden row still exists.
• Owned action succeeds.
• Unauthorized action is denied.
• Unauthorized update is denied.
• Cleanup uses EML modifications only.

---

48. End-of-practice explanation

Explain without notes:

DCL protects reads.

Global RAP authorization answers whether
the user may perform an operation generally.

Instance RAP authorization adds
instance-dependent user permission.

Feature control is not authorization.

A feature can be enabled while
authorization still denies execution.

IN LOCAL MODE belongs to provider logic,
not external consumers.

If you can prove those statements in your own Issue BO, you are ready for Lesson 16.