RAP Basics Part 9: Behavior Implementation — Handler and Saver Classes

📌 KEY POINTS
✅ The behavior pool is a global class (ZBP_I_TRAVEL) that is empty by itself; the logic is in local classes in the "Local Types" tab.
✅ Handler class (lhc_travel, inherits cl_abap_behavior_handler) holds validations, determinations, actions, features and authorization methods.
✅ Saver class (lsc_zi_travel, inherits cl_abap_behavior_saver) holds the save sequence methods: finalize, check_before_save, save/save_modified, cleanup.
✅ Parameters are derived types: keys, result, failed, reported, mapped; %tky is the transactional key (includes %is_draft).
⚠️ Always use IN LOCAL MODE inside the BO — otherwise your own logic is blocked by feature control and authorization meant for consumers.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Part 7 declared validations, determinations and actions. Now we implement them.

━━━━━━━━━━━━━━━━━━━━
▶ 1. THE BEHAVIOR POOL

• Created from the BDEF quick fix; global class has no code.
• Local Types: one handler class per entity, one saver class for the BO.
• Method signatures are generated — do not type them by hand.

━━━━━━━━━━━━━━━━━━━━
▶ 2. HANDLER METHOD KINDS

• FOR VALIDATE ON SAVE: validation; fill failed and reported.
• FOR DETERMINE ON MODIFY / ON SAVE: determination; MODIFY ENTITIES IN LOCAL MODE.
• FOR MODIFY … FOR ACTION: action; return result.
• FOR INSTANCE FEATURES / FOR INSTANCE AUTHORIZATION.\n\n━━━━━━━━━━━━━━━━━━━━\n▶ 3. DERIVED TYPES AND %-COMPONENTS\n• TABLE FOR READ RESULT zi_travel\travel, TABLE FOR UPDATE …
• %tky: transactional key; %key: key only; %control: which fields are set; %msg: message; %element: field for message highlighting.

━━━━━━━━━━━━━━━━━━━━
▶ 4. FAILED AND REPORTED

• failed-travel: append %tky → the instance failed.
• reported-travel: append %tky, %msg (new_message or message class), %element-CustomerID = if_abap_behv=>mk-on.
• In draft, add a %state_area to clear old messages.

━━━━━━━━━━━━━━━━━━━━
▶ 5. SAVER CLASS

• Managed: redefine only if additional/unmanaged save.
• Unmanaged: implement finalize, check_before_save, save, cleanup.
• Never COMMIT WORK — the framework commits.

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

1. Generate the behavior pool from the BDEF.
2. Use quick fix to create all declared methods.
3. Implement validateCustomer: read, check with SELECT on customer, fill failed/reported.
4. Implement setInitialStatus with MODIFY ENTITIES IN LOCAL MODE.
5. Implement acceptTravel and return result $self.

✅ CHECKPOINT: saving a travel with an unknown customer shows the error on the Customer field and nothing is saved.

In a travel-expense BO, the team implemented acceptTravel without IN LOCAL MODE. The action worked in unit tests with a developer user but failed for approvers in quality: the status field was readonly for consumers and the approver lacked the edit authorization, so the framework rejected the action's own UPDATE. Adding IN LOCAL MODE to the MODIFY and READ statements inside the behavior pool fixed it, because internal BO logic bypasses consumer-level feature control and authorization checks. In the same review, a validation that set a default currency was split: the check stayed as a validation, the default moved into a determination.

• Missing IN LOCAL MODE in behavior pool EML, so internal updates are blocked by feature control or authorization.
• Changing data inside a validation.
• Filling reported without failed (message shown but save continues) or failed without reported (save blocked without explanation).
• Typing method signatures by hand instead of using the quick fix.
• Using COMMIT WORK or CALL FUNCTION IN UPDATE TASK directly in handler methods.

• Generate methods via quick fix; keep one handler class per entity.
• Always fill both failed and reported for rejected instances, with %element for field highlighting.
• Use IN LOCAL MODE for all EML inside the BO.
• Read only the fields you need (FIELDS ( … )), in one READ ENTITIES per method — no reads in loops.
• Put select logic for checks in bulk (FOR ALL ENTRIES or a range) when many keys arrive.

Questions: "What is a behavior pool?", "What are failed and reported?", "Why IN LOCAL MODE?"
Strong answer: the behavior pool is the ZBP_* class whose local handler classes implement validations, determinations, actions, features and authorization, and whose saver class implements the save sequence. failed marks instances that failed; reported carries messages with %element for field highlighting. IN LOCAL MODE lets internal BO logic bypass consumer feature control and authorization. Senior answers mention %tky including %is_draft and bulk processing of keys.