The fact that two database tables are involved in the runtime of a draft business object requires an elaborate life cycle of data. All data undergo several states and state transitions (actions) while being processed by a draft business object. There are two scenarios that need to be distinguished: New-Draft and Edit-Draft.

 

We speak of New-Draft instances if the data is initial data that is not yet persisted on the active database table. New-draft instances do not have a corresponding active instance.

 

The life cycle of a new-draft starts with the creation of a new draft instance. The new data is immediately stored in the draft persistence, regardless of its validity or completeness. Draft data can be enriched and checked for consistency by execution of the PREPARE action.

 

With the ACTIVATE action the draft data is copied into active data in the application buffer. ACTIVATE includes an implicit execution of PREPARE. Once the active instance is successfully created, the draft instance is discarded and the related data is deleted from the draft table.

 

Using the DISCARD action on a New-Draft will delete the related data from the application buffer and the draft table without creating an active instance.

Life-Cycle of a Draft 2 - Editing Existing Instance

 

Edit-Drafts always exist in parallel to the corresponding active data. They are created by using the EDIT action on active instances. The whole active instance is copied to the draft table.

 

Like New-Drafts, Edit-Drafts can be enriched and validated using the PREPARE action.

 

With the ACTIVATE action the draft data is copied to overwrite the existing active data in the application buffer. As with New-Drafts, ACTIVATE includes an implicit execution of PREPARE.

 

Using the DISCARD action on an Edit-Draft will delete the draft data from the application buffer and the draft table, leaving the active data in the application buffer unchanged.

 

Draft Tables

Quick Fix to Generate Draft Database Table

 

Draft business objects need two separate database tables for each entity, one for the active persistence and one for storing draft instances. With using a separate database table for the draft information, it is guaranteed that the active persistence database table remains untouched and consistent for existing database functionality.

 

While the persistent table addition is used to specify the active table of a RAP BO entity, the draft table is assigned via the draft table addition. The draft table addition is mandatory in every behavior definition statement as soon as the RAP BO is draft-enabled.

 

The draft table can be generated automatically via a quick fix in the behavior definition. If the draft database table already exists, the quick fix completely overwrites the table.

Draft Database Table Layout

 

The draft database table contains exactly the same fields as the active database table plus some technical information the RAP runtime needs to handle draft. The technical information is added with the draft admin include SYCH_BDL_DRAFT_ADMIN_INC.

 

Concurrency Control in Draft

Pessimistic Concurrency Control in Draft

 

RAP uses a combination of pessimistic and optimistic concurrency control to ensure data consistency.

In scenarios with draft support, the pessimistic concurrency control (locking) plays an even more crucial role during the draft business object life cycle.

 

As soon as a draft instance is created for an existing active instance, the active instance receives an exclusive lock and cannot be modified by another user. The exclusive lock is not bound to the ABAP session. It remains intact between the different update requests from the same user. When the user saves or discards the changes, the draft is deleted and the exclusive lock is removed.

Optimistic Concurrency Control in Draft