Architecture of RAP:

Data Model:

Depending on the use case, data models support either transactional access
or query access to the database. Accordingly, they are used in business
objects (for transactional scenarios) or queries (for read-only scenarios).

1
  Transactional access: refers to create, update, and delete (CRUD)
operations where you are modifying the database. If you are building a
transactional application (CRUD), then a BDEF is required.
 Queries: refer to how you read data from the database. If you are
building a read-only application, a behaviour definition (BDEF) is not
mandatory.

Data model layer/vdm types:

Its not mandatory to mention vdm type, but it’s a good practice, These are
used to maintain a structural representation of cds view and define what role
particular cds view plays.

 Interface view(basic + composite view):

1. Basic View:
Represents the foundational data model; exposes raw data from
database tables and serves as a reusable building block for other views.
2. Composite View:
Builds on basic views by adding logic or combining basic view; used for
more specific domains like analytical processing.

 Consumption View:
Tailored for specific use cases or applications, especially UI; delivers exactly
the data and annotations needed for consumption. These are nothing but
your projection view.

Reference link: [Link]

cost-accounting-in-sap-s-4hana/getting-an-overview-of-the-virtual-data-
model_fbd48178-c584-4b3d-a8c9-13143c1c75dc

2
Data model for static data fetching: Managed Query
Have you ever wondered how data is fetched with querries like filters, top,
skip, or select while using CDS views as data models, even though you didn’t
write any specific logic for it?
This is possible because RAP uses the SADL framework , which automatically
handles these runtime queries. Since the framework handles the query logic,
this is known as a managed query—you don’t need to write custom code for
query handling.

Data model for dynamic value fetching: Unmanaged Query

In contrast, an unmanaged query requires the use of custom entities and a
corresponding query implementation class, where the developer writes the
logic to handle the query manually.
Note:
 On top of a custom entity, you can only build an unmanaged business
object, because a managed BO depends on the framework to handle
CRUD operations. Since in this case the developer is manually handling
the read operation, a managed BO is not applicable.
 Custom entities can’t have projection views as well.

In simple terms, if you're working on a simple application where data is

fetched directly from a table, you can use a table and CDS view. This is known
as a managed query. However, if you need to fetch data dynamically based
on specific conditions or custom logic, you can use custom entities along with
a query implementation class. This approach is called an unmanaged query,
where you write the logic yourself to handle how the data should be fetched.

Refer this link for unamnaged querry:

[Link]
entity..html

3
Data model for analytics application:
For analytical reports, we use cube, dimension, and fact views as the data
model. Analytical reports are primarily developed for read-only operations,
where you need to perform analytical processing using tools like SAP
Analytics Cloud. These views do not create SQL views on the database and
can only be accessed through the analytical runtime.

refer this link to understand the flow better:

[Link]
analytics..html#35f16409-e58a-4d76-82a0-323754260ea6

Projection View :
A projection view defines how data should be presented in an API or a Fiori
UI.

Metada extension:
It’s considered good practice to write UI annotations in a metadata extension
rather than directly on the projection view.
Why?
This approach helps separate the UI layer from the CDS logic, ensuring
better modularity.
It allows you to define multiple UI annotations for a single projection
view, providing greater flexibility.
If multiple metadata extensions exist, the one with the highest priority is
used. The priority is determined using the @[Link] annotation.

Refer this blog to learn in detail about metadata extension :

[Link]

4
 applications/explaining-metadata-extension_e6f582d8-ee73-410a-9b96-
897452de936d

Why do we need a projection view? Can't we expose the interface view directly to
the UI?
The main reason for using a projection view is to introduce flexibility and
modularity. The interface view typically contains generic, reusable data and
logic, while the projection view allows for service-specific customization
Like:
 You can add virtual elements (e.g., calculated fields) in the projection
view.
Refer this blog to learn about virtual elements:
[Link]
members/how-to-use-virtual-elements-in-abap-restful-application-
programming-model/ba-p/13532828
 You can exclude certain fields that aren't needed in a specific application
