RAP Basics Part 4: Implementation Types — Managed, Unmanaged, Additional Save and Unmanaged Save

📌 KEY POINTS
✅ Managed: the framework provides the transactional buffer, CRUD and the save to your own tables — you add only business logic.
✅ Unmanaged: you implement create/update/delete, read, lock and save yourself — used to wrap existing application logic (BAPIs, function modules).
✅ Managed with additional save: framework saves, you add extra saving (change documents, application log, outbound calls) in save_modified.
✅ Managed with unmanaged save: framework handles the buffer and interaction phase, but you write the data yourself (e.g. via a legacy update function).
⚠️ Choosing unmanaged for a new BO with its own tables multiplies code and bugs for no benefit.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Parts 2–3 built the data model and projection. Now the key architectural decision: who does the transactional work?

━━━━━━━━━━━━━━━━━━━━
▶ 1. MANAGED

• Header: managed implementation in class zbp_i_travel unique;
• persistent table ztravel_a — the framework reads, buffers and writes.
• Numbering, locking, ETags, draft all supported out of the box.
• Best for greenfield BOs with their own Z tables.

━━━━━━━━━━━━━━━━━━━━
▶ 2. UNMANAGED

• Header: unmanaged implementation in class zbp_i_salesorder unique;
• You implement create/update/delete/read/lock in handler classes and finalize/check_before_save/save/cleanup in a saver class.
• Your code maintains its own buffer (usually a static attribute in a buffer class).
• Typical: wrap BAPI_SALESORDER_CREATEFROMDAT2 to expose standard sales orders.

━━━━━━━━━━━━━━━━━━━━
▶ 3. MANAGED WITH ADDITIONAL SAVE

• with additional save in the BDEF entity.
• Framework saves normally; your saver method save_modified runs in the same LUW for extra writes.
• Use for change documents, application log, triggering an outbound event.

━━━━━━━━━━━━━━━━━━━━
▶ 4. MANAGED WITH UNMANAGED SAVE

• with unmanaged save — no persistent table; you write in save_modified.
• Keeps managed buffer, draft and numbering benefits while the data lands via legacy update logic.

━━━━━━━━━━━━━━━━━━━━
▶ 5. DECISION MATRIX

• New Z tables, no legacy logic → managed.
• New Z tables + need change docs/logging → managed with additional save.
• Existing tables written only by legacy update FMs → managed with unmanaged save.
• Existing complete logic in BAPIs, including checks → unmanaged.
• Remember: in S/4HANA many standard objects already have released RAP BOs — check before wrapping BAPIs.

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

1. List the BO's tables and who owns their update logic today.
2. Pick the implementation type from the matrix.
3. Set the BDEF header and the save option.
4. Generate the behavior pool and implement only what the type requires.

✅ CHECKPOINT: you can defend your implementation type in a design review with one sentence per alternative.

A client moving from ECC to S/4HANA wanted a Fiori app to create customer returns. The first design was fully unmanaged, re-implementing buffer, locks and save around BAPI_CUSTOMERRETURN_CREATE — about 2,000 lines of handler code. The architect first checked the API Business Hub and found the released RAP BO for customer returns (I_CustomerReturnTP), which could be consumed with EML from a small custom BO. Where no released BO existed (a custom rebate agreement table maintained by legacy update function modules), the team used managed with unmanaged save, keeping draft and locking from the framework and calling the legacy update module in save_modified. Custom code shrank by around 70%.

• Choosing unmanaged for a brand-new BO with its own tables.
• Wrapping a BAPI in unmanaged RAP when SAP already delivers a released RAP BO for the object.
• Calling COMMIT WORK inside save or save_modified — the framework controls the LUW.
• Doing extra writes in a determination instead of save_modified.
• Forgetting the buffer class in unmanaged scenarios, so read after create returns nothing.

• Default to managed; move to hybrids only for a concrete need.
• Check released RAP BOs and APIs before wrapping BAPIs.
• Keep unmanaged buffers in a dedicated singleton buffer class.
• Put side writes (logs, change documents) in save_modified of an additional save.
• Document the chosen type and the reason in the design document.

Questions: "Managed vs unmanaged RAP — when do you use which?", "What is managed with additional save?", "How would you expose an existing BAPI-based process in RAP?"
Strong answer: managed for new BOs on own tables; unmanaged when existing application logic (BAPIs) must own create/update/save; managed with additional save for extra side effects; managed with unmanaged save when the framework should run the interaction phase but data must be written by legacy update logic. A senior candidate first checks for a released SAP RAP BO before wrapping a BAPI and never commits inside the save sequence.