What is RESTful Application Programming (RAP)?

The ABAP RESTful Application Programming Model, developed by SAP, is built entirely on the ABAP language and follows the framework of Representational State Transfer (REST) to create applications in a client-server architecture with a uniform interface for resource manipulation.

The primary purpose of RAP is to enable developers to efficiently build cloud-ready business applications that manage different business transactions in the form of standard OData services or to create extensions for existing applications without modifying the existing standard code.  They support end-to-end development from data modeling to service exposure and compactivity with SAP Fiori UX.

RAP supports development for various SAP platforms, including SAP BTP ABAP for building cloud-native applications and extensions, as well as SAP S/4HANA Cloud (Public and Private Editions), which supports custom developments compatible with the cloud’s continuous innovations and upgrade cycles. RAP has been available for on-premises SAP S/4HANA since the 1909 release, allowing customers to build applications using modern development practices and create future-proof applications.

RAP plays a pivotal role in the ABAP cloud development model for transactional applications, utilizing Core Data Services (CDS) to define data structures and views, providing mechanisms for implementing business logic, and ensuring data integrity during transactions.

Why Learn RESTful Application Programming?

Evolution of Business Application Requirements

RAP is not just a new development framework; it’s SAP’s strategic programming model for embracing the modern paradigm in building enterprise business applications within the SAP ecosystem.

Modern business applications require immediate insights from their operational data to inform decision-making. Subsequently, analytical capabilities are getting embedded within transactional applications to gain insights without switching context. RAP enables direct integration of data with AI model training and analytics, reducing the need for complex data replication and processing.

RAP is optimized for SAP HANA database, leveraging the full potential of its in-memory processing capabilities and executing operations such as joining, aggregations, and complex calculations at higher rates, which were once performance bottlenecks on traditional databases.

SAP Fiori introduced a new design language and user experience paradigm for SAP applications, characterized by simplicity, consistency, and role-based access. RAP enables developers to expose business objects as OData services, allowing for seamless integration with Fiori elements and a consistent experience across various devices.

RAP is designed with cloud principles in mind, and applications are inherently optimized for the SAP BTP ABAP environment, enabling both in-app extensibility and side-by-side extensions. This makes it ideal for cloud-native and hybrid deployments.

End User Expectations

Fiori UX directly consumes RAP OData services, providing a consistent user experience across different devices while maintaining context. The underlying design of RAP promotes statelessness, allowing users’ sessions to be easily picked up from any device where it was last left, on the next device.

Product Qualities (Out-of-the-box)

RAP programming principles enable developers to add several critical qualities by default without requiring post-development efforts:

• Scalability: RAP’s stateless architecture and optimized interaction with SAP HANA inherently allow scalability, enabling applications to be deployed in a distributed manner and easily scaled up in cloud environments.
• Testability: RAP provides built-in tools and techniques to test applications’ logic and promote the separation of logic layers, making unit testing and behavior definition maintainable.
• Extensibility: RAP enables developers to create well-defined extension points in their applications, allowing for modifications and additions of new features without requiring changes to the source code.
• Supportability: Applications developed are easily maintained with detailed diagnostic and debugging capabilities after deployment.
• Documentability: RAP’s declarative nature, such as CDS definitions and structured programming model, inherently leads to better documentation.

RAP Basics

What is a business object?

A business object in RAP represents a real-world business entity or concept within a business domain, such as Sales Order, Customer, Product, or Employee. It encapsulates all its data, behavior, and relationships. The business object is the core unit of control for consistent data manipulation and transactional integrity, defining the structure of data, the rules governing data manipulation, and the lifecycle of a business entity.

What is a query?

A query is the read-only interface that connects to access data for consumption and is built on top of Core Data Services (CDS) Views, primarily used to retrieve and display business data. They provide a structured way to recover, filter, sort, and aggregate data, often serving as a data source for analytical dashboards, search functionalities, or lists of objects in the user interface.

What is a business service?

Business services in RAP provide an external interface to access the functionalities of business objects, both read and write, which are interactable through the Fiori application UI for end-users or external systems. Business services are typically exposed with a service definition, which outlines what the service provides, and a service binding, specifying how it’s exposed using a particular protocol, such as OData v2 or v4, UI, Web API, etc.

What is a business event?

A business event in RAP represents a defined trigger or notification signaling a significant change or action occurring within a business object, which may trigger other events in applications or services that might be linked. For example, a “sales order created” or “product price changed” is a business event that can be consumed by other applications or workflows for further processing. Event Definitions and Event Bindings are defined and used for asynchronous integration between services via SAP Event Mesh or custom logic.

Data modeling

Data modeling in RAP is performed using Core Data Services (CDS), which defines Entities, i.e., data structures, their associations, i.e., relationships with other entities, and projections with customized views for exposure. Data modeling is the central point for defining the entire application structure from a data flow perspective.