or service.
This separation ensures that your interface view remains clean, reusable,
and generic, while the projection view adapts to the needs of each specific
service or application.

Example Scenario for projection view:

Let’s say you have a table for Business Partners, and you need to build two
applications:
[Link] for Customers
[Link] for Vendors

You have two options:

[Link] two interface views and two projection views (one pair for each
use case).
[Link] better, create one interface view and two projection views.
By choosing the second approach (1 interface + 2 projections), you make the
design modular (no code duplication) and flexible (each projection can
customize the UI for its specific use case — such as adding virtual elements or
hiding fields).

5
Types of Projection Views / Provider Contracts:

1. Transactional query:
Used for modeling the projection layer of a business object in the ABAP
RESTful Application Programming Model (RAP).

2. Transactional interfaces:
Usually used by SAP-released business objects for extensibility purposes.
These don’t have new associations or fields added to them; they are meant
to be extended. You can check the properties of the released consumption
view to understand how they are released and their provider contract in sap
accelarator hub.
Link:
[Link]
ws

3. Analytics query:
This is built only on top of analytical objects like cube or dimension CDS
views. These are specifically designed to run on the analytical engine.
Refer to this link to better understand projection view:
[Link]
views

6
Business object(BO):

BO stands for Business Object. For which business process did you create the
RAP application? For example, if you created an application to create Sales
Orders, then 'Sales Order' would be one of the BOs, and 'Items' and 'Partners'
would be other related BOs.

We refer to the parent node as the root, and the lowest-level child in the
hierarchy as the leaf.

Behaviour definition(Bdef ):

This will include all the characteristics of your Business Object (BO), such as
CRUD operations, action buttons to approve the sales order, validations to
check the character limit of the sales order, and determinations to calculate
the price based on amount and quantity, and so on.

In RAP, we have to create 2 BDEF, bdef interface on top of interface view and
bdef projection on top of projection view

Buisness object Implementation types in BDEF:

Managed
In a managed scenario, the framework handles:
1. Create, Update, Delete (CUD) operations.
2. Transactional buffer management.
3. Full save sequence execution.
When to use:
 For greenfield implementations — when starting from scratch.
 Limited control — most logic is handled by the framework.

7
Managed with Unmanaged Save
Handled by the framework:
1. CUD operations.
2. Transactional buffer.
Handled by the developer:
 Developer manages the save sequence.

Managed with Additional Save

Handled by the framework:
1. CUD operations.
2. Transactional buffer.
3. Save sequence ➕ devellper can insert custom logic within the save
sequence.
When to use managed with Unmanaged Save and Additional Save
 When developer needs to control save sequence, like to use BAPIs, RAP
facades, BGPF, or late numbering.
 Additional save-When the managed save process is not enough and
extra logic is required.

Unmanaged
In an unmanaged scenario, everything is handled by developer
1. CUD operations are written in the ABAP behavior pool.
2. Developer creates and maintains the transactional buffer (typically in
global class internal tables).
3. Save sequence is fully developer-driven.
When to use:
 Ideal for brownfield implementations — reusing legacy code such as
classes, BAPIs, or function modules.
 Offers complete developer control over logic and flow.

8
Behaviorur implementation:

In the BDEF, you only declare the characteristics of the Business Object (BO);
the logic is implemented in the ABAP Behavior Pool.

Abap behaviour pool:

It is the class in which we write the logic for the behavior of the Business
Object (BO). As soon as you create the ABAP behavior class, a global class
(which is abstract and final) is automatically created along with a local class.
We will not write any logic in global class because Rap is strictly editable only

9
on eclipse. Local classes, which can only be edited in Eclipse, provide security and
control over the implementation. This is crucial because:
 If we were to write code in a global class, it could be modified through the GUI,
which could introduce security risks and unwanted changes.

Global class is editable

Local class is not editable in GUI

 Local classes are restricted to the development environment (Eclipse),

ensuring more consistency and security.

Note: A global class can contain one or more local RAP handler classes, but only
1 RAP saver class.

10
Structure of local class:

Local class is divided into local handler class and local saver class.

