Draft Motivation

Stateful Technologies - One Server Session

 

SAP traditional applications are developed using stateful technologies, such as Floorplan Manager for Web Dynpro ABAP or the classic Dynpro technique.

 

These stateful transactional applications rely on a server session along with application buffers that can fulfill client requests (user interactions with multiple backend round trips) until the user has saved the data changes and finished their work. In stateful applications, data entry and data updates work on a temporary in-memory version of a business entity which is only persisted once it is sufficiently complete and consistent.

 

Stateless Technologies - Many Individual Sessions

 

Modern cloud-ready apps require a stateless communication pattern, for example, to leverage cloud capabilities like elasticity and scalability. Therefore, there is no fixed backend session resource along a business transaction for each user and the incoming requests can be dispatched to different backend resources, which supports load balancing. As a consequence, the application cannot save a temporary version of the business entity inside the application.

 

Stateless Technologies - Non-draft Scenario

 

The ABAP Restful Application Programming Model follows such a stateless approach. The application does not save temporary versions on the application server. The application performs checks, actions, and so on, but the changes to the data are only saved once the user chooses Save. This is referred to as the non-draft scenario.

 

Solution: Draft Persistence on DB

 

Both the stateful approach and the non-draft approach have one big disadvantage, the end user cannot store changed data that is inconsistent to continue at a later point in time or to recover this data, even if the application terminates unexpectedly.

 

The draft scenario replaces the temporary in-memory version of the business entity with a persistent version on the database. This persistent temporary version is known as draft. It is not stored in the same database tables as the active versions but in special database tables, the Draft Tables. The draft represents the state and stores the transactional changes until they are persisted in the active table or discarded.

What is a Draft?

Draft Enabled RAP Business Objects

Enable Draft in Behavior Definition

 

The draft capability for a draft business object is defined by adding the statement with draft; in the header part of the behavior definition. You can build draft business objects from scratch, or you can draft-enable existing business objects with both implementation types, managed or unmanaged.

 

Draft Enabled Business Objects

 

In all scenarios, the draft is managed. This means that the draft life cycle is determined by the RAP draft-runtime as soon as the business object is draft-enabled. You, as an application developer, do not need to know how the draft instance is created, how draft data is written to the draft database table, or how the draft instance is activated.

 

Adding draft capabilities to your business object might imply changes in your business logic for the processing of active data that you are responsible for. In addition, RAP also offers implementation exits for cases in which you need business service-specific draft capabilities that impact the draft handling.

Life-Cycle of Draft 1 - Creating New Instance