RAP Managed Scenario End-to-End: Draft Handling Step by Step

Why draft handling is non-negotiable

Open any modern Fiori app and notice: half-finished entries save automatically, you can leave and come back, and nothing goes live until you explicitly activate it. Users expect this everywhere now.

In RAP's managed scenario, draft is first-class: the framework generates the draft tables, the edit/activate/discard actions, and the ETag handling for you.

This post builds a complete managed business object with draft — data model to Fiori preview.

---

The four layers

• CDS data model — root entity; the framework handles the draft table once declared.
• Behavior definition — managed with draft, plus validations, determinations, actions.
• Behavior implementation — ABAP classes with your business logic.
• Service definition + binding — OData V4 exposure for the Fiori UI.

---

Step 1: The CDS data model

Define your root entity as usual — but design knowing drafts exist. Every user-editable field must be draft-enabled. The framework maintains draft administrative fields (created-by/at, changed-by/at) automatically.

---

Step 2: Behavior definition — managed with draft

The heart of it:

managed with draft;
define behavior for ZI_SalesOrder_TP
  persistent table zsalesorder
  draft table zdraft_order
  lock master
  authorization master ( instance )
{
  create;
  update;
  delete;
  field ( readonly ) OrderID;
  draft action Edit;
  draft action Activate;
  draft action Discard;
  draft action Prepare;
  validation checkOrder on save { field NetAmount; }
  determination setStatus on modify { field Status; }
}

validation ... on save runs at activation time. Users can keep inconsistent drafts — they just can't activate bad data. Exactly the UX you want.

---

Step 3: Behavior implementation

Two rules worth following:

• Validations report via failed and reported — never raise exceptions to stop a user mid-draft.
• Determinations derive values (status, totals) on modify, so the UI reflects them immediately in the draft.

---

Step 4: Service definition and binding

Expose the BO in a service definition, create the service binding (OData V4 → UI), publish.

Draft actions missing from the Fiori preview? Check the behavior definition first — nine times out of ten it's a missing with draft.

---

Step 5: Test the draft flow like a user

1. Create an object — confirm you're in a draft, not live data.
2. Enter invalid data, save — the draft should keep it (drafts tolerate inconsistency).
3. Try to activate — your on save validation should block it with a proper message.
4. Fix, activate, verify. Then test Discard.
5. Open the same object twice — check locking (lock master).

---

Gotchas to watch for

• Draft admin data — read the framework's draft admin fields; don't maintain them yourself.
• ETags — draft relies on them for optimistic locking. Custom updates must respect the ETag.
• Authorizations — authorization master ( instance ) means instance-based checks. Implement them, or draft actions fail for business users while working for your developer user.
• Managed vs unmanaged — hand-implementing create/update/delete? You probably wanted managed. Unmanaged is for exotic cases (remote APIs, non-standard persistence).

Build this once, and every Fiori app you ship afterwards gets professional-grade editing UX for free.

Stuck on a draft activation error? Describe it in the comments with your behavior definition snippet.