Behavior Implementations Part 2: Determinations and Validations Without Side Effects

📌 KEY POINTS
✅ Determinations recompute — never accumulate.
✅ Validations only read and report (with %state_area and %element).
✅ Read external data once for all keys.
⚠️ No commits, mails or remote calls in determinations or validations.

▶ WHERE WE ARE
Part 1 showed the structure of the behavior pool. Determinations and validations are the most frequently written methods — and the easiest to get subtly wrong.

WHAT "WITHOUT SIDE EFFECTS" MEANS
RAP decides when these methods run, and they can run more than once: several triggers in one request, draft Prepare, then save again. Therefore:

• Determinations must be idempotent: running twice gives the same result as running once.
• Validations must only read and report; they never change data.
• Neither may cause effects outside the BO: no database writes, no RFC or HTTP calls, no e-mails, no COMMIT. Such effects belong in the save phase or after the commit.

━━━━━━━━━━━━━━━━━━━━
▶ THE DETERMINATION PATTERN

1. READ ENTITIES … IN LOCAL MODE for all keys, only the fields you need.
2. Filter out instances that need no change (e.g. status already set) — this is what makes it idempotent.
3. One MODIFY ENTITIES … IN LOCAL MODE for the remaining instances.
4. Pass on messages from the MODIFY into reported if needed.

Avoid determinations that modify the fields they are triggered by; they can trigger themselves again. Keep triggers narrow ("field Quantity, Price" rather than all fields).

━━━━━━━━━━━━━━━━━━━━
▶ ON MODIFY VS ON SAVE — CHOOSE DELIBERATELY

• on modify — the user must see the value immediately (default status, calculated totals in the draft UI).
• on save — the value is needed only when the data is persisted, or must be assigned once (document numbers), or is expensive.

━━━━━━━━━━━━━━━━━━━━
▶ THE VALIDATION PATTERN

1. READ ENTITIES … IN LOCAL MODE for all keys.
2. For each instance: first append an empty message with the validation's %state_area to reported — this clears messages from earlier runs (important with draft).
3. If the rule is violated: append the instance to failed and a message to reported with the same %state_area and %element for the field.
4. For validations on children, report on the child entity (failed-item, reported-item) and, if helpful, add %path to the parent so Fiori shows it in context.

━━━━━━━━━━━━━━━━━━━━
▶ READING WHAT YOU NEED

• FIELDS ( A B ) instead of ALL FIELDS reduces work.
• To validate against other data (e.g. supplier blocked), read that data once for all keys: a SELECT from a released CDS view with FOR ALL ENTRIES (after checking the driver table is not empty) or a join — never inside the loop.
• Read related entities via association: READ ENTITIES … BY \_Item.

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

1. For every rule: determination or validation? on modify or on save? Which trigger fields?
2. Implement with the patterns above.
3. Test idempotency: run the same EML change twice and check that nothing changes the second time.
4. Test draft: fix an error and check the message disappears.

━━━━━━━━━━━━━━━━━━━━
▶ WHAT YOU HAVE AFTER PART 2
Reliable automatic logic. Part 3 covers actions and user-facing messages.

Users reported that some purchase requests showed doubled totals after editing. The determination for the total did "TotalAmount = TotalAmount + item amount" for the changed item. With draft, the determination ran several times (on item change, then again in Prepare), so the amount was added more than once.
The fix made it idempotent: always read all items of the request and recompute the total from scratch. In the same review, the team found a validation that "corrected" an empty currency by setting a default — it was moved into a determination, because validations must not change data. A regression test now runs every determination twice and compares results.

• Non-idempotent determinations (incrementing instead of recomputing).
• Determinations triggered by the fields they change, causing loops.
• Validations that modify data.
• External calls (mail, RFC, HTTP) or commits in determinations or validations.
• Not clearing messages via %state_area, so fixed errors stay visible in draft.
• SELECT SINGLE inside the loop over instances.
• FOR ALL ENTRIES without checking that the driver table is not empty.

• Read all needed data once, process the set, modify once.
• Make determinations recompute, not accumulate.
• Keep triggers narrow and deliberate (on modify vs on save).
• Validations: clear with %state_area, then report with %element.
• Read external data from released CDS views, once for all keys.
• Test idempotency and draft message behavior explicitly.

Questions: "Why must determinations be idempotent?", "Can a validation change data?", "How do you clear validation messages in draft?"
Strong answer: RAP can run determinations several times per transaction, so they must recompute rather than accumulate and should skip instances that are already correct; validations only read and report failed/reported; neither may cause external side effects. %state_area with an initial empty message clears old messages. Mention set-based reads of external data and narrow triggers.