To support developers, SAP has provided programming models to help organizations meet their business needs and to help make coding more efficient. These models have changed over the years as requirements and technologies have changed — from the longtime Dynpro and list programming models for SAP GUI-based applications, to the business server pages and Web Dynpro model for web-based development, to the ABAP programming model for SAP Fiori to support SAP HANA-optimized development for SAP Fiori. With the user experience taking center stage in a constantly evolving business landscape, a flexible and efficient model that optimally supports SAP Fiori, SAP HANA, and sophisticated technologies has become a pressing need. While the ABAP programming model for SAP Fiori provides this support to some extent, it lacks certain qualities that are essential for efficient development, such as simplicity and typed access to business entities. To fill the gap, SAP now offers the ABAP RESTful programming (RAP) model (the RAP abbreviation, which originally stood for RESTful ABAP programming model, is widely used in the ABAP community). The RAP model provides an intrinsic approach to building SAP Fiori applications in ABAP that are optimized for SAP HANA and run both in the cloud and on premise. The building blocks of the RAP model are core data services (CDS) enriched with transactional behavior that are exposed as REST-based OData services for easy consumption in SAP Fiori templates. This article introduces the existing traditional ABAP developer community to the basic principles and philosophies of the RAP model so they can hit the ground running and quickly start taking advantage of its benefits. It first looks at the evolution of the ABAP programming model, and then explains how the RAP model works. Finally, it walks through an example scenario that demonstrates what development using the RAP model looks like. Before examining the RAP model itself, it will be helpful to understand how the ABAP programming model has evolved over time, so that developers who have experience with SAP Fiori development in ABAP can better understand how to leverage their existing assets with this model.  

The Evolution of the ABAP Programming Model

Figure 1 provides an overview of how the ABAP programming model has evolved over time to meet changing business requirements. Let’s take a closer look at how it has changed over the years.   Figure 1 — The evolution of the ABAP programming model  

Traditional ABAP Programming Models

The original ABAP programming models were the longtime, well-known traditional models — such as Dynpro and list programming for developing SAP GUI-based applications and business server pages and Web Dynpro for web-based development — which were available with release 7.5 and earlier of the ABAP platform. With these models, development started with a basic data model consisting of data dictionary domains, data elements, and tables. Foreign key definitions were used for referential integrity, and the ABAP logic was expressed in module pools, function modules, and ABAP classes and interfaces. These programming models were designed for the traditional on-premise world and delivered significant value to customers through efficiency, robustness, and support for a state-of-the-art user interface (UI) on top of traditional relational database systems, often called “anyDB” in the SAP context. However, these models were highly optimized for complete server-side processing on the ABAP application server. A major ABAP programming innovation in recent years was the introduction of CDS to optimally utilize the capabilities of SAP HANA for ABAP application development. Delivered with the ABAP stack as of SAP NetWeaver 7.4, CDS in ABAP forms a semantic data model consisting of views, which define the data model, and associations, which define the relationships between CDS views. CDS views are augmented with annotations, which describe how the application’s UI should interpret the data — for example, SAP Fiori templates consume annotations to determine the application’s layout and navigational flow. Since CDS views are read only, these applications were limited, however — for instance, they could not perform transactional operations. In addition, developers had to manually implement the SAP Gateway services as OData services to be consumed by the SAP Fiori applications. With SAP Fiori designated as the UI technology for SAP applications going forward, the need arose for a new programming model to better support this type of development.  

The ABAP Programming Model for SAP Fiori

