Draft Handling

In a draft-enabled app, editing follows four steps:

1. A user chooses Edit on an existing object, or starts creating a new one. The back end creates a draft instance in a separate draft table.
2. Every change is written to the draft in the background, so nothing is lost if the browser closes.
3. Validations, field control and default values run against the draft while the user works, and messages appear before saving.
4. Save activates the draft: its content becomes the active version and the draft is removed. Discard deletes the draft instead.

The active data stays untouched until activation: a purchase requisition for Cedar Office Supply at Alder Manufacturing can be started on Friday and finished on Monday. Draft handling therefore separates work in progress from business data at the persistence level, not only in the browser.

• Exclusive draft: one user owns the draft. Only the owner can change, activate or discard it, and other users cannot see the changes before they are saved.
• Collaborative draft: several authorized users can work on the same draft at the same time. In SAP Fiori elements for OData V4, the object page shows who is in the draft and locks a field while someone types in it.

In RAP, the choice is a single keyword in the behavior definition header: with draft for exclusive or with collaborative draft for collaborative drafts. Before planning collaborative draft, check the ABAP keyword documentation of your release for the keyword. Exclusive draft remains the common case, and collaborative draft fits objects that several people complete together.

Drafts change how locking behaves. In RAP:

1. When a draft is created for an existing object, the active instance receives an exclusive lock that lasts for a set time, even if the user's session ends.
2. After that period, the draft enters an optimistic lock phase. If the owner resumes, the framework tries to lock the object again.
3. If someone changes the active object directly in the meantime, the draft becomes invalid.
4. Drafts that stay untouched are discarded automatically by a draft life-cycle service, by default after 28 days according to SAP's RAP documentation.

A total ETag field, mandatory for draft-enabled RAP business objects, detects whether the active version changed while the draft existed. Draft handling thus replaces a short session lock with a longer reservation that eventually expires.

• RAP: add the draft keyword to the behavior definition header, plus a draft table per entity and a total ETag. Draft applies to the whole business object, never to single entities. RAP supports draft from ABAP 7.55, which corresponds to SAP S/4HANA 2020.
• CAP: the annotation @odata.draft.enabled on the service entity enables draft, and the runtime handles it generically.
• Older SAP S/4HANA apps: drafts implemented with BOPF in the ABAP Programming Model for SAP Fiori still exist and can be carried into BOPF-based RAP business objects.
• SAP Fiori elements: the UI picks up draft from the service metadata. SAP states that full support for SAP Fiori elements on OData V4 services is granted only for draft-enabled scenarios. For OData V2, draft is not available on SAP NetWeaver AS for ABAP 7.50.

Draft handling is a service decision; the UI only reflects what the back end declares.

1. Treating "locked by another user" as a bug. The message usually means a colleague has an open draft. Ask the owner to save or discard it, or wait for the lock phase to end.
2. Reading the draft table directly. SAP warns that draft tables should only be accessed through the RAP framework, for example the Discard action.
3. Forgetting the total ETag. A draft-enabled RAP business object requires one.
4. Building an editable OData V4 app without draft. Users lose resume and lock information, and SAP Fiori elements offers only limited support.

Most draft handling problems come from misunderstanding the lock and lifetime rules, not from the framework.