ABAP language

The modern ABAP language serves as the foundation for implementing business logic within RAP, leveraging its features, including Entity Manipulation Language (EML), annotations, and object-oriented concepts, as well as its extensive libraries and error handling capabilities.

Tools

RAP development is supported by a different set of tools, such as the CDS Editor, ABAP Source Code Editors, ADT Wizards, and the Services Binding Editor, which are primarily integrated within the ABAP Development Tools (ADT) in the Eclipse IDE (an open-source development platform widely used for software development).

Extensibility

RAP provides built-in extensibility mechanisms, allowing customers and partners to enhance or adapt standard business objects and services without modifying the core codebase. Provides a precise mechanism for both types of extensibilities: in-app extensibility, which allows adding custom fields, custom logic, or custom business objects directly in existing applications, and side-by-side extensibility, which involves building separate applications or services to consume and extend standard business objects.

3 Layer Architecture of RAP Model

The RAP model has three foundational layers, each with a specific role, and provides a structured approach to building enterprise-grade SAP Fiori applications and exposing APIs for external interactions.

Data Modeling and Behavior

Data modeling and behavior definition are the foundational layer. They define the entities that represent business objects and the relationships between these entities.

Core data services views are used to define data models that can be reused and to define the structure of entities, including their attributes, associations, and apply different filters and calculations, as well as annotations to provide metadata for UI consumption.

Behavior definition is the step that defines what actions are possible with a data structure, such as create, update, and delete operations.

The data model and available operations are defined in the database. Still, the actual logic for executing these operations is implemented in ABAP classes that contain the business logic for creating, updating, deleting, and custom operations performed on business objects.

Business Service

The business service layer is responsible for exposing the data structure and behavior defined in the first layer as a consumable service. The definition of service is written to specify which CDS entities and their behavior will be exposed, thereby controlling the scope of the service.

The service binding definition is the second step that specifies the protocol to be used for communication with the service, i.e., OData v2 or OData v4.

Service Consumption

Service consumption refers to the layer where clients or applications use exposed services. When a service is intended for a SAP Fiori Elements application, it is referred to as a UI service, and its purpose is to provide data and metadata that Fiori Elements uses to render screens, tables, and forms automatically.

Service can be exposed as a Web API to be consumed by any OData client, and this kind of service does not include UI specific metadata. These services are ideal for integration with non-SAP systems, mobile applications, or any custom application that requires interaction with business data and logic.

Evolution of ABAP Programming Models

ABAP programming has evolved from freestyle coding to RESTful application programming model, adapting to the changing technological paradigm, architectural shifts and development need, especially after the advent of SAP Fiori and cloud-native development.

Classic ABAP Programming

In classic models, developers used to write ABAP code in a procedural and imperative style, directly accessing databases and mixing business and UI logic, which made them tightly coupled and subsequently more complex to maintain the codebase.

User interface was built using tools like SAPscript, Smart Forms and dialog programming (Dynpro). Creating screens with UI elements and linking them with ABAP logic, Process Before Output (PBO) and Process After Input (PAI) modules. Dynpro was effective for traditional desktop applications but lacked modern responsive design capabilities.

ABAP Programming Model for SAP Fiori

With the advent of SAP Fiori, a new programming model emerged to accommodate the needs of modern responsive user experience. This model focuses on creating OData manually with the tool SAP Gateway Service Builder (SEGW). Developers will manually define entities, properties, and associations, and implement create, read, update, and delete (CRUD) operations.

Using OData.publish mechanism, OData services were registered and published for consumption in SAP Gateway, which acted as a hub for exposing and managing OData services.

Core Data service allowed developers to define semantically rich data models for entity creation, associations, and calculations at the database level. The CDS based Business Object Processing Framework (BOPF) was designed to streamline the implementation of Business object logics like behavior, validations and CRUD operations.

ABAP RESTful Application Programming Model

RAP is the latest evolution, designed for efficient, cloud ready applications for SAP S/4HANA and SAP BTP.

It centralizes the concept of Business Service, encapsulating both data and behavior aspects, such as which entities and behaviors will be exposed for Fiori or an external application, and on which protocol.

The Core Data service remains central in RAP, enabling the definition of reusable data models and annotations to generate UI for Fiori Elements automatically.

RAP separates behavior definition from behavior implementation. A declarative specification defines what operations are possible, whereas behavior implementation is where ABAP code resides to implement the logic for defined behaviors.

Steps in RAP Development Process

Development process of applications in RAP starts from defining underlying data structure with its relationships, behavior and metadata to expose the service which can be consumed by Fiori Elements or external application.

1. Provide the Database Tables

The first step is to choose which tables will be used that hold the business data. These tables can be existing standard SAP tables or custom defined tables. Add explanations on integrating legacy and any modifications made to the tables, if they were non-CDS-based tables. Creating new tables, with custom attributes specific to the application, is also a suitable choice for a clean and separate implementation.