To meet this need, SAP delivered the ABAP programming model for SAP Fiori, which is available with release 7.5 and higher of the ABAP platform. This model reduces coding complexity with the concept of a reference data source, which is an SAP Gateway Service Builder (transaction SEGW) option that enables the underlying framework to implement SAP Gateway services as CDS views, which can later be exposed as OData services. In addition, the model includes services to support transactional applications. These transactional services are enabled by special annotations that define the link between a CDS definition and a corresponding Business Object Processing Framework (BOPF) model, which is automatically generated and supports transaction-oriented behavior via artifacts — such as validations, determinations, and actions — that you can implement in ABAP. While this approach helped fill the gaps on the transactional side, it suffered from some drawbacks. Both CDS and BOPF are modeling frameworks, which means that you must maintain both in parallel. They also have very different natures: CDS is a strongly typed framework embedded into the ABAP designtime and runtime with type checking at designtime. In contrast, BOPF, which was invented earlier than CDS, is a very generic ABAP-based framework, and many errors only happen at runtime and can be hard to debug. In addition, many different artifacts are created when developing a typical standard application, which can cause additional complexity when it comes to typical lifecycle tasks such as changing parts of the model or implementation.  

The RAP Model

To address the limitations of the previous model, the RAP model was introduced with SAP Cloud Platform ABAP environment, and is available with release 1808 and higher, with a planned quarterly update cycle that is no longer tied to a traditional yearly on-premise release. The RAP model is built on top of the semantic data model expressed by CDS, and transactional services are expressed in the behavior definitions for the data model and their corresponding implementations. The logic that defines the data model and behavior to be consumed by the SAP Fiori application is expressed and exposed as business services. Tools are also provided to help adapt existing applications to the RAP model, which is intended to be used for a long time, similar to the earlier traditional models. The RAP model is agnostic with respect to customers’ preferred deployment preferences. While the model was introduced with SAP Cloud Platform ABAP environment, you can also use it for on-premise development with SAP S/4HANA. The model is part of the ABAP platform, and both the cloud and on-premise versions of the ABAP platform are based on a common innovation codeline. Every RAP feature is introduced in SAP Cloud Platform ABAP environment, delivered quarter by quarter in a cloud-first approach, and then, starting with SAP S/4HANA 1909, is later bundled into the yearly on-premise shipment of the ABAP platform, which is the underlying foundation for SAP S/4HANA.  

A Look Inside the RAP Model

Now that you understand the needs that led to the development of the RAP model, let’s take a closer look at how the model works. Figure 2 provides an overview. As you can see, it consists of three layers: a data modeling and behavior layer, where the basic entities are defined that make up the model; a business services provisioning layer, where the projection of the relevant entities for a particular use case or persona are defined; and a service consumption layer, where the exposed business services are consumed in a responsive UI. Let’s walk through each of these layers, so that you are well oriented when starting your own development project.   Figure 2 — An overview of the layers of the ABAP RESTful programming model  

The Data Modeling and Behavior Layer

The CDS data models are defined in the semantic data modeling and behavior layer. These data models consist of CDS entities based on dictionary tables and other more fundamental CDS entities, based on joins or associations, and they are represented in ABAP as CDS views, which provide access to the data represented in the models. CDS views consist of fields and associations to other CDS views, which form the semantic network. A simple example of an association would be order headers and order details that are associated via composition. An order header in turn refers to a customer master by an association, and an order detail refers to a product master by an association. These associations enable you to easily navigate through the entire data model, and you can also use them to provide navigational capabilities in SAP Fiori applications. In this layer you can also execute queries to enable structured data retrieval for ad hoc analytics — and you can add behavior definitions for basic transactional services such as insert, update, and delete. For each CDS entity, you can create a corresponding behavior definition. In addition to the traditional create, update, delete (CUD) operations, you can use the behavior definition to specify how locks for concurrent access are handled. Soon, you will also be able to add draft capabilities so that end users can collaborate and data can be saved in an intermediate way (that is, in draft form) before a commit operation is finally executed (these draft capabilities are planned for an upcoming release). The behavior definition converts your CDS entities into true business objects. There are two different ways to implement behaviors: via a managed scenario or an unmanaged scenario. In a managed scenario, many of the behavioral elements are implemented by the RAP framework itself. However, you might want to add ABAP logic to implement complex validation logic on your own, or you might want to calculate fields based on the fields of your business objects (such as a totals field). This calculation logic is called determination. You might also want to realize actions that operate on your business objects, change their status, and trigger further processing that goes beyond the standard CUD operations, which typically requires ABAP coding that implements the required steps, changes, and processing. In these cases, you would want to use an unmanaged scenario. In this scenario, you provide all the coding for the implementation on your own. This is particularly useful if you have already-existing BOPF applications or traditional ABAP code (such as update function modules) that must be called when the business object you have modeled is saved.  

