Lesson 14 Companion — Actions and Feature Control

This companion supports:

Lesson 14 — RAP Actions, Field Control, and Dynamic Feature Control

The main progression is:

Lesson 13
Is the data valid?

Lesson 14
Which business operations and fields are currently available?

Lesson 15
Is the user authorized?

---

1. Core Reservation behavior

The Reservation status values are:

N = New
C = Confirmed
X = Cancelled

Lesson 14 adds two actions:

confirm
cancel

and a feature matrix:

Status	Confirm	Cancel	Fee	CurrencyCode
N	Enabled	Enabled	Editable	Editable
C	Disabled	Enabled	Read-only	Read-only
X	Disabled	Disabled	Read-only	Read-only

---

2. Why actions matter

An action is a named business command.

Compare:

generic update:
set Status = C

with:

business action:
confirm

The action is easier for a consumer to understand and gives the provider one place to evolve the business behavior.

---

3. Action declaration reference

Use:

action ( features : instance ) confirm result [1] $self;

action ( features : instance ) cancel result [1] $self;

The action:

operates on an instance
has instance feature control
returns one instance of the same entity

---

4. Action result cardinality

This part:

[1]

means:

exactly one result per input action instance

And:

$self

means:

the result type is the current entity

The implementation must fill the result if the action declares one.

---

5. Static field-control reference

Use:

field ( mandatory:create, readonly:update ) ReservationNo;

This is static because it does not depend on current Status.

---

6. Static field characteristics

Useful characteristics include concepts such as:

readonly
mandatory
mandatory:create
readonly:update

Lesson 14 focuses on:

mandatory:create
readonly:update

because they fit the Reservation Number naturally.

---

7. Why field characteristics are part of the contract

A BO consumer should be able to learn:

which fields are required
which fields are writable

from the BO contract.

Do not encode every access rule only in consumer-side code.

---

8. Dynamic field-control reference

Use:

field ( features : instance ) Fee, CurrencyCode;

This tells RAP that the field characteristics are calculated per instance.

The implementation belongs in:

FOR INSTANCE FEATURES

---

9. Dynamic action-control reference

Use:

action ( features : instance ) confirm result [1] $self;

This tells RAP that action availability depends on the instance.

---

10. Handler signatures

ADT should generate signatures equivalent to:

METHODS confirm
  FOR MODIFY
  IMPORTING keys FOR ACTION Reservation~confirm
  RESULT result.

METHODS cancel
  FOR MODIFY
  IMPORTING keys FOR ACTION Reservation~cancel
  RESULT result.

METHODS get_instance_features
  FOR INSTANCE FEATURES
  IMPORTING keys
    REQUEST requested_features
    FOR Reservation
  RESULT result.

Prefer Quick Fix generation.

---

11. Complete confirm reference

METHOD confirm.

  MODIFY ENTITIES OF ZR_Reservation_### IN LOCAL MODE
    ENTITY Reservation
      UPDATE FIELDS ( Status )
      WITH VALUE #(
        FOR key IN keys
        ( %tky   = key-%tky
          Status = 'C' )
      )
    FAILED failed
    REPORTED reported.

  READ ENTITIES OF ZR_Reservation_### IN LOCAL MODE
    ENTITY Reservation
      ALL FIELDS
      WITH CORRESPONDING #( keys )
    RESULT DATA(reservations).

  result = VALUE #(
    FOR reservation IN reservations
    ( %tky   = reservation-%tky
      %param = reservation )
  ).

ENDMETHOD.

---

12. Complete cancel reference

METHOD cancel.

  MODIFY ENTITIES OF ZR_Reservation_### IN LOCAL MODE
    ENTITY Reservation
      UPDATE FIELDS ( Status )
      WITH VALUE #(
        FOR key IN keys
        ( %tky   = key-%tky
          Status = 'X' )
      )
    FAILED failed
    REPORTED reported.

  READ ENTITIES OF ZR_Reservation_### IN LOCAL MODE
    ENTITY Reservation
      ALL FIELDS
      WITH CORRESPONDING #( keys )
    RESULT DATA(reservations).

  result = VALUE #(
    FOR reservation IN reservations
    ( %tky   = reservation-%tky
      %param = reservation )
  ).