2. Define the Data Model

The next step is to define the Data model, building CDS views that represent business objects. These views can consist of a single table as a simple CDS view or join multiple tables to create composite views with parent-child definitions for complex Business objects.

• Simple business objects fully represent a product or customer with all relevant attributes and behaviors encapsulated within one CDS view.
• Composite business objects address complex business scenarios involving multiple business entities, such as a Sales Order, which may not be a single entity and could be linked with Sales Order Header and Sales Order Items.

The parent-child relationship defines association and composition in CDS, supports transactional behavior, and ensures consistency.

3. Define and Implement the Behavior (Transactional apps only)

The data model defines the structure of the business object. In contrast, the behavior definition and implementation define how it will behave transactionally, including the supported operations, such as create, update, and delete. Custom operations are implemented here with validation checks before saving data.

The Behavior Pool, a global ABAP class, is used for behavior implementation, where actual ABAP code is written.

Key features of transactional apps are as follows:

• Draft Enabling: Allow end users to save incomplete business data as a draft, without committing, thereby improving the user experience by allowing them to pause and resume work later.
• Automatic Numbering: Unique and sequential key generations for entities that require unique identities, such as sales order numbers.
• Validations: These are data consistency checks implemented to validate that input format and expected values adhere to business logic, i.e., delivery dates cannot be in the past, and phone number formats are correct.
• Determinations: Fields that get calculated based on input in other fields, i.e., full name gets populated based on first and last name, or when a product name is entered, their description and prices are automatically populated.

Behavior implementation can be neglected if the application is purely for displaying data such as list report or analytical report and does not require modification operations.

4. Project the RAP Business Object

Rather than exposing all the fields from the underlying CDS view, selected subsets of fields are exposed with CDS projection views for a particular service. Fields can be renamed or added pre-calculated fields specific to UI and naming convention like ZC_<fieldname> can be used for consistency.

Similar to a Data projection model, Behavior projection allows for enabling or disabling specific operations, such as creating, deleting, and updating, at the service level. For example, rather than removing the delete operation on the CDS behavior level, this behavior is not exposed on the service level.

UI-specific annotations are added to the projection view to define how data should be displayed in the UI of Fiori Elements and control aspects such as field labels, search capabilities, and analytical features.

5. Define the Service

Service definition is a repository object that references one or more CDS projection views and acts as a container for the entities to expose as a service.

The Z<service_Name> naming convention is usually used, and specific annotations are described to control exposure and UI navigation properties.

6. Bind the Service and Test the Service

The final step is to define the binding of the service by describing the consumption methods, i.e., Fiori UI or external applications, and the protocol, such as OData v2 or v4.

For UI services, developers can enable preview to automatically generate a Fiori elements preview, allowing them to quickly test functionality without building the complete Fiori application.

Typically, naming convention ZUI_<service_Name>_04 is used for the UI service of the OData v4 protocol.

Implementing Business Objectives

There are two main approaches to implementing Business Objects types in RAP:

• Managed
• Unmanaged

Both methods are based on data models defined by CDS view entities. The difference lies in the provisioning of the Business object’s transactional behavior.

Managed Business Objectives

Managed type implementation is primarily used when an application is developed from scratch, but it can also leverage out-of-the-box support for transactional processing. Standard validations and determinations are provided by the framework.

Unmanaged Business Objectives

An unmanaged approach is adopted to take complete control over transactional logic, CRUD operations, and data persistence when handling complex business logic and interaction with multiple systems. Developers must implement essential components of the REST contract. Behavior must be specified in the behavior definition, but implemented manually in ABAP classes in the behavior pool.

When business logic is already encapsulated in functional modules, an unmanaged approach helps developers reuse existing business logic in business objects. It can benefit from standardized RAP run-time orchestration to create a RAP service.

Reuse Services and Libraries

ABAP RAP provides a collection of pre-designed functionalities, APIs, and components designed for use across multiple applications or services. Reusing existing services and libraries enables developers to save time and effort on tasks such as standardized authorization checks, text determinations, and redundant code, allowing them to concentrate on unique business logic specific to the application.

Pre-defined libraries and services provide out-of-the-box generic functionalities applicable across various business domains such as draft handling, field control and validations, manage transactional processing, date and time utilities, Etag handling for data concurrency control, standardized log generation and how errors or events are tracked.

RAP allows building custom logic specific to the domain for these internal services or libraries, and these custom services can be reused anywhere.

The ability to reuse standard or customized libraries allows developers to reduce boilerplate code. This not only accelerates the development process but also improves maintainability. Reusing services and libraries is designed to integrate within applications, allowing developers to call external services or invoke library functions directly from their Behavior implementations and projection views.

Frequently Asked Questions