The Business Services Provisioning Layer

The business services provisioning layer mediates between the data model and the consumer of the data (an SAP Fiori application or another ABAP program, for example). Let’s say that you have defined your semantic data model and corresponding behavior, and that model will serve as the foundation for many different applications that are targeted toward a certain persona (a project manager, for example). Instead of using all the fields and associations of the underlying model, it makes more sense to project a subset that fits the needs of the targeted persona. Similarly, you likely want to offer only certain behavioral aspects rather than exposing all behaviors on this level. In an order management scenario, you might want to project the behavior and not include all the underlying functions — for example, you might want to allow a persona to display and change an order, but not create or delete it. This layer enables this control through the definition of business services, which consist of a service definition and a service binding. After defining a data model projection and a behavior projection, which define the subsets of the data model and behavior that are specific to a particular service, you expose the required scope in the service definition and bind it to a particular protocol version, such as OData v2 or v4. Once these steps are complete, the service is available and you can test drive it in a browser.  

The Service Consumption Layer

The service consumption layer consumes the services that are exposed on the business services provisioning layer. In a real-life scenario, end users would run their SAP Fiori template applications, which would then invoke the OData-based business services and navigate along the model hierarchy. Alternatively, a consumer could be another ABAP program, in which case the exposed service is called a Web API.  

Developing with the RAP Model

With an understanding of the different layers of the RAP model, let’s look at what development using this model looks like in SAP Cloud Platform ABAP environment. Note that all development tasks are performed with the Eclipse-based ABAP development tools, which are the standard development tools for SAP Cloud Platform ABAP environment. Figure 3 shows the development flow. As you can see, you typically start by creating a CDS model, which can be examined in the CDS editor in the Eclipse workspace. Next, you add behaviors and factor out an implementation class containing your code. Then, you specify the data model projection and behavior projection. Finally, you expose the service definition, bind it, publish it, and start a preview to run your application directly from within the development tools. The tools follow this development flow through their wizards and prompts.   Figure 3 — The development flow with the ABAP RESTful programming model   Let’s see what this development flow looks like using a straightforward example that is suitable for the RAP model and philosophy and that is typical to the real world. In this scenario, customers would like to create travel requests that are handled by a particular travel agency, and we need to develop an application that processes and approves the submitted travel requests. We’ll next walk through the following tasks:

• Define an ABAP package and a database table.
• Develop a read-only application.
• Add transactional behavior.
• Enhance behavior with action and validation.

Define an ABAP Package and a Database Table