ENDMETHOD.

---

13. Why the action reads after update

The action declares:

result [1] $self

So it needs the changed entity state.

A clean pattern is:

modify transactional state
→ read changed instance
→ fill action result

---

14. Action results and commit

The action result reflects:

transactional state

The save is still completed with:

COMMIT ENTITIES

Do not confuse:

action result returned

with:

persistence successfully completed

---

15. Complete feature-control reference

METHOD get_instance_features.

  READ ENTITIES OF ZR_Reservation_### IN LOCAL MODE
    ENTITY Reservation
      FIELDS ( Status )
      WITH CORRESPONDING #( keys )
    RESULT DATA(reservations)
    FAILED failed.

  result = VALUE #(
    FOR reservation IN reservations
    (
      %tky = reservation-%tky

      %features-%action-confirm =
        COND #(
          WHEN reservation-Status = 'N'
          THEN if_abap_behv=>fc-o-enabled
          ELSE if_abap_behv=>fc-o-disabled
        )

      %features-%action-cancel =
        COND #(
          WHEN reservation-Status = 'N'
            OR reservation-Status = 'C'
          THEN if_abap_behv=>fc-o-enabled
          ELSE if_abap_behv=>fc-o-disabled
        )

      %features-%field-Fee =
        COND #(
          WHEN reservation-Status = 'N'
          THEN if_abap_behv=>fc-f-unrestricted
          ELSE if_abap_behv=>fc-f-read_only
        )

      %features-%field-CurrencyCode =
        COND #(
          WHEN reservation-Status = 'N'
          THEN if_abap_behv=>fc-f-unrestricted
          ELSE if_abap_behv=>fc-f-read_only
        )
    )
  ).

ENDMETHOD.

---

16. About requested_features

The generated method receives:

requested_features

because a consumer can request specific feature information.

For the first feature-control lesson, calculating all four declared features keeps the code easy to read.

In larger BOs, provider code can use the request information to avoid unnecessary calculations.

---

17. Feature constant families

Operation/action feature results use:

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

Field feature results use:

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

Do not mix them.

---

18. %features

The result derived type contains a component group:

%features

For actions:

%features-%action-confirm
%features-%action-cancel

For fields:

%features-%field-Fee
%features-%field-CurrencyCode

The exact components exist because the BDEF declares feature control for those elements.

---

19. Why Status is enough for this feature method

Every rule in this lesson depends only on:

Status

So the provider reads only:

Status

That keeps the feature calculation focused.

---

20. Feature control should be deterministic

For the same BO state:

Status = C

the feature method should return the same permission values.

Do not base feature results on arbitrary hidden handler state.

---

21. Do not store BO state in handler attributes

RAP may instantiate handler classes according to runtime needs.

Do not rely on instance attributes as long-lived transaction storage.

Read current BO state when needed.

---

22. GET PERMISSIONS

ABAP EML can query feature/authorization information.

Lesson 14 uses:

GET PERMISSIONS ONLY INSTANCE FEATURES OF ZR_Reservation_###

This lets students verify feature control before service/UI exposure exists.

---

23. GET PERMISSIONS request reference

GET PERMISSIONS ONLY INSTANCE FEATURES OF ZR_Reservation_###
  ENTITY Reservation
    FROM VALUE #(
      ( Uuid = uuid )
    )
    REQUEST VALUE #(
      %action-confirm     = if_abap_behv=>mk-on
      %action-cancel      = if_abap_behv=>mk-on
      %field-Fee          = if_abap_behv=>mk-on
      %field-CurrencyCode = if_abap_behv=>mk-on
    )
  RESULT DATA(permissions)
  FAILED DATA(failed_permissions)
  REPORTED DATA(reported_permissions).

