Preface
This blog describes the differences between classic ABAP programming and ABAP Cloud programming with regards to the SAP Logical Unit of Work (SAP LUW)
[1] and the ABAP RESTful application programming model (RAP). It helps to understand how database updates work and what developers must consider avoiding data inconsistencies during database updates.
Classic ABAP Programming
In typical business applications, the data is changed, further changes are derived, and the data is verified. If the resulting state based on these changes is consistent from an application point of view, the changes are finally committed to the database. All changes made are committed with one atomic database transaction following the ACID
[2] paradigm.
To achieve this, SAP provides the SAP Logical Unit of Work (SAP LUW) for classic ABAP programming. As the database is the central resource and can become a bottleneck, the processing and handling is done on the ABAP application server. Therefore, the data changes are not directly written to the database but kept in local temporary tables or buffers and are then jointly written to the database, either directly or via SAP update task. The SAP LUW terminates by calling COMMIT WORK if all changes were done successfully, or by calling ROLLBACK WORK if not.
Processing the COMMIT WORK statement includes:
- the update task processing.
- a database commit of the primary database connection.
- starting of further asynchronous processing (e.g., via background RFCs) or registering on the transaction end events to clean up the buffers and prepare for the next SAP LUW in the same ABAP session.
When a ROLLBACK WORK statement is processed all changes are discarded, the current SAP LUW is terminated and a new one is opened.
Why is there an Update Task in classic ABAP programming?
The recommendation for classic ABAP programming is to always use update task function modules to perform modifying database operations, due to mainly three reasons:
- In the past, database updates had a significant impact on the end-user performance. The update task offered an option to perform the (real) actual database changes asynchronously. This helped improving the perceived end-user performance.
- Data consistency was not always given because proper isolation of database modifications was not available for all databases supported by SAP at that time. This means, that uncommitted database modifications were visible to other transactions although not finally committed.[3]
- The SAP LUW is confirmed with an explicit COMMIT WORK But, as will be explained in the next section, the ABAP Platform sometimes invokes implicit database commits on the primary database connection. If data was already written before to the database, then the implicit database commit would result in multiple database transactions (database LUW) within one SAP LUW which violates the ACID paradigm.
Why are there implicit database commits?
The ABAP Platform scales via load balancing and multiple application server instances. In the cloud, these can be added and removed on demand. The number of work processes of an ABAP application server is limited, and their usage optimized. If a work process needs to wait (idle), e.g., when waiting for user interaction or remote connection, the work process is released for a different workload. This is done by saving (also called rolling-out) the current workload context and releasing the resources. This approach requires a database commit. It also explains why a synchronous RFC (sRFC), calling a WAIT statement (e.g., for asynchronous tasks via asynchronous RFC (aRFC)) or the invocation of an HTTP request via HTTP client leads to a database commit - as it might take a while until these requests return and the program can continue, and it is usually not known upfront how long it takes.
What about secondary database connections?
Database modifications and commits - on service connections or via secondary database connections - are allowed within the SAP LUW. These connections are usually used by technical components, e.g., for fetching the next bunch of numbers of a buffered number range, or for persistent caches, traces, logs or similar.
ABAP Cloud Development Model
In the ABAP Cloud development model, the classic update task is not offered anymore. The reasons for the usage of an update task, as mentioned in the chapter before, are not applicable anymore:
- Writing directly to the database tables is no bottleneck anymore, as database processing on SAP HANA is much faster.
- SAP HANA as the only supported database provides full isolation, thus preventing dirty read.
- Implicit database commits are no issue anymore if database modifications are triggered as late as possible, ensuring that afterwards no database commit except via COMMIT WORK is invoked.
Nevertheless, data changes are still done in the buffers of the application server. The data is enriched, verified, and finally saved to the database.
It cannot be prevented that implicit database commits happen before saving the data to the database, as calling remote services (e.g., via sRFC or HTTP client) is still possible. Consequently, modifying database operations are only allowed at the end of the SAP LUW.
Furthermore, once the end of the SAP LUW is reached and the modifying database operations are invoked, all operations that lead to an implicit database commit are not allowed anymore, as these would disrupt the consistency and atomicity (ACID).
Obviously, the explicit database commit on the primary database connection is only allowed to finally terminate the SAP LUW, but not before. Also, the pattern to start further asynchronous processing is still needed and valid (e.g., via
bgPF).
This requires to strictly follow these rules from application development to avoid inconsistencies due to multiple database LUWs.
How is this handled in the ABAP RESTful Application Programming Model (RAP)?
Compared to classic ABAP programming, RAP is a more advanced application programming model with further abstraction. RAP controls the transactions (ABAP LUW) and provides an orchestration with clearly defined phases, namely:
- the interaction phase,
- the early-save phase,
- the late-save phase followed by a cleanup.
The RAP transaction model is described in more detail in the RAP documentation
(
The RAP Transactional Model for the SAP LUW).
Based on this transaction model, the rules, and guidelines of the SAP LUW can be manifested by runtime checks. With these checks in place, you can avoid data inconsistencies or race conditions.
The following violations will always lead to a runtime error in a RAP context:
- Explicit use of COMMIT WORK or ROLLBACK WORK statements, as the transaction handling and database commit is exclusively handled by RAP.
- Calling the update or background task (bgPF) in the interaction phase or early-save phase.
Some other operations only lead to runtime errors, if the RAP behavior definition is implemented in ABAP for Cloud Development and the strict(2)-mode
[4] is applied:
- Invoking authorization checks in the early-save or late-save phase.
- Modifying database operations in the interaction phase or early-save phase.
- Raising business events in the interaction phase or early-save phase.
- (Implicit or explicit) database commits for the primary database connection in the late-save phase.
Conclusion
The ABAP RESTful Application Programming Model supports you in following the rules to avoid issues with transactional consistency caused by modifying statements or database commits in the wrong sequence / phase.
Feel free to share your feedback or thoughts by commenting this BLOG.
With the information provided here you also get an understanding on how and where BAPIs can be used in RAP as described in
Using BAPIs in RAP provided by my colleague
marcel.hermanns.
Follow for more via
renzo.colle.
[1] A sequence of programming steps and data updates, whose database changes are updated within a single database commit.
[2] ACID (atomicity, consistency, isolation, durability), check also
https://en.wikipedia.org/wiki/ACID.
[3] Also known as
dirty read.
[4] The strict mode adds additional consistency checks during development so that to the RAP behavior definition is developed life cycle stable.