Each project starts with the creation of an ABAP package in the Project Explorer of the Eclipse workspace. After creating an SAP Cloud Platform ABAP environment development project (PMD_EN in the example), right click on the project name in the Project Explorer and select New > ABAP Package (see Figure 4). Specify a name (ZTRAVEL_APP_KK), description (Travel package), and type (Development) for the package (see Figure 5).   Figure 4 — Create a new ABAP package   Figure 5 — Define an ABAP package to contain the application components   Next, add the package to your favorites by right clicking on the package in the Project Explorer and selecting Add to Favorite Packages (see Figure 6), which makes it a top-level entry and easy to find. Then create a new repository object by right clicking on the package and selecting New > Other ABAP Repository Object (see Figure 7).   Figure 6 — Make the package a favorite so it is easy to find   Figure 7 — Create a new repository object   Choose Database Table from the list of Dictionary tools (see Figure 8). Enter a name (ZTRAVEL_KK) and a description (Travel table) for the database table, which will contain the travel requests (Figure 9).   Figure 8 — Choose the Database Table tool to create a database table   Figure 9 — Define a database table to contain the travel requests   We will base the travel requests on the reference flight data model available on Github. To access this data model, create a new package in the project and name it (/DMO/FLIGHT), add a description (Flight model), and select a type (Development) for the package (see Figure 10). Next, start the abapGIT client by clicking on the abapGIT Repositories tab in the lower pane of the workspace, add a new repository by clicking on the plus (+) icon, and enter the URL https://github.com/SAP/abap-platform-refscen-flight (see Figure 11).   Figure 10 — Create a new package for the flight data model     Specify the repository branch (refs/heads/master) and target package (the /DMO/FLIGHT package we just created) for the flight data model content (see Figure 12) and start pulling the content from Github using the context menu (see Figure 13).   Figure 12 — Specify the target package for the flight data model content   Figure 13 — Pull the flight data model content from Github   Once the pull is complete, you can examine the contents of the repository in the Project Explorer (see Figure 14).   Figure 14 — Browse the contents of the flight data model in the Project Explorer   Next, in the ZTRAVEL_KK database table that we created to hold the travel requests, define the table’s fields, such as a travel ID to identify a travel request, an associated agency, a customer ID, begin and end date, booking fee and total price (both referring to the currency code), a description, the status field, and organizational fields such as create date and last update (see Figure 15). To fill the table’s fields with some basic data, create a class, assign it to the ABAP package for the application (ZTRAVEL_APP_KK), and enter a name (ZCL_GENERATE_TRAVEL_DATA_KK) and a description (Generate travel data) for the class (see Figure 16).   Figure 15 — The definition of the ZTRAVEL_KK database table   Figure 16 — Define an ABAP class to fill the database table with data   Code the SQL inserts in the class, which will insert three records defined with the VALUE # operator (see Figure 17). Finally, we can browse the content of the ZTRAVEL_KK table by executing the class (by pressing F8 in the table editor) and viewing it in preview mode (see Figure 18).   Figure 17 — Add SQL inserts to the class implementation   Figure 18 — The results of the class implementation  

Develop a Read-Only Application

With a traditional dictionary database table defined, the next step is to build a CDS model on top of this table and develop an initial read-only SAP Fiori application. To create a CDS view for the table, create a new data definition — right click on the ABAP package (Z_TRAVEL_APP_KK), select ABAP Repository Object, and choose Data Definition from the list of Core Data Services tools. Enter a name (ZI_TRAVEL_M_KK) and a description (Interface View) for the interface view. Next, code the data definition for the interface view (see Figure 19). Figure 20 shows the code of the data definition for the interface view. As you can see, we base the definition of the view on the dictionary database table ZTRAVEL_KK. We expose associations to Agency, Customer, and Currency, and then list the fields from the ZTRAVEL_KK database table, adding semantics such as currency code and organizational data.   Figure 19 — Create a data definition for the CDS view   Figure 20 — The definition of the ZI_TRAVEL_M_KK interface view   Next, create a projection view to define the subsets of the data model and behavior that are specific to a particular service. Create a new data definition and enter a name (ZC_TRAVEL_M_KK) and a description for the view (see Figure 21). In this case, we describe the projection view as a “consumption view,” since it is consuming the underlying interface view. Then, as shown in Figure 22, code the definition of the consumption view. Based on this definition, the view picks the fields that should be displayed, adding additional details such as layout information, header labels, value help for agency, customer, and currency.   Figure 21 — Create a data definition for the consumption view   Figure 22 — The definition of the ZC_TRAVEL_M_KK consumption view   Next, create the service definition, which will expose the relevant CDS entities as a service to the SAP Fiori application — right click on the ABAP package, select ABAP Repository Object, and then choose Service Definition from the list of Business Services tools. Specify a name (ZUI_C_TRAVEL_M_KK) and a description (Travel service) for the service definition (see Figure 23). In the code, add the entities to be exposed — for the example, we add the entities for TravelProcessor, Passenger, Airport, Currency, and Country from the flight data model (see Figure 24).   Figure 23 — Create a service definition to expose the relevant CDS entities as a service   Figure 24 — The ZUI_C_TRAVEL_M_KK service definition for exposing the CDS entities   Finally, create a service binding to bind the service to a communication protocol (OData in this case) — right click on the ABAP package (Z_TRAVEL_APP_KK) and select New Service Binding. Name the binding (ZUI_C_TRAVEL_M_KK), provide a description (Travel binding), choose a binding type (ODATA V2 - UI), and associate the newly created service definition (ZUI_C_TRAVEL_M_KK) with the binding (see Figure 25).   Figure 25 — Create a service binding to bind the service to a communication protocol   Once the binding is activated, you can view general information about the binding in the Eclipse workspace, including the type of binding and the entity sets and associations included in the service (see Figure 26). Double clicking on the Travel Processor entity set in the example launches a preview that shows the travel request in a generated SAP Fiori template application (see Figure 27).   Figure 26 — General information about the service binding   Figure 27 — A preview of the travel request in a generated SAP Fiori template application  

