RAP Build-Along Part 8: Managed vs Unmanaged — Choosing the Transaction Model for Your Travel App

📌 KEY POINTS
✅ The real question: who writes the data to the database — the RAP framework or your code?
✅ New custom tables → managed. Existing legacy posting logic → managed with unmanaged save or unmanaged.
✅ Business logic (validations, determinations, actions) and services look the same in all types.
⚠️ Managed on tables owned by legacy programs bypasses their rules — don't.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Parts 1–7 built a managed Travel app. In real projects you also meet existing data and legacy code. This part helps you choose the implementation type — the detailed series are Managed RAP, Unmanaged RAP and RAP Business Objects Part 2.

━━━━━━━━━━━━━━━━━━━━
▶ 1. THE FOUR OPTIONS

• Managed — RAP handles buffer, locks (with lock master), ETags, numbering (managed UUIDs) and persistence for create/update/delete. You write only business logic. Our Travel app.
• Managed with additional save — RAP persists your tables; you add extra writes in save_modified (e.g. a change log or an event).
• Managed with unmanaged save — RAP keeps the buffer, draft, locks and ETags; your save_modified calls legacy posting code instead of RAP writing the tables.
• Unmanaged — you implement buffer, CRUD, read, lock and save completely (usually wrapping existing APIs).

━━━━━━━━━━━━━━━━━━━━
▶ 2. DECISION CHECKLIST

1. New data model in own tables? → managed.
2. Need extra persistence on save (log, outbox)? → managed + additional save.
3. Data must be written by existing function modules/classes (posting rules, updates in update task)? → managed + unmanaged save.
4. Existing application must keep full control of buffer and locking? → unmanaged.
5. In doubt → choose the most managed option that respects existing rules.

━━━━━━━━━━━━━━━━━━━━
▶ 3. WHAT STAYS THE SAME
Projections, service definitions and bindings, Fiori annotations, EML consumers, authorization and feature control work identically. Switching later is possible but costly — decide deliberately.

━━━━━━━━━━━━━━━━━━━━
▶ 4. WHAT CHANGES FOR YOU

• Managed: no CRUD code; saver only if you need numbering/extra saves.
• Unmanaged save: implement save_modified mapping create/update/delete to legacy APIs (in update task, no COMMIT).
• Unmanaged: implement create, update, delete, read, lock, read-by-association and the full saver.

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

1. For the Travel app: own tables ZRAP_ATRAV/ZRAP_ABOOK → managed (as built).
2. Imagine bookings must also be posted to a legacy system table via an FM → managed with unmanaged save for bookings.
3. Write down your decision and reason in the BO documentation.

✅ CHECKPOINT: you can defend the implementation type in a design review.

A team was asked to build a Fiori app on top of an existing travel request table maintained for years by a classic transaction, which triggered approvals and wrote change documents. The first prototype used managed RAP writing directly to the table — and approvals and change documents were silently skipped.
They switched to managed with unmanaged save: RAP still handled draft, locks and ETags, while save_modified called the existing posting function in update task. All legacy rules applied again, and the app kept the modern RAP features.

• Using managed on tables written by legacy logic.
• Choosing unmanaged by default "for flexibility".
• COMMIT WORK in save methods.
• Not documenting the reason for the chosen type.
• Believing services or UI differ by implementation type.

• Decide by ownership of persistence.
• Prefer the most managed option that respects existing rules.
• Use additional save for logs/outbox, unmanaged save for legacy posting.
• Keep business logic independent of the persistence type.
• Record the decision and triggers for revisiting it.

Questions: "Managed vs unmanaged RAP?", "When do you use managed with unmanaged save?"
Strong answer: the difference is who owns persistence; managed for new own tables, additional save for extra writes, unmanaged save when legacy APIs must persist while RAP keeps buffer, draft, locks and ETags, unmanaged when legacy must control everything. Services, projections and business logic are the same; never write legacy-owned tables with managed RAP.