Behavior Implementations Part 4: Save Sequence, Late Numbering and Unmanaged Save

📌 KEY POINTS
✅ Plain managed BOs need no saver class.
✅ Late numbering → adjust_numbers; extra persistence → save_modified.
✅ save_modified runs once per successful save — ideal for change logs.
⚠️ No checks, commits or EML changes in the save phase.

▶ WHERE WE ARE
Parts 1–3 covered handler classes. The saver class (inheriting from cl_abap_behavior_saver) contains code for the save sequence. Unmanaged RAP Part 4 covers the full unmanaged saver in depth; this lesson covers the saver from the implementation-type point of view, especially for managed BOs.

━━━━━━━━━━━━━━━━━━━━
▶ THE SAVER METHODS (IN ORDER)

• finalize — last derivations; may report errors.
• check_before_save — final checks; may report errors (stops the save).
• cleanup_finalize — runs if finalize or check_before_save failed; undo derivations, keep the buffer.
• adjust_numbers — late numbering: assign final keys.
• save — unmanaged BOs: write the buffer. Point of no return.
• save_modified — managed BOs with additional save or unmanaged save: receives the changes to persist.
• cleanup — after the commit; clear buffers.

You only redefine the methods you need.

━━━━━━━━━━━━━━━━━━━━
▶ WHEN DOES A MANAGED BO NEED A SAVER?
A plain managed BO needs no saver: on-save determinations and validations are handler methods, and the framework writes the tables. You add a saver only for:

1. Late numbering → adjust_numbers.
2. Additional save → save_modified (framework also writes).
3. Unmanaged save → save_modified (framework does not write).

━━━━━━━━━━━━━━━━━━━━
▶ LATE NUMBERING IN A MANAGED BO
Declare "late numbering" in the entity header. During the interaction phase, new instances are identified by a preliminary ID (%pid) and a temporary key. In adjust_numbers, RAP passes the new instances in mapped; you assign the final key fields (for example from a number range) for each entry. Use it when numbers must be gap-free or can only be assigned once the save is certain. Drawing the number as late as possible means failed or abandoned creates never consume numbers.

SAVE_MODIFIED — ONE METHOD, TWO USES
save_modified receives three structures, one component per entity:

• create-<entity> — complete new instances.
• update-<entity> — changed instances; %control shows which fields changed. With "with full data" in the BDEF you receive all fields.
• delete-<entity> — keys of deleted instances.

Additional save: the framework already writes the BO tables; use save_modified to write something extra in the same LUW — a change log, an outbox table for events, statistics.
Unmanaged save: the framework does not write; translate the three structures into calls to the persistence API (e.g. update-task function modules).
"MAPPING FROM ENTITY" (CORRESPONDING … MAPPING FROM ENTITY) uses the BDEF mapping block to convert entity fields to table columns.

━━━━━━━━━━━━━━━━━━━━
▶ SAVE-PHASE RULES (ALL TYPES)

• No errors after check_before_save — save and save_modified must not fail.
• No COMMIT WORK, BAPI_TRANSACTION_COMMIT or ROLLBACK.
• No EML MODIFY on BOs during save; reading is fine.
• No synchronous calls that commit elsewhere; use update tasks, bgRFC, the background processing framework or business events after commit.

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

1. Decide whether you need a saver (late numbering, additional save, unmanaged save).
2. Generate the saver class with the quick fix; redefine only needed methods.
3. Implement adjust_numbers or save_modified as in the code example.
4. Test: failed validation → nothing written; successful save → change log entries exist exactly once.

━━━━━━━━━━━━━━━━━━━━
▶ WHAT YOU HAVE AFTER PART 4
The right saver for each implementation type. Part 5 covers performance, testing and debugging.

A procurement team needed an audit log of every change to purchase requests. The first implementation wrote the log inside a determination on modify — which ran several times per transaction and also for changes that later failed validation, producing duplicate and phantom log entries.
Moving the logging to save_modified with "with additional save" solved it: save_modified runs once per successful save, after all validations passed, in the same LUW as the business data. Log entries now exist if and only if the change was persisted.

• Adding a saver to a plain managed BO without a reason.
• Writing logs or follow-up data in determinations instead of save_modified.
• Performing checks in save or save_modified.
• Committing in the saver.
• Using additional save when the standard write must be replaced (that is unmanaged save).
• Forgetting that update-<entity> only contains changed fields unless "with full data" is set.
• Drawing late numbers somewhere other than adjust_numbers.

• Add a saver only for late numbering, additional save or unmanaged save.
• Use save_modified for anything that must exist exactly when the BO is saved.
• Keep save-phase code simple and failure-free; all checks before.
• Use MAPPING FROM ENTITY to reuse the BDEF mapping.
• Test failed and successful saves and verify side tables for both.

Questions: "Which saver methods exist and in which order?", "When does a managed BO need a saver?", "What is save_modified used for?", "How does late numbering work?"
Strong answer: finalize, check_before_save (cleanup_finalize on failure), adjust_numbers, save/save_modified, cleanup. Managed BOs need a saver only for late numbering, additional save or unmanaged save. save_modified receives create/update/delete per entity; additional save adds work on top of the framework's write, unmanaged save replaces it. adjust_numbers assigns final keys for instances identified by %pid during interaction.