Background
Having worked with ABAP RAP for over quite some years now and after taking quite a few technical interviews, what I observed from my experience is that many developers still struggle to fully understand what happens inside the ABAP RAP runtime — especially around transactional buffering, EML execution, and commit/rollback behaviours.
Hence setting the context of this blog.
➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️
Introduction
The ABAP RESTful Application Programming Model (RAP) is the foundation for building modern, cloud-ready, and transactional applications on SAP BTP ABAP Environment and SAP S/4HANA.
Crucial to its understanding is about its runtime and hence in this blog, we will touch upon and break down the following concepts in an ntuitive way:
RAP Runtime FlowRAP Transactional Buffers (Draft & Active)
Let’s start from the foundation.
➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️
ABAP RAP Runtime — The Invisible Engine
When you build a transactional application with RAP, a lot happens behind the scenes in what we call the RAP runtime engine. It’s “invisible” because you rarely write code for many of its steps — but knowing what it does is key to debug & optimise.
The RAP runtime is responsible for orchestrating everything that happens when you call an action, modify data, run validation/determinations, or commit a business object.
Key responsibilities of RAP runtime:
Provides draft handlingMaintains transactional buffersRuns determinations/validations/actions in the right orderEnsures ACID properties for business transactionsConsolidates errors, warnings, and messages through REPORTED structureWrites data to the database only after commit
The most important thing to understand: RAP never directly updates the DB during EML calls. Everything goes into the RAP transactional buffer first.
Here’s how the runtime engine typically handles a transactional request (e.g., modify, create, action on a BO):
Receive Request
The service binding/OData call enters the RAP runtime. The runtime frameworks dispatch this to the correct BO implementation.Interaction Phase: Loading & BufferingIf the request references existing data, the runtime loads the existing BO instance into the transactional buffer.If it’s new data, buffer is prepared accordingly with new instance(s).All modifications (via EML) are made against the buffer, not directly the database.This phase may include edit/draft handling, business logic, change of states.Save Sequence Trigger
Once the interaction phase completes (i.e., no more immediate edit tasks), the runtime triggers the Save Sequence.Consistency Checks & Late LogicThe runtime runs final determinations, validations to ensure data integrity.Any failures here cause rollback of buffer (no DB write).Then key generating logic (late numbering etc) happens if required.Database Write & Buffer Clean-upThe buffered changes are persisted and the transactional buffer is cleaned up.
The runtime returns results (FAILED / REPORTED / MAPPED) to the caller.
The runtime can also be further divided into Standard Operations and Non-standard Operations Runtime based on the operation types.
Source : help.sap.com
➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️
ABAP RAP Transactional Buffers
The ABAP RESTful Application Programming Model (RAP) does not introduce its own LUW concept, but uses the rules and concepts of the SAP LUW and thus does inherent checks ensure that your application is consistent and stable, also when more than one BO is involved.
RAP uses an internal transactional buffer (in-memory layer) to temporarily hold all data modifications.
It is the key “scratch‐pad” where all modifications happen before anything goes to the database. Think of it like a workspace for your BO operations.
Every operation (create, update, delete, action) targets an instance in the buffer first. The buffer is internal to RAP runtime — you don’t explicitly manage it, you just use EML and commit/rollback.
Why it matters
It ensures isolation: multiple requests don’t interfere until commit.It provides a stage for determinations/validations before final write.It allows draft mode: you can work on data in draft buffer without touching active DB immediately.It ensures you can rollback if something fails without partial DB updates — ACID in practise.
Here’s how you visualise it:
Buffer Behaviour in Different Modes:
There are two types of buffers Draft Buffer/Draft Runtime & Active Transactional Buffer. Let’s break them down.
Active Transactional Buffer – The In-Memory DB-Staging Area
The Active Transactional Buffer is used when you work on active instances (not in draft mode).
This handles all temporary changes for active data until COMMIT ENTITIES.No draft tables involved.
When It Is Used
When your BO is not draft-enabled.When your BO is draft-enabled but you are working on active instances (e.g., %is_draft = 00).When triggering actions that operate on active data.
What Happens on COMMIT
At COMMIT, RAP takes all pending changes from the transactional buffer, runs validations and determinations, executes the save sequence, and finally writes everything to the database.
Draft Buffer aka Draft Runtime– Your Temporary Workspace
The Draft Buffer is a staging area inside the RAP runtime that stores unsaved, in-progress work of a user managed by Draft Runtime.
Since RESTful applications require a constant stateless communication with the backend to prevent that transient data is lost when a user session ends, drafts are essential.
Here, for new-draft & edit-draft instances, data gets updates in Draft Database tables only upon COMMIT ENTITIES.
Only on ACTIVATE, it gets converted into Active Instance in a Active Transactional Buffer and then gets persisted to database table on COMMIT ENTITIES.
When It Is Used
When you run MODIFY ENTITIES … ENTITY <X> CREATE with draft modifier,When you trigger draft actions:When you read draft-specific elements.
What Happens on COMMIT
At activation, RAP takes the draft buffer data, runs validations and determinations, executes the save sequence, deletes the draft, and promotes the changes to active database records
The One-Liner Summary:
Active Mode: COMMIT ENTITIES takes the delta from the transactional buffer → validates → determines → writes to DB → commits → clears buffer. Draft Mode: ACTIVATE promotes data to active instance → COMMIT ENTITIES runs the full save sequence → deletes draft → commits.
Source: help.sap.com
➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️
What about ROLLBACK ?
1. Discards entire buffer
→ The runtime clears all staged changes.
2. No DB write/rollback
→ Nothing is persisted/rolled back to/from the database.
3. No further validations/actions
→ All remaining processing is immediately stopped.
4. Restores consistent state
→ System returns to a clean, stable state.
➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️
Conclusion
If you’ve reached this far, you may now have a clear inside-out view of how ABAP RAP’s runtime and transactional buffers really work.
To wrap up, the runtime is all about buffers, orchestration, and guaranteed consistency.
Understanding this invisible engine not only helps you debug confidently but also helps you design cleaner, safer, more predictable business objects.
If this blog helped even a little bit in strengthening that foundation, then mission accomplished !
Keep exploring, keep building ! 🙂
Regards,
Subhajit
BackgroundHaving worked with ABAP RAP for over quite some years now and after taking quite a few technical interviews, what I observed from my experience is that many developers still struggle to fully understand what happens inside the ABAP RAP runtime — especially around transactional buffering, EML execution, and commit/rollback behaviours.Hence setting the context of this blog.➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️IntroductionThe ABAP RESTful Application Programming Model (RAP) is the foundation for building modern, cloud-ready, and transactional applications on SAP BTP ABAP Environment and SAP S/4HANA.Crucial to its understanding is about its runtime and hence in this blog, we will touch upon and break down the following concepts in an ntuitive way:RAP Runtime FlowRAP Transactional Buffers (Draft & Active)Let’s start from the foundation.➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️ABAP RAP Runtime — The Invisible EngineWhen you build a transactional application with RAP, a lot happens behind the scenes in what we call the RAP runtime engine. It’s “invisible” because you rarely write code for many of its steps — but knowing what it does is key to debug & optimise.The RAP runtime is responsible for orchestrating everything that happens when you call an action, modify data, run validation/determinations, or commit a business object.Key responsibilities of RAP runtime:Provides draft handlingMaintains transactional buffersRuns determinations/validations/actions in the right orderEnsures ACID properties for business transactionsConsolidates errors, warnings, and messages through REPORTED structureWrites data to the database only after commitThe most important thing to understand: RAP never directly updates the DB during EML calls. Everything goes into the RAP transactional buffer first.Here’s how the runtime engine typically handles a transactional request (e.g., modify, create, action on a BO):Receive RequestThe service binding/OData call enters the RAP runtime. The runtime frameworks dispatch this to the correct BO implementation.Interaction Phase: Loading & BufferingIf the request references existing data, the runtime loads the existing BO instance into the transactional buffer.If it’s new data, buffer is prepared accordingly with new instance(s).All modifications (via EML) are made against the buffer, not directly the database.This phase may include edit/draft handling, business logic, change of states.Save Sequence TriggerOnce the interaction phase completes (i.e., no more immediate edit tasks), the runtime triggers the Save Sequence.Consistency Checks & Late LogicThe runtime runs final determinations, validations to ensure data integrity.Any failures here cause rollback of buffer (no DB write).Then key generating logic (late numbering etc) happens if required.Database Write & Buffer Clean-upThe buffered changes are persisted and the transactional buffer is cleaned up.The runtime returns results (FAILED / REPORTED / MAPPED) to the caller.The runtime can also be further divided into Standard Operations and Non-standard Operations Runtime based on the operation types.Source : help.sap.com➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️ABAP RAP Transactional BuffersThe ABAP RESTful Application Programming Model (RAP) does not introduce its own LUW concept, but uses the rules and concepts of the SAP LUW and thus does inherent checks ensure that your application is consistent and stable, also when more than one BO is involved.RAP uses an internal transactional buffer (in-memory layer) to temporarily hold all data modifications.It is the key “scratch‐pad” where all modifications happen before anything goes to the database. Think of it like a workspace for your BO operations.Every operation (create, update, delete, action) targets an instance in the buffer first. The buffer is internal to RAP runtime — you don’t explicitly manage it, you just use EML and commit/rollback.Why it mattersIt ensures isolation: multiple requests don’t interfere until commit.It provides a stage for determinations/validations before final write.It allows draft mode: you can work on data in draft buffer without touching active DB immediately.It ensures you can rollback if something fails without partial DB updates — ACID in practise.Here’s how you visualise it: Buffer Behaviour in Different Modes:There are two types of buffers Draft Buffer/Draft Runtime & Active Transactional Buffer. Let’s break them down. Active Transactional Buffer – The In-Memory DB-Staging AreaThe Active Transactional Buffer is used when you work on active instances (not in draft mode).This handles all temporary changes for active data until COMMIT ENTITIES.No draft tables involved.When It Is UsedWhen your BO is not draft-enabled.When your BO is draft-enabled but you are working on active instances (e.g., %is_draft = 00).When triggering actions that operate on active data.What Happens on COMMITAt COMMIT, RAP takes all pending changes from the transactional buffer, runs validations and determinations, executes the save sequence, and finally writes everything to the database. Draft Buffer aka Draft Runtime– Your Temporary WorkspaceThe Draft Buffer is a staging area inside the RAP runtime that stores unsaved, in-progress work of a user managed by Draft Runtime.Since RESTful applications require a constant stateless communication with the backend to prevent that transient data is lost when a user session ends, drafts are essential.Here, for new-draft & edit-draft instances, data gets updates in Draft Database tables only upon COMMIT ENTITIES.Only on ACTIVATE, it gets converted into Active Instance in a Active Transactional Buffer and then gets persisted to database table on COMMIT ENTITIES.When It Is UsedWhen you run MODIFY ENTITIES … ENTITY <X> CREATE with draft modifier,When you trigger draft actions:When you read draft-specific elements.What Happens on COMMITAt activation, RAP takes the draft buffer data, runs validations and determinations, executes the save sequence, deletes the draft, and promotes the changes to active database recordsThe One-Liner Summary: Active Mode: COMMIT ENTITIES takes the delta from the transactional buffer → validates → determines → writes to DB → commits → clears buffer. Draft Mode: ACTIVATE promotes data to active instance → COMMIT ENTITIES runs the full save sequence → deletes draft → commits.Source: help.sap.com➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️What about ROLLBACK ?1. Discards entire buffer→ The runtime clears all staged changes.2. No DB write/rollback→ Nothing is persisted/rolled back to/from the database.3. No further validations/actions→ All remaining processing is immediately stopped.4. Restores consistent state→ System returns to a clean, stable state. ➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️⬅️ConclusionIf you’ve reached this far, you may now have a clear inside-out view of how ABAP RAP’s runtime and transactional buffers really work.To wrap up, the runtime is all about buffers, orchestration, and guaranteed consistency.Understanding this invisible engine not only helps you debug confidently but also helps you design cleaner, safer, more predictable business objects.If this blog helped even a little bit in strengthening that foundation, then mission accomplished !Keep exploring, keep building ! 🙂 Regards,Subhajit Read More Technology Blog Posts by SAP articles
#SAP
#SAPTechnologyblog