---

24. Why request only the relevant features?

The request explicitly asks for:

confirm
cancel
Fee
CurrencyCode

This makes the test output easier to interpret and mirrors the concept that consumers request permission information they need.

---

25. Result interpretation

The permission result contains:

instance key
feature components

The values are framework feature flags.

For learning, compare them with the expected state matrix.

Do not hard-code the raw flag bytes as business constants.

---

26. State N expected result

confirm      enabled
cancel       enabled
Fee          unrestricted
CurrencyCode unrestricted

---

27. State C expected result

confirm      disabled
cancel       enabled
Fee          read-only
CurrencyCode read-only

---

28. State X expected result

confirm      disabled
cancel       disabled
Fee          read-only
CurrencyCode read-only

---

29. EML action execution reference

MODIFY ENTITIES OF ZR_Reservation_###
  ENTITY Reservation
    EXECUTE confirm
      FROM VALUE #(
        ( Uuid = uuid )
      )
    RESULT DATA(action_result)
  FAILED DATA(failed_action)
  REPORTED DATA(reported_action).

The operation is still a RAP modification.

Commit it separately.

---

30. Why action logic belongs in the BO

A future action may expand from:

set Status

to:

set Status
run checks
calculate values
write messages
raise business event

The consumer still calls:

confirm

That is one benefit of a business-oriented API.

---

31. Feature control and Fiori

When the BO is eventually exposed to a Fiori Elements UI, dynamic feature results can inform UI behavior such as:

action button enabled/disabled
field editable/read-only

Lesson 14 proves the backend logic first with EML.

---

32. Feature control is a BO concern, not a UI hack

Do not implement:

hide Confirm button when Status = C

only in frontend code.

The backend BO should express:

Confirm is unavailable for this instance

Then multiple consumers can use the same contract.

---

33. Feature control vs authorization

Feature control is based on:

business state

Authorization is based on:

user permission

A future UI may only enable an action when both dimensions allow it.

Lesson 15 adds authorization.

---

34. Feature control vs validation

Use:

field control
→ can the field currently be modified?

validation
→ is the proposed value valid?

For Fee:

Status = C
→ field read-only

Status = N and Fee = -5
→ field editable but invalid

That example shows why both mechanisms can exist.

---

35. Feature control vs determination

Determination:

derive/change data automatically

Feature control:

describe availability

They do not replace each other.

---

36. Static vs instance feature control

Prefer static BDEF characteristics when the answer never changes.

Example:

ReservationNo readonly:update

Use dynamic instance features only when the answer depends on current instance data.

---

37. Why no global feature control today?

RAP also supports global feature control.

That answers questions such as:

is this operation available globally right now?

Lesson 14 focuses on instance-state decisions because Status gives a concrete and visible example.

---

38. Why no action parameter today?

RAP actions can have input parameters.

For example:

cancel with reason
apply discount percentage
reschedule to date

The first action lesson uses parameterless actions to isolate:

action declaration
action implementation
action result
feature control

Parameterized actions can be introduced later when needed.

---

39. Static control test

Because:

ReservationNo

is readonly:update, an external EML update request should not treat it as a normal writable update field.

Use this as a controlled repair exercise.

Do not make it part of the final working class.

---

40. Dynamic field-control test

Required verification uses:

GET PERMISSIONS

rather than deliberately trying to violate the dynamic field restriction.

This keeps the lesson focused on feature calculation.

Later service/UI consumption will make dynamic editability visually obvious.

---

41. Action failure handling

The action implementation uses:

FAILED
REPORTED

from its local update.

If the internal update fails, those responses can be propagated through the action handler.

Do not ignore provider-side failure structures.

---

42. Why feature control should match action semantics

If feature control says:

confirm disabled for C

but the action implementation conceptually treats repeated confirmation as meaningful, the contract becomes confusing.

