In software architecture, nonfunctional requirements and the quality attributes of the software play a significant role. These include, for example, performance, usability, changeability, flexibility, and adaptability of software.
A software architecture should take into account the quality requirements placed on it. These determine the long-term usability and longevity of the software product. Thus, the architecture of the ABAP RESTful application programming model also brings with it certain quality attributes, some of which will be described in greater detail in this section. For SAP development teams, as well as for SAP partners and customers, there are important consequences associated with the use of the programming model.
In this post, we’ll take a closer look at the following selected quality attributes:
Software development has always strived to create software that is capable of evolution, that is, software that is (and remains) changeable in the long term and can also take into account new technical trends and developments. Technical trends usually concern the infrastructure of a business application, for example, a new UI technology or a way of storing data, rather than the business logic of the application.
Software is well adaptable to trends if its technical core hasn’t been mixed with technical coding for the infrastructure. It’s also useful to have the software provide a business-motivated API as an access point for consumers, making it usable in a variety of technical contexts. Similarly, the business core of an application should also be readily adaptable to additional business requirements. This is the case when there’s no technical coding in it.
The ABAP RESTful application programming model supports the quality attribute of evolution capability through its end-to-end declarative approach. Thanks to CDS, applications are generally independent of the underlying data source. The data model is declared exclusively at the logical level. UI annotations are also located on the logical level because with such annotations, you specify the desired functionality without having to know the concrete implementation in the UI. This makes it possible to leave annotations basically unchanged in the application, even if you later interpret them using a different UI technology.
You also declare transactional properties and business logic in the behavior definition without having to know the concrete technical implementation. Business services again abstract from the underlying runtime environment—the SAP Gateway system.
Prior to the service definition, you don’t yet reference a specific technical protocol that will be used to expose the defined entities. This reference must be established only in the service binding. From SAP’s point of view, service binding can therefore serve as an anchor point for adapting new interface technologies and protocols.
This evolutionary capability benefits not only the applications developed from scratch with the ABAP RESTful application programming model (RAP) but also the existing applications that have been encapsulated with the ABAP RESTful application programming model. Such encapsulated legacy applications can also be exposed to various interfaces and protocols using RAP means without having defined this in the legacy application itself. This also means that existing RAP applications can continue to benefit from newly supported technical functionality or interfaces (e.g., data retrieval for forms) in the future.
The quality requirements for a programming model also include efficiently supporting application developers in building applications. Thus, it’s been a long-standing endeavor of software development to relieve the burden on development teams by offering technologies and crosscutting services (e.g., UI technologies, application servers, etc.) so that they can focus on implementing the business application layer.
The ABAP RESTful application programming model supports development efficiency with the following approaches:
A model-based approach provides a formal language tailored to the specific application purpose. For example, BDL is a formal language tailored to the purpose of behavior modeling. Development objects (of the standard SAP) are generated from the source code created on the basis of the language (the model, which can also be a graphical model), or the model is evaluated generically at runtime. So, you declare the desired functionality (the “what”) and don’t have to bother about the concrete technical implementation (the “how”).
Based on the CDS data model, the ABAP RESTful application programming model is tightly integrated into the ABAP language, thereby ensuring strict typing of RAP-based interfaces (through derived data types). This allows static syntax checking and better tool support (e.g., through the code assist and element info in ADT). This in turn reduces the susceptibility to errors and the amount of research required, which benefits development efficiency.
The programming model provides standard implementations for certain application development tasks such as implementing standard operations (create, update, delete), transactional buffer management, persistence, and draft handling. You can use these standard implementations by specifying appropriate keywords in the behavior definition for the business object. This way, you can very quickly develop the first versions of a new application.
The standard implementation of OData is provided in the background by SAP Gateway, whose functionality you can access via service binding. You don’t even need to know that SAP Gateway is the technology used to do this. SAP Gateway knowledge is therefore not necessary, which has a positive effect on the number of prerequisites you need to bring along.
The programming model defines a standard vocabulary for business applications and business logic. Validations (validation), determinations (determination), and actions (action) can be used as explicit keywords in the behavior definition and are thus also included in the ABAP language scope. These concepts facilitate the communication within the development team and with subject matter experts when discussing requirements and their implementation.
Changeability has been ensured since the early days of agile development, primarily via automated testing at various levels of granularity (from individual modules to complete end-to-end applications). However, software usually can’t be tested easily. The testability quality attribute determines how easily the functionality of an application can be tested automatically by a test suite. Program code is much easier and safer to change if it has been backed up with reliable test cases using test automation tools.
The ABAP RESTful application programming model introduces the interaction phase (separate from the save sequence) and the transactional buffer. By using the ABAP RESTful application programming model, it’s difficult to “bypass” this concept during programming. The presence of the (transient) transactional buffer makes it easier to store different test data depending on the test case and to execute test cases automatically one after the other without overlapping the data areas. Tests are typically enabled by implementing test cases using the ABAP Unit testing framework, which allows you to develop and execute unit tests for your applications.
The principle of separating business and technology is an application of the separation of concerns principle. It’s necessary to develop a business logic that can be changed independently of technology, and that can be reused as permanently as possible. This principle is an important means of implementing certain quality attributes.
Business logic refers to the implementation of the application purpose of business software, that is, the program logic with which, for instance, purchasing and ordering processes are handled. The technical environment of such a domain-oriented core includes the UI and the persistence layer (e.g., the database technology used), for example.
Technological changes occur more frequently or for different reasons than changes in the application domain. Thus, the calculation of the best purchase price is independent of the logic of the technical environment, for example, the code artifacts needed to display this price on the UI or the interface and message formats needed to transmit the price to a third-party system. Software is easier to customize if the business logic is separated from the technical program logic.
With the business object’s behavior definition and implementation, the ABAP RESTful application programming model creates an explicit space for the business logic. It becomes difficult to incorporate technically motivated coding into this behavior logic, which will impact further application development steps. The programming model also defines a flow for processing standard operations or actions. This process specifies explicit points in time and interfaces, for example, to implement authorization checks, numbering, or saving business data.
Editor’s note: This post has been adapted from a section of the book ABAP RESTful Application Programming Model: The Comprehensive Guide by Lutz Baumbusch, Matthias Jäger, and Michael Lensch. Lutz has worked as an SAP developer since 2000 and has been responsible for international SAP projects in various roles and areas. At All for One Group SE, he prepares current developer topics for internal and external training in the ABAP Cloud Development team. Matthias is a freelance full-stack ABAP developer, architect, and trainer. Previously, he worked for many years at All for One Group SE in the Solution Development team, where he developed ABAP-based software products. Michael leads a team of SAP developers at All for One Group SE. As development manager, he is responsible for development in SAP S/4HANA implementation projects in Germany and abroad.
This post was originally published 7/2025.