RAP Draft Handling: Draft Tables and Locking

Draft handling is the RAP mechanism that lets a user start editing a business object instance, walk away from the browser, come back, and resume exactly where they left off, without any changes touching the active table until an explicit activate step. The structural fact behind almost every confusion: every draft-enabled entity gets its own generated draft table, separate from the active table, holding a copy of the instance plus draft administration fields such as a draft UUID and last-changed-by information. The 'lock' a user holds on a record is not a classic ABAP enqueue tied to a dialog work process or an update task. It is a row sitting in the draft table, which survives across stateless OData requests. That is exactly why it needs explicit management through generated actions to edit, activate, discard and resume, and why it can outlive the browser session that created it if nobody calls discard.

Draft is the right fit for any Fiori elements object page that needs a distinct Edit mode with Save and Cancel, for objects where validations should only fire at a defined point rather than on every keystroke, and for multi-step edit flows where a user might legitimately need to leave and come back to an unfinished document. It is also useful wherever the UI needs to show other users that a record is currently being worked on. It is the wrong tool for value-help entities, pure reporting or analytical consumption, read-only list apps, and simple master data maintained through a single-shot create or update with no intermediate editing state. Reaching for draft there just adds a second table, extra determinations, and doubled write volume for no behavioral benefit.

Draft sits between the EML layer and behavior implementation below it, and the Fiori elements object page above it. The behavior definition declares the object as draft-enabled and the framework generates the draft table and the standard draft actions; the developer wires in draft determine actions and save-prepare validations. Fiori elements consumes the generated Edit, Activate, Discard and Resume actions automatically and renders the corresponding buttons without custom UI5 coding. Draft supersedes older manual patterns where a developer built a shadow buffer or Z-table to hold in-progress edits, and it replaces reliance on classic transactional locks as the sole edit-in-progress indicator. It does not remove classic enqueue locking entirely; the active instance is still protected by a standard lock at the point of activation.

A travel booking business object is modeled with a root node for the booking header and a child node for booking items. The behavior definition marks the root 'with draft' and generates the draft table alongside the standard actions. A save-prepare validation checks that the booking has at least one item and that the total price is populated before activation is allowed. A user opens the object page, the framework calls Edit, which copies the active instance into a new draft row with a fresh draft UUID. Every subsequent PATCH from the UI updates the draft row, not the active table. The user adds two booking items, closes the browser, and returns an hour later; Resume reloads the same draft row because it is keyed by draft UUID rather than by session. On Activate, the save-prepare determination runs, the framework copies the validated draft content into the active table and the child table, then deletes the draft rows for both nodes. If the child node had not been enabled for draft, item edits would have written straight to the active table while the header stayed pending, producing a document that is inconsistent between header and items.

Draft handling is a native part of the RAP and CDS-based Fiori elements stack on S/4HANA and is considerably lighter than the older BOPF-driven draft mechanisms used by earlier generations of Fiori apps. From a clean core standpoint, draft is a standard, framework-generated capability configured through the behavior definition rather than custom code, which keeps it upgrade-safe as long as the draft actions are used through their intended hooks. Building a parallel hand-rolled buffering mechanism to mimic draft behavior, instead of enabling the framework's own draft table generation, is the anti-pattern to avoid; it defeats the point of the feature and creates exactly the kind of custom persistence layer clean core principles are meant to discourage.

Development owns the behavior definition draft annotations, the draft table configuration, and the determine and validation logic tied to save-prepare and activation. Architecture decides whether a given business object justifies the extra table and complexity given its edit UX and concurrency profile. Functional consultants define what the edit and approval process should look like, including how long an unfinished draft is expected to remain valid.

Read the behavior definition and implementation page for how draft actions are declared and where determine and validation hooks live. The managed versus unmanaged scenarios page explains why draft integrates far more cleanly with managed implementations. The Fiori elements list report and object page reference shows how draft actions map onto generated Edit, Save and Cancel buttons without custom UI5 code. The concurrency control page is worth checking wherever draft and ETag-based locking interact on activation.