Keep availability and action design aligned.

---

43. Business transition consistency

For Lesson 14:

N → C
N → X
C → X

are the intended transitions.

The model does not expose:

X → C
C → N
X → N

through actions.

---

44. Why generic update still exists

The BO still supports:

update

for ordinary fields.

Lesson 14 does not yet lock Status itself behind actions.

That stricter design could be added later if the course wants all status changes to go exclusively through actions.

For this lesson, focus on understanding action and feature mechanics.

---

45. Safe repeatable test cleanup

For reserved number:

96000001

use a read-only lookup to discover an old UUID.

Then delete only that instance through EML.

Do not directly delete from:

ZRESV_###

---

46. Suggested runtime sequence

cleanup old training instance
        ↓
create Reservation without Status
        ↓
Lesson 13 determination → N
        ↓
commit
        ↓
GET PERMISSIONS
        ↓
confirm enabled / cancel enabled
        ↓
EXECUTE confirm
        ↓
result Status C
        ↓
commit
        ↓
GET PERMISSIONS
        ↓
confirm disabled / cancel enabled
        ↓
EXECUTE cancel
        ↓
result Status X
        ↓
commit
        ↓
GET PERMISSIONS
        ↓
both disabled

---

47. Practice scenario reference

Support Issue statuses are:

O = Open
I = In Progress
C = Closed

Recommended actions:

startProcessing
O → I

close
I → C

Recommended dynamic field behavior:

EstimatedCost
CurrencyCode

editable while O or I
read-only when C

Recommended static rule:

IssueNo
mandatory:create
readonly:update

---

48. Practice feature matrix

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

---

49. Practice actions

Declare actions equivalent to:

action ( features : instance ) startProcessing result [1] $self;

action ( features : instance ) close result [1] $self;

Students should adapt the implementation independently.

---

50. Practice feature implementation

The feature method reads:

Status

and returns:

action features
field features

according to the matrix.

Do not copy the Reservation Status values.

---

51. Common error — wrong action name in %features

If the BDEF declares:

confirm

but the method writes:

%features-%action-confirmReservation

the derived type will not match.

Use the exact action name from the BDEF.

---

52. Common error — wrong entity result

Because the action declares:

result [1] $self

the handler result uses:

%param

containing the entity result.

Do not return an unrelated local structure.

---

53. Common error — missing features : instance

If you omit dynamic feature declaration from the BDEF, the expected %features component does not belong to the contract.

The declaration creates the feature-controlled surface.

---

54. Common error — forgetting action commit

After external EML executes an action that changes transactional state, complete the transaction with:

COMMIT ENTITIES

unless the test deliberately rolls back.

---

55. Common error — checking only F8

F8 proves persisted state.

It does not show:

feature availability

Use:

GET PERMISSIONS

for that.

---

56. Certification-oriented interpretation

A practical task may give you:

an action declaration
a feature method
a Status field
an EML consumer

and ask you to repair or complete the behavior.

Trace:

BDEF declaration
→ generated handler signature
→ provider implementation
→ permission result
→ EML action call
→ persisted state

That is more useful than memorizing one sample.

---

57. Instructor validation

Before Lesson 15, students should be able to explain:

action
static field control
dynamic instance feature control
FOR INSTANCE FEATURES
GET PERMISSIONS
operation feature constants
field feature constants
feature control vs authorization

They should also be able to demonstrate changing feature results as a Reservation moves:

N → C → X

---

58. Lesson 15 boundary

Do not add:

global authorization
instance authorization
DCL
role checks

to Lesson 14.

The next lesson will layer authorization on top of the existing state-based feature model.

---

Next checkpoint — Project 3

After completing Lesson 14 and its practice, build the Purchase Request Workflow Manager. This independent project combines persistence, managed RAP behavior, EML transactions, business rules, actions, and dynamic feature control in one workflow.

Start Project 3 — Purchase Request Workflow Manager →