Managed RAP Part 3: Determinations, Validations, Actions and Feature Control

📌 KEY POINTS
✅ Determination = automatic value; validation = blocks invalid save; action = explicit step.
✅ Determinations must be idempotent; validations only read and report.
✅ Use IN LOCAL MODE inside the BO to change read-only fields.
⚠️ State rules ("only when Submitted") belong in instance feature control.

▶ WHERE WE ARE
After Part 2 the Purchase Request has numbers, locks, ETags and authorization. It still has no business rules: a request can be saved without a description, items can have zero quantity, and there is no approval workflow. This part adds the four behavior elements that carry business logic.

━━━━━━━━━━━━━━━━━━━━
▶ THE FOUR TOOLS AND WHEN TO USE EACH

• Determination — the system calculates or defaults a value automatically. Nobody triggers it explicitly. Examples: set status to New on create; recalculate the total when an item changes.
• Validation — the system checks a rule and rejects the save if it is broken. Examples: description is mandatory; quantity must be greater than zero.
• Action — the user or an API explicitly triggers a business step. Examples: Submit, Approve, Reject.
• Feature control — decides whether an operation or action is currently allowed based on the instance's state. Examples: Approve is only enabled when status is Submitted; an approved request cannot be edited.

Rule of thumb: if the user should press a button, it is an action; if it should just happen, it is a determination; if it should stop the save, it is a validation; if it should grey out a button, it is feature control.

━━━━━━━━━━━━━━━━━━━━
▶ STATUS MODEL FOR OUR EXAMPLE
N = New → (Submit) → S = Submitted → (Approve) → A = Approved, or (Reject) → R = Rejected.

━━━━━━━━━━━━━━━━━━━━
▶ DETERMINATIONS: ON MODIFY VS ON SAVE
A determination declares when it runs (the trigger) and on what (trigger operations and fields):

• "on modify { create; }" — runs immediately in the interaction phase when an instance is created. The user sees the result at once (with draft, even before saving). setInitialStatus uses this.
• "on modify { create; field Quantity, Price; }" — runs when an item is created or when Quantity or Price change. calculateTotal uses this, on the Item entity, and writes the total to the parent.
• "on save { create; }" — runs once, during the save sequence. setRequestID from Part 2 uses this.

Determinations must be idempotent: running twice must produce the same result. That is why setInitialStatus only sets the status when it is still initial.

━━━━━━━━━━━━━━━━━━━━
▶ VALIDATIONS
Validations always run on save and declare which operations and fields trigger them: "validation validateDescription on save { create; field Description; }". A validation reads the data, and for each broken instance it appends the key to FAILED (this stops the save) and a message to REPORTED (this tells the user why). Set %element-<field> in the message so Fiori highlights the field.
The %state_area pattern (clear first, then add the message with the same state area) matters once draft is enabled: it removes the old message when the user fixes the problem.

ACTIONS

"action ( features : instance ) approve result [1] $self;" declares an instance action that returns the updated instance. The implementation changes data through MODIFY ENTITIES IN LOCAL MODE and returns the instance in result so the UI can refresh.
An action may also refuse: submit checks that the request has at least one item; if not, it returns FAILED and a message and nothing changes.
Other action types to know: static actions (no instance, e.g. "copy from template"), factory actions (create a new instance, e.g. "copy request"), and actions with a parameter (declared with "parameter" and an abstract entity, e.g. a rejection reason).

━━━━━━━━━━━━━━━━━━━━
▶ FEATURE CONTROL
"update ( features : instance )" and "action ( features : instance ) approve" make RAP call get_instance_features before the operation and whenever the UI asks which buttons to enable. The method returns enabled or disabled per instance and per operation. Result: in Fiori the Approve button is greyed out unless the request is Submitted, and the Edit button disappears once it is Approved. If an API caller tries anyway, RAP rejects the call.
Static field control is declared directly in the BDEF: "field ( mandatory ) Description, CurrencyCode;" and "field ( readonly ) Status, TotalAmount;".

━━━━━━━━━━━━━━━━━━━━
▶ STEP BY STEP

1. Change "update;" and "delete;" on the root to "update ( features : instance ); delete ( features : instance );".
2. Add the determination, validation and action lines from the code example to the root and to the item.
3. Place the cursor on each new name and use Ctrl+1 to generate the method stubs in ZBP_R_PURCHREQ.
4. Implement the methods as shown. Always READ first, process the set, then one MODIFY.
5. Test with EML: create a request without description and COMMIT ENTITIES — you get FAILED and a message. Create one with an item, call EXECUTE submit, then approve, and read the status.

━━━━━━━━━━━━━━━━━━━━
▶ WHAT YOU HAVE AFTER PART 3
A business object with a real workflow and rules the UI will respect automatically. Part 4 makes the header-item relationship first-class with create-by-association and adds draft, so users can edit safely over a longer session.

A procurement team first put every rule inside one action called "save_and_check". It set defaults, recalculated totals, checked mandatory fields and changed status. The action worked in the UI, but the same request created through the API skipped all of it, because nobody called the action.
The fix was to split the logic by purpose. Defaults and totals became determinations, so they run no matter which channel creates the data. Mandatory checks became validations, so no channel can save invalid data. Only the explicit business steps (Submit, Approve, Reject) remained actions. The "you cannot approve your own request" check went into get_instance_authorizations, and "approved requests are read-only" went into feature control.
The UI and API then behaved identically, and support tickets about "API-created requests without totals" stopped.

• Putting derivations or checks into an action — anything not triggered explicitly will then skip them. Use determinations and validations.
• Writing non-idempotent determinations (e.g. adding 1 each time) — they can run more than once.
• Reading only the changed items when calculating a total; you must read all items of the parent.
• Appending to FAILED without a REPORTED message: the save fails and the user does not know why.
• Forgetting %element in messages, so Fiori cannot highlight the field.
• Looping over keys and calling MODIFY ENTITIES once per key instead of once for the set.
• Using feature control for "the user has no role" (that is authorization) or authorization for "the status is wrong" (that is feature control).
• Using COMMIT ENTITIES or messages with MESSAGE ... TYPE 'E' inside handler methods.

• Choose the tool by trigger: button = action, automatic = determination, block save = validation, grey out = feature control.
• Keep determination triggers narrow (specific fields), so they do not run on every change.
• Pattern for every method: one READ ENTITIES for all keys, process the table, one MODIFY ENTITIES.
• Use a message class (new_message with id/number) in production instead of hard-coded text, so messages are translatable.
• Use %state_area in validations so draft users see messages disappear once fixed.
• Return the changed instance from actions (result [1] $self) so the UI refreshes without a reload.

Classic questions: "Determination vs validation vs action?", "When does a determination on modify run vs on save?", "What is feature control and how is it different from authorization?", "What are FAILED, REPORTED and MAPPED?"
Strong answer: determinations derive values automatically (on modify in the interaction phase, on save during the save sequence), validations run on save and block it via FAILED plus a REPORTED message, and actions are explicit business operations. Instance feature control enables or disables operations based on data state; authorization decides based on the user. FAILED lists instances that failed, REPORTED carries messages, MAPPED maps %cid to the final keys. Mention bulk processing and idempotency — interviewers probe whether you know handlers receive sets of keys and that determinations can run repeatedly.