Add Transactional Behavior

To add transactional behavior to the application, right click on the CDS view (ZI_TRAVEL_M_KK) and select New Behavior Definition. Add a description (Behavior for ZI_TRAVEL_M_KK) — the name of the behavior definition is the same as the CDS view (ZC_TRAVEL_M_KK), and the Managed implementation type is preselected (see Figure 28).   Figure 28 — Create a behavior definition to add transactional behavior to the application   In the code (see Figure 29), specify the underlying dictionary table (ZTRAVEL_KK) used for the CUD operations and add lock control for concurrent access. Then specify field properties such as read only or mandatory. Next, specify the standard CUD operations that will be handled by the framework. Finally, create the corresponding implementation class that hosts your ABAP coding by entering a name for the class (ZCL_BP_I_TRAVEL_M_KK) and clicking on the class name.   Figure 29 — The behavior definition for the ZI_TRAVEL_M_KK CDS view   In the same way, add transactional behavior to the ZC_TRAVEL_M_KK consumption view. Right click on the consumption view, select New Behavior Definition, and add a description (Behavior for ZC_TRAVEL_M_KK) — the name of the behavior definition is the same as the consumption view, and the “Projection” implementation type is preselected (see Figure 30). In the code (Figure 31), specify the mandatory fields for the scenario and the used CUD operations that will be exposed.   Figure 30 — Create a behavior definition for the consumption view   Figure 31 — The behavior definition for the ZC_TRAVEL_M_KK consumption view   Rerun the application in the preview (see Figure 32), and you will see that Create and Delete buttons have been added. The application is now fully functional, meaning that the transactional updates are executed by the framework (see Figure 33).   Figure 32 — A preview of the application with the behavior definition added   Figure 33 — The fully functional application  

Enhance Behavior with Action and Validation

Let’s say that we want to add code to validate input — to validate that the begin date should always be earlier than the end date, for example. To add this, enhance the behavior definition of the interface view (ZI_TRAVEL_M_KK) that refers to the implementation class ZCL_BP_I_TRAVEL_M_KK, which contains the code for validations and actions and was defined previously. The relevant portion of the code is shown in Figure 34. Here, we use the entity modeling language (EML) — which consists of special keywords of the ABAP language that act like an API against business objects — to specify that if the end date is earlier than the begin date, the ABAP code will compose an error message that is then sent to the user.   Figure 34 — Enhance the behavior definition to add a validation function  

Summary

The RAP model included with SAP Cloud Platform ABAP environment builds on the foundation of CDS, adding transactional behavior capabilities that are reflected in SAP Fiori template applications to support the development requirements of modern SAP environments. Via wizards and prompts, the standard Eclipse-based ABAP development tools guide developers along the development flow through the layers of the RAP model, enabling an efficient development process. While this article covers the basic principles and philosophy to help developers get started, the RAP model supports a wide variety of additional, more advanced concepts, such as handling composite relationships. To learn more and explore the RAP model and how it works in more detail, visit https://blogs.sap.com/2019/10/25/getting-started-with-the-abap-restful-programming-model/.