1. Local handler class:

 A handler class (e.g., lhc_handler) inherits from CL_ABAP_BEHAVIOR_HANDLER.

 The handler class is crucial for managing operations in the interaction phase of
a RAP Business Object. For modularization purposes, one behaviour pool can
define multiple handler classes. These could include:
1. One handler class per entity.
2. Distinction between reading and changing operations for different RAP BO
entities.
 RAP Handler methods are defined based on the functionality used in BDEF.
 Handler methods should be defined in private section.

2. Local saver class:

 A saver class (e.g., lsc_saver) inherits from CL_ABAP_BEHAVIOR_SAVER.

 Mandatory RAP saver methods must be implemented in local saver class.
 Only one RAP saver class can be implemented for a RAP BO.
 RAP saver methods are declared by redefining predefined methods from the
super class, which allows you to define custom behaviour during the save
sequence.

CL_ABAP_BEHV – The Foundation Class

At the top of the BO API class hierarchy is CL_ABAP_BEHV, the foundation class
for both the handler and saver classes. This class defines:
 Fundamental data types used in behaviour processing (e.g., field names in
derived type structures).
 Methods for message creation .
The classes that inherit from CL_ABAP_BEHV include:
 CL_ABAP_BEHAVIOR_HANDLER – The base class for the handler.
 CL_ABAP_BEHAVIOR_SAVER – The base class for the saver.

Derived Types:

The methods generated by the framework for the characteristics declared in

the Behavior Definition (BDEF) are not of the normal ABAP types that we

11
 typically declare. Instead, they are called derived types. These are implicitly
derived by the ABAP compiler from the involved CDS views and the behavior
definition. To check the derived type, place the cursor on the method and
press F2. You will see the importing and changing parameters of the method.
These parameters are of derived types, and each derived type has its own
derived components.

Derived Components:

Internal structures and tables declared with derived data types do not
contain only key and data fields. They also include other components that
are not directly derived from the CDS entity's line type. These additional
components have special, tailor-made line types that provide extra
information required for transactional processing. The names of these RAP
components begin with a % symbol to avoid naming conflicts with
components of the CDS entities. We will see about each of the % components
as we proceed.

Service definition:

A business service definition (short form: service definition ) describes which CDS
entities of a data model are to be exposed. It can be either interface view or
projection view. If you don’t expose that searvice not be showed in application.

12
Service binding:

Used to bind service side and client side.

Types of service binding:

1. OData V2/V4 – Web API:

These are used only to provide OData services. They are consumed by
frontend developers who use them to build applications. These APIs do
not contain any UI elements.
2. OData V2/V4 – UI:
These represent complete Fiori applications. They include both the
backend services and UI annotations.
3. InA-UI (Information Access):
Analytical data models are exposed using the InA protocol for live data
access. This is typically used in scenarios involving analytical objects
such as cube CDS views, dimension CDS views, and projection views
with an analytics query contract.
4. SQL-UI:
You can access published ABAP-managed database API objects using
Open SQL. This allows direct interaction with database tables, views,
and CDS entities in ABAP programs.

BO Runtime:

BO (Business Object) runtime explains how a business object is created at runtime.

It follows a controlled LUW*. All data provided by the end user is first moved to the
transactional buffer* during the interactive phase. After successfully checking the
consistency of the data using check_before_save, finalize method. Consistent data
is persisted to the persistence table* during the save phase. The logic for the
interactive phase is written inside the local handler class of the ABAP behavior pool,
while the logic for the save sequence is implemented in the local saver class.

* Controlled LUW: An extension of the SAP LUW concept. It introduces a

mechanism to detect transactional consistency violations. Controlled LUW is
implicitly supported by newer ABAP concepts like RAP. In non-RAP transactions, it
can be implemented by explicitly setting transactional phases using static methods
of the CL_ABAP_TX class.

13
* Transactional Buffer: A runtime-generated temporary memory (not a physical
database). It holds raw data entered by the end user and is cleared once the data is
moved to the persistence table.

* Persistence Table: The database table on which the application is built. It is called
a persistence table because the records created in the application are ultimately
stored (persisted) in this table.

14