RAP Made Easy — No More a Buzzword

Main objective:

My main objective in releasing this documentatio/notes is to help you

understand different real-time use cases of RAP and get to the core of it —
something I felt was often missing in most available resources. Many
documents and YouTube tutorials explain what RAP is, but rarely dive into
real-time use cases, good coding practices, how to test it, or how it works
across different environments.

This documentation answers all those topics. That’s why I start right from the
prerequisites for RAP — explaining topics like the different SAP systems and
how they differ, various tech stacks for Fiori, when to use RAP, and real-
world RAP use cases. I also break down buzzwords like extensibility (side-by-
side, developer), clean core, and how that’s achieved using Steampunk and
embedded Steampunk.

A huge part of this book focuses on the architecture and flow of RAP from
multiple viewpoints, like list & object pages, analytics RAP, unmanaged
queries, and much more.

All functionality is explained with step-by-step instructions and examples.

I’ve also provided a GitHub link so you don’t have to start from scratch — you
can directly consume my code.

I’ve further covered AUnits and the Test Double Framework, with examples
tailored for RAP.

GitHub link for all my code:

[Link]

Disclaimer:

This is not official SAP documentation. It’s a document I wrote primarily

based on my perspective and experiences with RAP. However, I’ve included
as many links as possible to the standard documentation, so you can cross-
reference and learn more in depth.
 Table of content:

1. Prerequisites for Learning RAP - pg no: 1

1.1 Knowing About Different SAP Systems
1.1.1 S/4HANA On-Premise
1.1.2 S/4HANA Public Cloud
1.1.3 S/4HANA Private Cloud
1.1.4 ABAP Environment in BTP (Steampunk)
1.2 ABAP Language Versions
1.2.1 Standard ABAP
1.2.2 ABAP for Cloud
1.3 Knowing About Fiori
1.3.1 SAP Fiori and Fiori Launchpad
1.3.2 Types of Fiori Applications
[Link] Freestyle Fiori
[Link] Fiori Elements
1.3.3 Different Tech Stacks for Creating Fiori Applications
[Link] CAPM (Cloud Application Programming Model)
[Link] RAP (RESTful ABAP Programming Model)
[Link] BOPF (Business Object Processing Framework)
[Link] SAP Build Apps
1.4 Supporting Tools and Concepts
1.4.1 SAP Business Accelerator Hub
1.4.2 Clean Core Principle
[Link] ABAP Environment in BTP (Steampunk)
[Link] Embedded Steampunk in S/4HANA Cloud
1.5 Extensibility in ABAP
1.5.1 What is an Extension?
1.5.2 Types of Extensibility
[Link] Classic Extensibility
[Link] Developer / On-Stack Extensibility
[Link] Side-by-Side Extension
[Link] Key User Extensibility
1.6 Use Cases of RAP
1.6.1 Fiori App with Fiori Elements
1.6.2 OData V2/V4 Custom APIs
1.6.3 Analytical Applications
1.6.4 Clean Core (3-Tier Extensibility)
1.6.5 Side-by-Side Extension in BTP
1.6.6 Unmanaged Queries
 1.6.7 Developer Extensibility in Public Cloud
1.6.8 RAP in Steampunk & Embedded Steampunk
1.7 WH Questions of RAP
1.7.1 Why Learn RAP
1.7.2 What is RAP
1.7.3 Where to Start

2. Architecture of RAP - pg no: 12

2.1 Data Model Layer
2.1.1 Transactional vs Query Access
2.1.2 CDS View Types
[Link] Interface Views (Basic & Composite)
[Link] Consumption Views (Projection Views)
2.1.3 Managed Queries (Static Data Fetching)
2.1.4 Unmanaged Queries (Dynamic Data Fetching)
2.1.5 Analytical Data Models (Cube, Dimension, Fact Views)
2.2 Projection Views
2.2.1 Purpose of Projection View
2.2.2 Provider Contracts
[Link] Transactional Query
[Link] Transactional Interface
[Link] Analytics Query
2.2.3 Metadata Extensions
- Priority with @[Link]
- UI/Annotation Separation
2.3 Business Objects (BO)
2.3.1 Root and Leaf Structure
2.4 Behavior Definition (BDEF)
2.4.1 Interface and Projection Layer BDEF
2.4.2 Types of BO Implementation
[Link] Managed
[Link] Managed with Unmanaged Save
[Link] Managed with Additional Save
[Link] Unmanaged
2.5 Behavior Implementation (ABAP Behavior Pool)
2.5.1 Global and Local Classes
- Security and Development Boundaries
2.5.2 Handler Class
- Operations in Interaction Phase
2.5.3 Saver Class
 - Operations in Save Phase
2.5.4 CL_ABAP_BEHV Foundation
- Handler / Saver Base Classes
- % Derived Types and Components
2.6 Services
2.6.1 Service Definition
2.6.2 Service Binding
[Link] OData V2/V4 - Web API
[Link] OData V2/V4 - UI
[Link] InA-UI (Analytics)
[Link] SQL-UI
2.7 BO Runtime
2.7.1 Controlled LUW
2.7.2 Transactional Buffer
2.7.3 Persistence Table
2.7.4 Check, Finalize, and Save Sequence

3. Draft - pg no: 26
3.1 Why do we need draft / Drawbacks of non-draft
3.2 How draft helps
3.3 Locking in draft
3.3.1 Exclusive lock
3.4 Total ETag
3.4.1 What is Total ETag
3.4.2 Why Total ETag vs ETag Master/Dependent
3.5 Steps to add draft
3.5.1 In BDEF interface
3.5.2 In BDEF for child entity
3.5.3 In BDEF projection
3.6 %key vs %tky
3.7 Draft actions
3.7.1 Edit
3.7.2 Activate
3.7.3 Resume
3.7.4 Prepare
3.7.5 Discard
3.8 Draft flows
3.8.1 Create flow
3.8.2 Edit flow
4. EML Statements
- pg no: 35
4.1 Common additions
4.1.1 In-local mode
4.1.2 Privileged mode
4.2 Read EML
4.2.1 Short form (single entity)
4.2.2 Long form (multiple entities)
4.2.3 Dynamic read
4.2.4 Read by table or fixed value
4.3 Modify EML
4.3.1 Multiple modify (create from itab)
4.3.2 Hardcode few values
4.3.3 Create by association
4.4 Get permission EML
4.5 Commit entities EML
4.6 Modify augmenting EML

5. Numbering - pg no: 41
5.1 Early numbering
5.1.1 External early numbering
5.1.2 Managed internal early numbering
5.1.3 Unmanaged internal early numbering
5.2 Late numbering
5.2.1 Adjust numbers in saver
5.3 Summary of numbering

6. Locking in RAP - pg no: 45

6.1 Road Map for Learning Lock Mechanism in RAP
6.2 Concurrency Control
6.2.1 Optimistic Concurrency Control (E Tag)
6.2.2 Pessimistic Concurrency Control (Locking)
6.3 Optimistic Concurrency Control (E Tag)
6.3.1 How E Tag Works
6.3.2 Variants of E Tag
[Link] E Tag Master
[Link] E Tag Dependent
[Link] Total ETag
6.3.3 E Tag Definition
7. Authorization in RAP - pg no: 50
7.1 Overview and concept
7.2 Creating authorization objects (different systems)
7.3 Global vs instance authorization
7.4 Authorization vs precheck
7.5 Authorization for actions and functions
7.6 Read vs modify authorization
7.7 Bypassing authorization (in-local / privileged)

8. RAP: Action - pg no: 56

8.1 What is action?
8.2 Trigger points
8.2.1 Via UI
8.2.2 Via EML
8.3 Syntax of action
8.3.1 Internal
8.3.2 Repeatable
8.3.3 Input/Output Parameters
8.4 Steps to create
8.4.1 Define in BDEF
8.4.2 Implement in ABP
8.4.3 Add EML/UI trigger
8.4.4 Expose in projection
8.5 Types of action
8.5.1 Factory vs non-factory
8.5.2 Non-factory
[Link] Instance
[Link] Static
8.5.3 Factory
[Link] Instance (copy)
[Link] Static (default create)
8.6 Save action
8.7 Function (read-only)

9. RAP: Precheck - pg no: 65

9.1 What is precheck?
9.2 When used
9.3 Precheck vs validation
 9.4 Steps
9.4.1 BDEF interface
9.4.2 Implement in ABP

10. RAP: Default Values Functions - pg no: 68

10.1 What is it?
10.2 Parameter note
10.3 Where used
10.4 Steps
10.4.1 BDEF interface
10.4.2 Implement in ABP
10.4.3 Expose in projection

11. RAP: Augmentation - pg no: 71

11.1 What is it?
11.2 Notes
11.3 Applicable operations
11.4 MODIFY AUGMENTING ENTITY
11.5 Flow in interactive phase
11.6 vs Determination
11.7 Steps
11.7.1 BDEF projection
11.7.2 Implement in ABP

12. RAP: Determination - pg no: 76

12.1 What is it?
12.2 Notes
12.3 Triggers
12.4 Good practices
12.5 On modify vs on save
12.6 Flow
12.6.1 Modify
12.6.2 Save
12.7 On save vs finalize
12.8 Steps
12.8.1 BDEF interface
12.8.2 Implement in ABP

13. RAP: Validation - pg no: 80

13.1 What is it?
 13.2 Notes
13.3 Triggers
13.4 vs Precheck
13.5 Flow
13.6 Steps
13.6.1 BDEF interface
13.6.2 Implement in ABP

14. RAP: Feature Control - pg no: 84

14.1 Roadmap
14.2 Static
14.2.1 Mandatory
14.2.2 Readonly
14.2.3 Suppress
14.3 Dynamic
14.3.1 Steps
14.3.2 Instance
14.3.3 Global

15. RAP: Side Effects - pg no: 88

15.1 Why needed
15.2 No GET call on draft
15.3 Solution: side effect
15.4 Steps
15.4.1 BDEF interface
15.4.2 Use in projection

16. RAP: Facade - pg no: 91

16.1 Why not direct persist
16.2 Why avoid BAPI in cloud
16.3 Business ops in cloud
16.4 RAP facades (C1 BDEF)
16.5 References
16.6 Using modify/commit entities

17. RAP: Background Processing Framework (BGPF) - pg no: 96

17.1 Why needed
17.2 Controlled vs uncontrolled
17.3 How it works
17.3.1 Starter vs operation class
 17.3.2 Wrapper of BGRFC
17.4 Workflow
17.4.1 Create process instance
17.4.2 Save for background exec
17.4.3 Commit triggers session
17.4.4 Execute + save sequence
17.5 Steps
17.5.1 Starter class
17.5.2 Commit
17.5.3 Operation class
17.6 Monitoring with cross trace

18. RAP: Business Event - pg no: 102

18.1 What is a RAP business event?
18.2 Example: create new BP on BP update
18.3 Steps to create event
18.3.1 Define event in BDEF (parameters, side effects)
18.3.2 Raise event (inside save method)
18.3.3 Consume event
[Link] Local consumption (event handler class)
[Link] Remote consumption (via Event Mesh)
18.3.4 Notes on event mesh availability

19. AUnits for RAP - pg no: 105

19.1 What are AUnits? (Unit tests for RAP validations, determinations, actions,
CRUD)
19.2 Reference for TDD (Test Driven Development)
19.3 Basics of AUnits
19.3.1 Local vs global test classes
19.3.2 FOR TESTING addition
19.3.3 Risk level (CRITICAL, DANGEROUS, HARMLESS)
19.3.4 Duration (SHORT, MEDIUM, LONG)
19.3.5 Helper vs test methods
19.3.6 Good practices (positive & negative cases)
19.4 Flow of test case
19.4.1 CLASS_SETUP
19.4.2 SETUP
19.4.3 TEARDOWN
19.4.4 CLASS_TEARDOWN
19.5 Running test class (ABAP Unit vs application)
 19.6 Test Double Framework
19.6.1 Why needed (mock/stub dependencies)
19.6.2 STUB vs MOCK
19.6.3 Typical RAP dependencies (auth, SAVE, EML, validations)
19.7 Example: validate check_country
19.7.1 Identify CUT & dependencies
19.7.2 Friend test class to access private methods
19.7.3 Setup mock for CDS view
19.7.4 Example single test case method

20. Deploying RAP Application - pg no: 112

20.1 RAP apps not consumed from Eclipse, usually via FLP/Work Zone
20.2 Cloud Foundry deployment
20.2.1 Using BAS, deploy to CF as HTML5 app
20.2.2 Work Zone vs classic FLP
20.2.3 Key links
20.3 Direct deployment in ABAP Environment
20.3.1 BTP trial and references
 Prerequistes for leaning rap:

Knowing about different sap systems:

Based on the system you are using, the usage of RAP (RESTful ABAP Programming
Model) will differ. So, it is important to understand the different SAP systems:

1. S4 hana on premise:
This is primarily used by large-scale companies that require extensive
customization and want full control over their infrastructure (hardware,
databases, servers). The customer is responsible for deployment and
maintenance.

2. S4 hana public cloud:

S/4HANA Public Cloud operates on the SaaS (Software as a Service) model,
where you purchase a complete product provided by SAP. It is comparatively
more affordable and best suited for new customers who want to operate
entirely in the cloud.

The public cloud runs on a shared platform and can only be accessed through
Eclipse ADT (ABAP Development Tools). GUI access is not supported, and you
cannot directly access standard tables or BAPIs. Instead, you must use CDS
views and business object interfaces (RAP facades).

3. S4 hana private cloud:

This is suitable for customers who want to move to the cloud but prefer not
to modify their existing objects. Unlike the public cloud, it follows the IaaS
(Infrastructure as a Service) model and operates in a dedicated, single-tenant
environment rather than a shared platform.

Here, you can use both the SAP GUI and Eclipse ADT and supports classical
abap aswell.

4. Abap environmnet in btp/steampunk:

SAP BTP (Business Technology Platform) provides a PaaS (Platform as a
Service) environment where you can build and deploy cloud-based
applications. In this environment, you cannot access standard tables or
standard objects; everything must be custom-developed.

1
Abap language version:

You might have noticed when you create project, it asks you whether it’s a ABAP
project or abap cloud project.

If you create cloud project it supoprts only abap for cloud and normal abap project
supports both standard abap and abap for cloud development.

Standard abap:

 Is done using gui and eclipse adt, These are nothing but your classical abap
ricefw and modern abap like cds,rap. These doesn’t have any restriction for
cloud check.

Abap for cloud:

 can be done only using eclipse adt, It doesn’t support classical abap like
ricefw. Only supports modern abap like rap, cds, cloud badi, classes. you
cannot use objects that are declared for standard abap directly in abap on
cloud. They have to be released in c1 contract. If they need to be used. That

2
 is the reason we don’t use standard table and bapi Instead, you must use
CDS views and business object interfaces (RAP facades).

Note:
if you are migrating code from standard to cloud or releasing it for c1
contract. Always do atc check with ABAP_CLOUD_READINESS variant

Refer this link to better understand both:

 [Link]
US/abenabap_versions.htm
 [Link]
members/smooth-transition-to-abap-for-cloud-development-cheat-
sheet/ba-p/13571567

Knowing about fiori:

SAP Fiori: is a technology used to build modern, user-friendly applications.

SAP Fiori Launchpad (FLP): It is used to organize and access applications

through a single interface. You can imagine the FLP as your phone's home
screen, and the Fiori applications as individual tiles—similar to apps on your
phone.
Fiori Launchpad can be accessed via a web browser or through the SAP
Business Client (transaction code: /UI2/FLP).

Refernce link:
[Link]
fiori/using-sap-fiori-launchpad_a9103226-f903-4afb-b471-c07be29c59e3

3
Types of Fiori Applications

 Freestyle Fiori:
In this approach, developers manually design the ui and ux of application
using front-end technologies like SAPUI5. It offers full control over the UI
making it suitable for custom requirement from front-end level.

 Fiori Elements:
This approach uses predefined UX templates provided by SAP to develop
applications with minimal coding. Instead of building the UI from scratch, you
consume annotations to generate the interface. Technologies like RAP
(RESTful ABAP Programming), CAP (Cloud Application Programming Model),
and SAP Build often use Fiori Elements to accelerate development.

reference link:
[Link]
members/sap-fiori-elements-vs-freestyle-apps-when-to-use-what/ba-p/14100734

Different Tech Stacks for Creating Fiori Applications

1. CAPM (Cloud Application Programming Model):

CAPM is ideal for building cloud-native applications directly on SAP BTP
(Business Technology Platform). It provides seamless integration with BTP
services and is primarily built using Java or [Link], typically developed in
SAP Business Application Studio (BAS). It supports side by side extension
using released apis.

2. RAP (RESTful ABAP Programming Model):

RAP is best suited for developing applications tightly coupled with S/4HANA
systems (public cloud, private cloud, or on-premise). It is based on
ABAP .Supports both developer extension and side-by-side extensions via
ABAP Environment (Steampunk) on BTP.

3. BOPF (Business Object Processing Framework):

BOPF (Business Object Processing Framework) is an older ABAP-based
framework formerly used to build Fiori applications. It lacks support for the
ABAP Environment (Steampunk), making it unsuitable for cloud development.
Development is fragmented, with BOs created in SAP GUI and CDS views in
Eclipse. Additionally, it does not support OData V4, It is useful for building
application on on premise. Its widely used in TM module.

4
4. SAP Build Apps:
SAP Build Apps is used to create Fiori-like applications with minimal technical
expertise by leveraging no code-low code. It's ideal for business users or end
users who want to build applications quickly without deep coding knowledge.
 Best suited for: Rapid app development, prototyping, or empowering
non-developers
 Strengths: Drag-and-drop interface, pre-built integration s, and tight
coupling with BTP services

SAP Business Accelerator Hub:

The SAP Business Accelerator Hub is a platform where you can find released
objects such as APIs, CDS views, Business Objects (BO), events, and more.
These resources are particularly useful for extensibility scenarios, including
side-by-side extensions and developer/on-stack extensibility for various SAP
products. Using the released content from the hub helps minimize the need
to create custom objects, promoting reuse and standardization. In the
context of RAP (RESTful ABAP Programming), the hub can be leveraged for
developer extensibility to access information about CDS views, BO interfaces
(RAP façades), and cloud BADIs.

Link to the Business Accelerator Hub: [Link]

Clean Core Principle :

The clean core principle refers to keeping your core system—typically your
S/4HANA system—as free from custom modifications as possible. The goal is
to avoid unnecessary changes to the standard SAP code-base to ensure the
system remains cloud-ready and upgrade-stable.

What does this mean for developers?

 Leverage standard objects from the SAP Business Accelerator Hub
whenever possible.
 When custom development is necessary, create objects that are cloud-
compatible, adhering to the principles of ABAP for Cloud Development.
This approach ensures that your extensions are aligned with SAP's cloud
strategy and can withstand future upgrades without breaking. Products like
s/4 hana public cloud inherently enforce a clean core approach because
modifications to the core system code are not allowed. But in case of private

5
 cloud/on premise, if you have standard abap repositories you can use
wrapper to make it cloud ready, using 3 tier extensibility.

Environments for clean core:

 ABAP Environment in BTP (formerly known as Steampunk):

The ABAP environment is one of the services provided by SAP for ABAP
developers to build applications directly on BTP. This allows developers to
follow the clean core principle and implement side-by-side extensions.

If you are interested in learning btp refer this link:

[Link]
started

 ABAP Environment in S/4HANA Cloud (Embedded Steampunk):

Embedded Steampunk refers to applying the clean core, cloud-ready, and

upgrade-stable principles directly within your core system—without relying
on BTP. The core system can be your S/4HANA On-Premise, Public Cloud, or
Private Cloud edition.

How is this achieved?

When you create an ABAP repository object using ABAP for Cloud
Development, it adheres to cloud standards and doesn’t have any
dependencies of you standard abap( you can release with c1 contract, if you
need to access standard abap ).

Note: its only for system version more than 2208.

6
Extensibility in ABAP

What is an Extension?
An extension adds additional functionality on top of the standard features
provided by SAP. It's important to understand that extensibility does not
involve modifying standard objects. Instead, it allows you to extend existing
functionality without altering the core SAP code.

To explore ABAP extensibility with real-time examples, use this link:

[Link]
er/#/SearchList

7
Types of Extensibility in ABAP:

1. Classic Extensibility
Classic extensibility involves directly modifying standard SAP code through
enhancements, user exits, or modifications in classical ABAP.
This approach is not recommended because it violates the clean core
principle

2. Developer Extensibility / On-Stack Extensibility

In S/4HANA Public Cloud, developer extensibility—also known as on-stack
extensibility—allows you to extend standard business logic using cloud-
compliant techniques.
You can extend:
 CDS Views
 Business Object Interfaces (RAP Facades)
 Cloud BADIs
However, to use an object for developer extensibility, it must be released
under a C1 Contract, ensuring it meets SAP’s cloud standards.

In order to find about the object you can go to business accelerator hub
public cloud->on- stack extensblity.

3. Side by side extension:

Side-by-side extension refers to building custom applications that run on SAP
BTP (Business Technology Platform). These applications interact with the
core system using released APIs, ensuring the core remains untouched and
clean.
In this model, the core system—such as S/4HANA On-Premise, Private Cloud,
or Public Cloud—exposes business functionality via APIs. The custom

8
 application, developed on BTP, consumes these APIs to deliver additional
features or business processes.

How Side-by-Side Extension Works in ABAP?

To achieve side-by-side extensibility in ABAP, you use the ABAP Environment
on BTP (formerly known as Steampunk). This allows ABAP developers to
build cloud-ready applications. For other technologies like SAPUI5, Java, or
[Link], the extension is done via released APIs to communicate with the
core system. Explained in detail in use cases of rap.

4. Key user extensibility:

It’s not usually done by developers, as the name tells its mostly done by key
users/end users who are not much aware of coding and want to leverage no
code/low code to extend. Usually, they does it through Fiori launchpad, like
changing theme, hiding fields.

9
Use cases of rap, I have primarily focused on common use case:

 Developing Fiori application using Fiori elements

[Link]
 Creating OData v2, v4 custom Api
 Building analytic s Fiori application:
[Link]
analytics..html#25592d34-c117-44a5-9b9a-db2310dd062f
 Clean core extensibility, 3 tier extensibility: converting custom objects in s/4
Hana on premise/ private cloud to cloud ready
[Link]
extensibility-for-sap-s-4hana-cloud/explaining-extensibility-model-best-
practices_e290f382-800e-40ef-a203-85a13115f487
YouTube video: [Link]
 Side by side extension: Consuming custom Api in your local system in btp.
With the help of service consumption model, custom entities and
unmanaged rap
[Link]
consume-s4-hana-cloud-api-in-sap-btp-abap-environment-by-using/ba-
p/13549731
 Consuming Unmanaged queries in rap
[Link]
query
 Developer extensibility: Adding action, new fields, determination, validation
in any of the business process in s4 Hana public cloud
[Link]
extensibility-for-sap-s-4hana-cloud/explaining-developer-
extensibility_f2683861-d69e-4a59-9e3e-01e3cc20fb0f
[Link]
[Link]/pub/mmcp/[Link]?show=project!PR_8C70C0B4D34D9CB
6:uebung#22
 Rap is famous programming choice for steampunk and embedded steampunk
[Link]
members/embedded-steampunk-what-s-under-the-hood-part-ii/ba-
p/13570047

10
Answering wh questions of RAP:

Why to learn rap?

 The Primary disadvantages of Bopf was that it didn’t support cloud
development, because it was highly dependent on Gui ( for developing Bo ),
In rap this was overcome and it was used as one of the major tool for cloud
programming.
Refer this blog how rap helps in cloud compared to other tech stacks:
[Link]
members/embedded-steampunk-what-s-under-the-hood-part-ii/ba-
p/13570047
 Use of Fiori elements, as a backend developer it helps you to build a full stack
application without use of frontend coding.
 Many good features from ui5 were brought to rap, like draft, side effects and
much more.
 Leverage of SADL framework – RAP uses the SADL framework mainly for read
operations. I’ll explain this in more detail in the upcoming sections. For
analytics application, analytics engine is used.
 In classical ABAP, there was a risk of inserting inconsistent data. RAP
overcomes this using controlled LUW (Logical Unit of Work).
This means any user input is first stored in a transactional buffer, and only
after passing multiple checks and validations, the consistent data is saved to
the persistence table in a defined save sequence.
 Helpful in providing seamless integration to cloud services, ex: using business
event to communicate with event mesh.
[Link]
[Link]
events-with-advanced-event-mesh-2-creating-custom-business/ba-
p/13914171

What is rap?
It’s a framework used by abapers to build cloud ready Fiori application, odata
services, extension and etc. it works only from s4 hana 1909 system.

Where to start with rap?

You can use btp trial version to learn rap, if you don’t have any sap systems.
Btp trial version has 30 days trial period, and if you login continuously it will
also extend to 90 days in total.

11
  Since rap can be used only in eclipse ADT, First download eclipse adt:
Follow this steps to download: [Link]
install-adt..html
 Then setups abap environment in you btp trial account:
[Link]
onboarding..html

Architecture of RAP:

12
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).
 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

13
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.

14
 Refer this link for unamnaged querry:
[Link]
entity..html

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.

15
 Refer this blog to learn in detail about metadata extension :
[Link]
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).

16
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

Business object(BO):

17
 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.

Managed with Unmanaged Save

18
 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.

19
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

20
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.

21
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

22
 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.

23
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.

24
* 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.

25
 RAP: Draft

Github link for all my codes:

[Link]

Why do we need draft? Or drawbacks of non - draft?

1. Odata services are rest api, which means they are stateless. They don’t store
any session data. Since its stateless,any termination in current session
cannot be recovered. For example lets say you are creating an sales order
with rap non-draft app. If the power is lost whatever changes you have
done is lost, because its stateless.
2. No feedbaack (eg; message,feature control) until “save” is triggered.

How does draft helps overcoming the above issues?

1. Draft allows to store data in draft table as temporay state, allowing

“stateless communication with stateful capabilities”.
2. Draft has their own workflow( which I will cover in detail in upcoming pages)
like authorizarion, precheck, validation. Every time you make changes or
resume, it triggers draft actions and goes through varies [Link]
helps in early feedback and prevents data loss.

26
Locking in draft:

Exclusive lock:

 As soon as a user starts working on a draft(edit,create,resume). It sets an

exclusive lock. It is locked for other users. The exclusiveness is maintained
for a defined period of time. After that period, the draft goes into an
optimistic lock phase. In this phase, the draft can either be resumed by the
same user or discarded.

Total Etag:

What is Total etag?

 The total ETag is a designated field in a draft business object to enable

optimistic concurrency checks during the transition from draft to active
[Link] total ETag always refers to the complete BO. As soon as an
instance of any BO entity is changed, the total ETag is updated. Its value is
compared when resuming a draft instance to ensure that the active data has
not been changed after the exclusive lock has expired.

27
Why do we need Total etag, when we have etag master/dependent?

 In draft bo, there are 2 tables, draft table and active table. When you want
draft bo to be consistent the total ETag value of the draft instance should be
compared to the total ETag value on the active instance. Only if the values
coincide can the draft be resumed. etag master/dependent validates only
etag in active table. So its mandatory to include Total etag in draft bo.

Steps for adding draft functionality:

Bdef interface:

1. Add “with draft”.

2. You will get an suggestion to add draft table. So create a draft table with the
help of suggestion or click ”ctrl+1”.
3. Add all draft action (like edit,acivate,discard,resume) in root entity.
4. Add Total E-tag as its mandatory.

For child entity add assocaition with draft and etag dependent.

28
Bdef projection:

1. Add “use draft.

2. Add “use tag”.
3. Use all the draft actions.
4. Add “with draft in assciation”.

%key vs %tky :

 It is always recommended to use %tky to uniquely identify record as it

contains both %key and %is_draft. You can use %key in non draft scenerio,
but we need to manually add %is_draft if we are upgrading to draft.

Draft action:

 Draft actions are actions that are implicitly available for draft business
objects. draft actions can be completely handled by the RAP framework, in
managed and in unmanaged implementation scenarios.
 An application developer can add additional implementation for each draft
action if the addition with “additional implementation” is used.
 Trigger conditions:
 UI trigger points like edit,save button.
 Triggered using eml execute action.

List of draft action :(refer end of the page to see detailed flow)

 Edit action: When user clicks edit button, The data from active instance is
copied to draft table and exclusive lock is created.

29
  Activate action: is the opposite of edit action, it is used to copy data from
draft instance to active instance ,deletes data from draft table and release
the exclusive lock.

 Resume action: used to put exclusive lock, when user starts resuming from
modified session.

 Prepare action: is an determine action(these are actions which will trigger

determination and validation, which are mentioned under detrmine action)
used to validate the value during activate action.

 Discard action: Triggered when user clicks on discard button, it deletes the
data from draft table and release the exclusive lock.

Note: If triggered by button %is_draft is always true(by framework). If we trigger by

eml, we can mention false, so it will directly create in active table.

Flow of draft :

Flow for create:

1. When user clicks create button or trigered by eml with %is_draft = true, new
key is assigned and draft instance is created.

30
 Draft table

2. If there is any termination of the session. The data will be in draft table.
3. Once you open the session again “Resume action” will place the exclusive
lock and you can fill in data.
4. Once you fill the fields and click on save, “Activate action” will be triggered
which will copy the data from draft instance to active instance and persisted
to persistance table. Then the draft data is discarded and exclusive lock is
release.

Persistence table

Draft table

Flow for Edit:

1. When user click on edit button, “Edit action” is triggered, the data will be
copied from active instance to draft table.

Persistance table

31
 Draft table

2. Once the user provides a value and clicks the 'Save' button, the 'Activate'
action will be triggered. This action moves the data from the draft instance
to the active instance, deletes the data from the draft table, and releases
the exclusive lock.

Create workflow for draft

32
Edit action workflow for draft

33
Activate action workflow for draft

34
 RAP: EML staments

Common additions in eml:

1. In-local mode:
 We know that both Modify and read eml will trigger the interactive phase of
rap. But if we don’t want to call the authorisation and feature control
methods, then we can use in-local mode.

2. Privieged mode:
 If you want to use the privilaged mode additon in eml, your bdef interface
should have “with privilaged mode”.
 In Bdef we will define certain auth object under privilage mode, if we use
the privilage mode in eml we will get exemption from the authorization
check for that auth object defined in bdef.

Read EML stament:

1. Read entity(short form)

 If you want to read only a single entity, then you can use read entity. In this
example you are reading the data from tx buffer which matches the key and
the corresponding result are added to lt_lfa2.

35
2. Read entities(long form)

 If you want to read multiple entity of a bdef, then you mention the name of
the bdef interface and their corresponding entities( here zi_lfa1_2 and
zi_lfb1_2).

3. Dynamic read(dynamic form)

 The dynamic form of the READ statement allows collecting multiple instances
to be read in multiple entities in one READ statement.
 Op_tab, here is an operation table, where you provide whether it’s a read or
read by association in op field, the entity to be read in instance tab and the
output will be filled inside result tab.

36
4. Reading based on a table and based on a fixed value

Modify eml

As mentioned in read eml, modify also has similar syntax: short,long,dynamic

form. I am not repeating the concept again, as they are similar.

1. To modify entries based on a table.

 When you want to change multiple records of a tx buffer. Use “create from
itab” syntax instead of running eml inside a loop, to reduce time
complexcity. Append all the records into an itab and run eml only once, this
way the code is optimized.

 Use auto fill cid, if you don’t want to provide cid manually.

37
2. To hard code value

 In scenerio where you need modify only few rows, you can use “with value
itab” syntax.

3. Create by association

 In create by association scenerio, %cid of header and %cid_ref of item

should be same.
 With the help of assocaition name, we can do create by association

38
Get permission eml:

 It is used to check accessiblity of the particular entity. It can do varies checks

like authorization check, feature control
 Based on the querry it will execute the corresponding method, for ex, if we
need to check the global authorization. It will execute that method and will
pass the results.
 In this example, I am checking if I have access to create bo inside static
action. In this scenerio it will call the global authorization method and willl
pass the result.

Commit entities eml:

 Commit entities will trigger the save sequence.

 Its part of rap luw, to persit the data into db.
 Commit entities begin,end (for late numbering), you have to use convert key
syntax inside commit entities for late numbering.

 If your commit should trigger only early save sequence, then use the
addition “in simulation mode”, this will execute only early save sequence
and not the save method.

39
Modify augmenting eml:(refer my augmnetatin blog)

 A special variant of MODIFY ENTITY, ENTITIES that is only possible in the

context of projections bo.
 For the statements, no response parameters can be specified, i.e. the
additions FAILED, MAPPED or REPORTED cannot be used.
 An ABAP EML MODIFY statement using the addition AUGMENTING must not
overwrite fields of the original [Link] done, dump will be thrown:

40
 RAP: Numbering

Road Map for Learning Numbering in RAP

Early numbering:
The numbering type early numbering refers to an early value assignment for the
primary key field. In this case, the final key value is available in the transactional
buffer instantly after the MODIFY request for CREATE.

[Link] Early Numbering:

• consumer provides key
• Key should be unique
key should be editable in create, and non-editable in modify. syntax:

41
[Link] Internal Early Numbering:
• Managed early numbering is only possible for
key fields with ABAP type raw (16) (UUID) of
BOs with
implementation type managed.
• UUID is read-only.

syntax:

[Link] Internal Early Numbering:

• Unmanaged Early Numbering is available in Managed and Unmanaged
Implementation Scenarios with Draft Capabilities
• Key is read-only.

Syntax:

Bdef:

42
 Local handler class:

Late numbering:
• The RAP runtime engine assigns values to the primary key fields.
• In the ABAP behaviour pool, the RAP saver method adjust_numbers must be
implemented to assign a final primary key value for each entity instance.
• The key value for an instance is assigned just before the instance is saved
on the database. Thus, a gapless assignment of unique keys is ensured.
• Late numbering is available for managed and unmanaged implementation
scenarios with and without draft.

Note:
• late numbering can't be external, since a consumer can't influence the SAVE
sequence after the point of no return.

43
 • If draft enabled, it is mandatory that the RAP draft table has an
additional key field DRAFTUUID of data type raw (16).

Summary:
• passed externally by the application user: External numbering
• set internally by the framework: Managed internal
• set internally by developer (implementation the FOR-NUMBERING
method): Unmanaged Internal

44
 Lockingin RAP

Road Map for Learning Lock mechanism in RAP

Concurrency Control

Concurrency control prevents concurrent and interfering

databaseaccessofdifferentusers. Itensuresthatdatacanonly be changed if data
consistency is assured.

1. Optimistic Concurrency Control:

Itallowsmultiple userstochangerecords simultaneously. Ex: E tag

2. Pessimistic Concurrency Control (Locking)

Pessimistic concurrency control prevents simultaneous

modificationaccess todata on thedatabase bymorethanone user.
Ex: Conventional locks available in se11

45
Optimistic Concurrency Control (E tag):

HowETagWorks:

1. When a user accesses a business object, a batch call (read operation)retrieves

[Link] that tells you the last timethe record was
modified.

Ex:Whenthebusinessobject“3eb9b5aa-d3ff-1edf-b583- f100044fee6b”is
accessed, a batch call fetches the "last changed at" timestamp.

2. Whena usermodifiestherecordandhits"Save," thesystem checksifthee tag

stillmatchesusinganIf-Matchcondition. Ifthee tagis unchanged,thesystem
modifiese tag with currenttimestamp,alongwithupdatedbo.

46
 checksthe E tagvalue

Etagismodifiedwithcurrenttimestamp
3. Ifthee tagdoesn’t match,it meansanotheruserhas
[Link], advisingthe user to
refreshbefore proceeding.

47
Variantsof E tag:

ETagMaster:

 Anentityisane tagmasterifthechangesoftheentityare trackedinafield

withintheentityitself.
 It logs thechanges of a businessobjectand typically has the etagfielddefinedin
thebehaviourdefinition(etagField).
 Rootentitiesareoftenetagmastersastheytrackthe changes forall
relatedentities.
Syntax:etagmasterChanged_on

ETagDependent:

 Anentityisetagdependentifitlogsitschangesinanother business object's

entity field.
 Theseentitiesareassociatedwiththeetagmasterentity, whichis specified
throughthe behaviourdefinition
(_AssocToETagMaster).

48
  Whenchangesarerequestedforanetagdependententity, the systemchecks
thee tagvalue ofits masterentityto
ensure no conflictingchanges occurred.

 Syntax:etagdependentby_Assoc

Total ETag

 InaTotaletagscenario,whendraftinstancesareupdated, thesystemensures
thatonlythelatestversionof thedraft instance can be modified. This prevents
the issue where multipleusersmighttrytomodifydifferentversionsofthe
draft instance concurrently.
 It’srecommendedtousebothTotaletagandetag
master/dependenttogetherindraftscenario.
 Syntax: total e tag TotalEtagField

Etag definition

 last_changed_atwillbeusedforgeneratingtheetagvalue, auto populated

using
@[Link] annotation

 InBdefinterface, declaree tagmasterwithchanged_onfield and e tagdependent

with association, note: you can also
declarechildentityasetagmaster,butitwillnotbelocked based on root node.

 InBdefprojection,declare“useetag”toenableetag.

49
 Authorization In RAP

Authorization:

It's a similar concept to how we check authorizations in classical ABAP — for

example, by creating an authorization object, assigning it to the user, and
using the AUTHORITY-CHECK statement in the code.

In RAP, we primarily check whether the user has access to perform a specific
operation? and whether they have access to a particular business object
(BO)?.

Creating Auth object and assigning for different system:

Not all system has same way of creating auth object, for ex in private cloud
and on premise we use su21,pfcg. But in public cloud and abap environment
in btp we don’t have tcode. So I will provide links for each sytem to refer.

 S/4 hana on premise and s/4 hana private cloud:

[Link]

 S/4 hana public cloud:

 [Link]
identity-and-access-in-sap-s-4hana-cloud-public-
edition/describing-the-authorization-concept_c2007f46-2166-
4216-be72-8e5be0b8802b
 [Link]
public-cloud-mohamed-elshazly-593pf/

 Abap environment/steampunk:
[Link]
authorization..html

Steps to create authorization:

1. Declare authorization master and dependent in the BDEF interface. The

authorization master is assigned to the root entity, while the authorization
dependent is used for the child entity. When a BO is declared as
authorization-dependent, it inherits the authorization of its root BO. This

50
 means that if the user is not authorized to access the root BO, they are also
not authorized to access the corresponding child entity—and vice versa.

2. Write logic in the corresponding method generated in abap behaviour pool.

Global authorization vs instance authorization:

 Global authorization: checks if the user has access to CUD operation

 Instance authorization: Checks if the user has access to CUD operation +
access to the selected bo(field level check).

51
Detailed explanation with example:

In global authorization, we are restricting the update access for the entire BO. As
shown below, by passing 'requested_authorization' as‘01’for both update and
action, both the update and action buttons are disabled.

The approve and update button is disabled for the entire bo.

code

In Instance Authorization, we check whether the selected BO (3eb9b5aa-d3ff-1edf-

b583- f100044fee6b) has update access. If not, we populate the result with‘01’for
update and the corresponding key (3eb9b5aa-d3ff-1edf-b583-f100044fee6b).

52
 The update is disabled for bo(3eb9b5aa-d3ff-1edf-b583-f100044fee6b)

Code

Difference between authorization, precheck?

Detailed explanation with example:

In this example, I have changed the country of the BO (3eb9b5aa-d3ff-1eef-b5b0-

b978a97335af) from BE (Belgium) to IN (India) and clicked "Save."
Once this change is made, Instance Authorization checks whether the user has the
necessary authorization for the selected BO (3eb9b5aa-d3ff-1eef-b5b0-
b978a97335af).

53
 Keys as importing parameter in instance authorization

In Precheck, we validate the incoming value (country: IN) for the selected BO (3eb9b5aa-
d3ff-1eef- b5b0-b978a97335af).

Entities are passed as importing parameter

Can we implement authorization for action? How?

You can add authorization to action with the syntax ( authorization : global ) in bdef

In result we have derived component called %action, manipulate %action to

allow access to action or not.

How does authorization differ for read and modify operation?

For the Read operation, RAP architecture checks the authorization from DCL, and
for Modify, it checks from the behaviour implementation method.

54
Why authorization checks are not allowed in functions?

Function is used to read the data only, and for the Read operation, the DCL takes
care of authorization. Therefore, we do not need to mention authorization for
functions.

How do we trespass authorization?

We can use in local mode or privileged mode to trespass authorization.

55
 RAP: Action

What is action?
Actions are used to modify the BO without calling the standard operations
(CRUD buttons).

Trigger points:
1. Trigger via ui: In order to trigger the action via ui button.
Syntax:

2. Trigger internally via eml: in order to trigger internally, like inside

determination via eml.
Syntax: execute action_name

Syntax of action:

 Internal:
This means the action can be triggered only within the ABAP behavior pool (via
EXECUTE EML) and cannot be triggered externally from an OData or Fiori
application (through UI annotations).

56
 Repeatable:
Used when you want to trigger the same action from within its own
implementation. The action calls itself using the EXECUTE EML statement. Each
time EXECUTE EML is triggered, the action will recursively call itself. Be careful
to handle this properly to avoid an infinite loop. This is only possible for non-
factory, instance actions.

 Input and Output Parameters:

When you need to send requests and receive responses in a specific format or
structure, you can use input and output parameters. This is typically achieved
by using an abstract entity to define the structure of the request payload and
response.

Steps to create action:

1. Define action in BDEF interface.

2. Implement the action method in abap behaviour pool.

3. Add the trigger point via EML or ui annotaion.

4. Expose the action to ui, using “use action” in BDEF projection.

57
Types of action:

Over view of factory vs non factory action:

1. Non-factory action:
 Used to modify the existing Bo
 By default, instance action. Need to explicitly provide static, for static
action.
 Instance non-factory action is used to modify the selected BO.
 Static non-factory action has access to modify any Bo, bound to the
entire entity.
 Syntax:

58
1.1. Instance non-factory action:
Instance(you do the operation for the selected Bo only) + non-factory (not
creating any new record/bo)

Requirement: To update the country code based on the user input.

To achieve it, I have declared instance non-factory action with abstract entity
as parameter, which provides the country code from user. Since, it's an
instance action, we would get the corresponding keys of the selected
BO(9e12812e-cf28-1fe0-81f6-be9f3d6f527b). We need to modify country
code(land1) via EML for the selected BO, with the input parameter from user.
Additionally, it is required to populate the result-derived type.
Action defined in BDEF:

Abstract entity for input parameter:

59
 Action method in abp:

Note:
 Declared result as self, as the parameter result has the same type as
the entity for which the action is executed.
 You can use deep parameter(only odata v4), if you want to modify
both parent and child entity.
 Result parameter is optional, but if you have declared in BDEF interface,
its mandatory to pass result in action method, else in ui, you will get blank
value.

1.2. Static non-factory action:

Static (you do the operation for the entire Bo ) + non-factory (not creating
any new record/bo)

Requirement: To update Bo’s whose country code is IN to GE.

60
 To achieve this, we can use a static non-factory action. First, we need to fetch
details from the persistence table for the BOs that have the country code set
to 'IN'. To modify the country, use t

Action defined in BDEF:

Action method in abp:

2. Factory action:
 Used to create a new Bo
 Bound to the entire BO inside an entity
 Instance factory action/copy action: Used to copy the existing Bo and
replicate new Bo.
 Static factory action: used to create BO with some default value.
 Syntax:

61
2.1. Instance factory action(Copy action):
Instance(you do the operation for the selected Bo only) + factory (creating an
new record/new bo).

Requirement: To create vendor (BO) based on the selected vendor.

To achieve this, we can use an instance factory action. Fetch the data from
the TX buffer to be copied using the read EML statement, and create a new
BO with a new key, while copying the remaining fields from the reference BO.
Since it’s a create operation, always pass %cid in the mapped derived type.

Action defined in BDEF:

Action method in abp:

62
2.2. Static factory action:
Static (you do the operation for the entire Bo ) + factory (creating an new
record/new bo).

Requirement: To create a vendor (BO) with default value (country=IN and

name=Arunagirish)

To achieve this, we can use the modify EML with default values and pass %cid
in the mapped parameter, as shown below:

Action defined in BDEF:

Action method in abp:

63
3. Save action

 Save actions are triggered only in save sequence(finalize, adjust

number).
 A save(finalize) action can be called from the implementation of a RAP
determination on save.
 Even though its implemented in handler class, we cannot call it in
interactive phase.

Use case:
Save action is used in situations where you require to achieve certain
functionality without modify a transactional buffer.

Function:

Function is similar to action, but function is used for only reading purpose
and not modifying unlike action.

Use case of function:

Functions can act as reusable components. For example, in an ABAP behavior

pool, if you have the same code in multiple places and want to modularize it,
you can define a function that can be called from multiple methods within a
class.

Since functions are similar to actions, I won't go into detail here. You can
refer to this blog for a more in-depth explanation.

Link: [Link]

64
 RAP: Precheck

Precheck:

 used to validate the data before storing into transactional buffer.

 a method that is called before a modify request is executed on the
transactional buffer to prevent unwanted changes from reaching the
application buffer.
 executed in interactive phase.

Note: when accessing an operation with the ABAP EML statement IN LOCAL
MODE, the precheck method is not called.

Precheck can be used for following methods:

 standard operations
 operations for associations
 actions

Precheck vs validation:

65
Steps to develop precheck:

1. Add precheck in standard or action operation in bdef interface.

2. Implement the logic for precheck in abap behaviour pool.

66
Requirement: In Modify operation, restrict user to not provide country as US.

To achieve this, we have added a precheck in the update operation. Before

executing the update method, the entry will be validated in the precheck method.
In the precheck method, we check the incoming values, and if the country is the US,
we populate a warning message in the reported derived type.

67
 RAP: Default Values Functions

Default Values Functions:

 Used to assign default values in ui.

 A default values function is implemented by assigning default values to the
(parameter) .
 Default values functions are defined in the base behavior definition.
 Default values function needs to start with GetDefaultsFor. Dump is thrown
if not mainatined.

Note:
 The paramters changes depending on where you are using it. Like for
instance importing parameter is keys and static %cid.

Can be used for following operations:

 create
 create by association
 Action
 Function

Steps to develop Default Values Functions:

1. Add Default Values Function in bdef interface.

68
2. Implement the logic for Default values function in abap behaviour pool.

3. Expose the default value functions in bdef projection.

69
Requirement: To assign default value(country ‘DE’ and name ‘default’) in ui,
when the user clicks “create” button.

To achieve this, we have to append the default value in result. As its create
operation. Its mandatory to pass %cid. Depending on where you are using default
value function concept the parameters may vary and needs to be altered
accordingly.

70
 RAP: Augmentation

Augmentation:

 used to enhance the modify request, before it reaches transactional buffer.

 Augmentation is available for projection BDEFs only.
 The augment methods are called before the create,update method - after
pressing the "Save" or "Create" button on the object page. And only, if
there has been changes on the BO.

Note:
 It is not possible to set a field in augment which was already set for the
original instance. For example, values set in the original request cannot be
changed. Only fields which are unset in the original request can be added.
 It is not possible to set fields in augment that are defined as read only .

The following operations can be augmented:

 create
 update
 create by association

In Augmentation method,we cannot use a normal read, modify eml as the data is
not moved into tx buffer yet. So we need to use:

ABAP EML - MODIFY AUGMENTING ENTITY:

 A special variant of MODIFY ENTITY, ENTITIES that is only possible in the

context of projections bo.
 For the statements, no response parameters can be specified, i.e. the
additions FAILED, MAPPED or REPORTED cannot be used.
 An ABAP EML MODIFY statement using the addition AUGMENTING must not
overwrite fields of the original [Link] done, dump will be thrown:

71
Flow of augmentation method in interactive phase:

Differnce between augmentation and determination:

Both Augmentation and determination are similar concept, as both are used to
modify the request based on some standard trigger condition. But here are some
differnces.

Augmentation Determination
Used to modify the request before Modifies the request after reaching
reaching transactional buffer. transactional buffer.
Used only in BDEF Projection Used only in BDEF Interface
Executed in interactive phase Can be executed in both interactive
and save sequence.
Only for create and update For create,update and delete

72
Steps to develop augmentation:

4. Add augmentation in standard operation in bdef projection.

5. Implement the logic for augmentation in abap behaviour pool.

73
Requirement: If the user doesn’t provides value for field “name”, Then it should be
assigned with an default value “test”, in modify request.

To achieve this, we have added a augmentation in the update operation. Before

executing the update method, the entry will beassigned with default value in
augmentation method. In the Augmentation method, If the name is empty, we fill
default value name using modify augmentation eml.

74
Entities importing parameter.

Reference table for augmenting.

75
 RAP: Determination

Determination:

 used to determine the value of certain entity based on the trigger condition.

Note:
 The execution order of determinations is not fixed. If there is more than
one determination triggered by the same condition, the execution order
is arbitrary.
 Once a determination has been triggered, it must run independently
from other determinations.
 In unmanaged scenarios, determinations are only supported for
draft instances, not for active instances.
 For determinations defined as on save, update works only in
combination with the trigger operation create.

Trigger conditions:

 Create
 Update
 Deletee
 Field modification

Good practices:

 Don't change the field that is being triggered, as it could cause an infinite
loop. The trigger field and the calculation field should always be different.
For example, if you use 'field1' as the trigger field and then update the
same field within the method, it will trigger the method again, resulting
in an endless loop.
 The trigger conditions can contain only fields of that entity. It
cannot contain fields of child / parent entity.
 It is recommended to use either a trigger condition as a standard
operation or a field to avoid multiple calls. For example, if you have a
trigger condition set to 'update' and 'field1,' every time you update the
field, it will trigger the determination twice because you have two trigger
conditions.

76
Differnce between determination on modify and on save:

On modify On save
Executed just after the Executed before persisting on table.
modification of transactional
buffer.
Triggered before save and on save Triggered only at save
as well.
Executed in interactive phase Executed in save sequence.

Flow of determination:

Determination on modify - Interative phase

Determination on save - Save sequence

77
Determination on save and finalize:

 Determination on save is triggerd only on managed scenerio.

 In unmanged scenerio, finalize method will be triggered, instead
of determination on save method

Steps to develop determination:

1. Add determination in bdef interface with trigger condition.

2. Implement the logic for determnation in abap behaviour pool.

78
Requirement: If the user provides name as “Test1”, Then the country should be
“IN”.

To achieve this, we have declared the determination on modify with the

field name. Since the determination is triggered after the changes are
moved to the transactional buffer, we can use the 'read EML' to read the
data based on the key’s importing parameter. If the name is 'Test1,' we
modify the country to 'IN' using the 'modify EML' in the transactional buffer.

79
 RAP: Validation

Validation:

 It’s a part of controlled luw to check the consistency of data.

 Its used to validate the entry provided by the user.
 Validation occurs during the save sequence, which means it takes place
after the data has been persisted in the transactional buffer. We validate
the data by reading it from the transactional buffer. If you want to perform
validation before persisting the data into the transactional buffer, use
PreCheck.
 Since its always executed on save sequence, we cannot define validation on
modify, only on save is alowed.

Trigger conditions:

 Create
 Update
 Deletee
 Field modification

Validation vs precheck:

80
Flow of validation:

Validation is executed in early save sequence, just before the point of no

return. Since it occurs before this critical stage, any validation failures can be
reported back to the user, allowing them to fix the issues and resubmit.

Note: Validation logic for unmanaged scenarios should be written inside the
check_before_save method, while for managed scenarios, it should be
implemented in the validation method.

81
Steps to develop validation:

1. Declare validation in bdef interface.

2. Implement the logic in abap behaviour pool.

Detailed explanation with example:

Requirement: The user should not provide a country code longer than 2 characters.
If they do, a warning message should be
displayed.

To achieve this, we have declared the validation with create as the trigger condition.

In validation importing paramter is key because we are checking data from

transactional buffer. To read from tx buffer. Use read eml staement and fetch the

82
country. Now check the length and if the length is greater than 2 populate error
message in reported derived type.

83
 RAP: Feature control

Roadmap to learning feature control:

Feature control:

As the name suggests, you are controlling the features displayed in the UI, such as
fields and buttons.

1. Static feature control:

Throughout the application the property you set for a ui element remains
same, for example: key should be always read-only, or some field is
mandatory.

 Mandatory (create,update,execute): its used to make the fields

mandatory for the particular operation, execute is to make any imp,exp
paramter mandatory(abstract entity).
 Readonly(create,update): used to make fields readonly, usually used for
key fields or fields updated using determination.
 Supress(field): used to remove the field from bdef, means you cannot
consume it in abap behaviour pool, odata api, odata – ui.

84
 2. Dynamic feature control:

The properties of a UI element are determined based on certain logic,

which is written inside the ABAP behavior pool.

Steps for dynamic feature control:

1. Define the feature control for the operation required in bdef interface.

2. Write the logic inside the abap behavior pool.

Dynamic feature control is of 2 types: instance and global:

I. Instance feature control:

The feature of the ui element is determined based on the bo that user has
selected.

Instance feature control is applicable for:

1. create is not possible as there is no active instance for create
2. update
3. delete
4. internal *operation*
5. _association {create;}

85
 Detailed explanation with example:

Requirement: If the country of the selected bo is “In”, then disable the action
button.

Instance authorization has two importing parameters: the requested feature

and the key of the selected BO. The requested feature indicates which
feature is being requested, as we write logic for all instance feature controls
within a single method. Therefore, we need to know which feature is being
requested. The changing parameters result, failed, and reported. result is
where you set the feature value for the UI property. Here I have set value as
false if country “In”.

II. Global feature control

When the feature of a UI element remains the same throughout the entire BO,
you can use a global feature. This is useful when you need to control UI
elements based on timing or user context.

Detailed explanation with example:

Requirement: If the country of the selected bo is “In”, then disable the action
button.

86
For global authorization, the requested feature is the only input parameter,
while result and reported are changing output parameters.
In this example, I checked if the date is the 15th; if so, the "Create" button is
disabled.

87
 RAP: Side effects

Before knowing what is side effect, we should know the problem statement.

Why do we need side effect?

 When you click on save 2 calls happen first post call, then get call. So every
change you make will update in the db and reflect in ui.
 But,in a draft scenario, any changes made at runtime on draft instance are
reflected in the draft table. However, these changes are not reflected in the
UI, as no GET call is triggered.
 The only way to reflect the changes in ui, is to refresh the page. Because
once you render the ui. There will be a get call happening.

Why there is no get call, when we update the field in draft instance?

 Because odata is stateless, it doesn’t store session data, so the frame work
doesn’t know whether you have changed or not. Only when you are
persisting the data in active table, the get call happens.

Example:

 I have declared a determination on modify, To modify the country as “IN” if

user updates name as “Test_in”.

 Now lets jump to the example. Here initially the bo has name as “Test_GE”
and country “GE”.

 Now,If I click on edit button, there is draft instance created and data is
copied to draft table from active instace.(refer my draft blog to understand
how edit action works)

88
  I will change the name to “Test_in” and tap enter. This will trigger a merge
call for determination. Since I have not clicked save button, neither it will
trigger save sequence or persist to active db. But the changes will be
available in draft table.

 But since ther is no get call happened, the ui is not aware of the backend
change and still shows country as GE, whereas in draft table its changed to
IN.

Solution:

 Side effect: now what side effect does, every time any change happen it
reloads only that particular field and triggers get call for that particular field.
So that the data in ui is consistent.
 Side effects can be used with multiple combinations like action,
determination, determine action. I will take determination to explain with
an example.
 Not only reload of fields, we can reload permission,message etc.
 Syntax: mention the trigger and target: Here name1 is trigger and land1 is
target ex: side effects {field Name1 affects field Land1;}

89
Lets resolve the issue for the same example mentioned above.

Steps to add side effect:

1. Define side effects in bdef interface, For the above example, name1 is trigger
and land1 is target.

2. To enable sied effects add “use side effects” in bdef projection.

Now for the same example, lets try changing the name and check whether the
country is updated in runtime or not.

Now if we modify the draft instance, the changes are reflected in ui as well,

90
 RAP: Facade

While practising rap we would have mostly worked on travel and booking
application where we persist the data directly in table. But in real buisness scenerio
we cannot directly persist it into an db, for ex: if you want to create purchase order,
you cannot directly build an rap application on top of ekko and persist the data into
ekko. In classical abap, we achieve it via bapi. But however if you are working on
cloud project. Its not advisable to use bapi.

Why bapi is not advisable to be used in cloud development?

 Not only bapi, any repositary object which is of standard abap version and
not c1 released. Is not advisible to be used in cloud development.

 Rap has its own LUW(RAP LUW), so providing commit statemnet on same
luw is not allowed( however this can be overcome using update fm wrapper
or bgpf ) and most of the bapis have their own commit statements.
 Rap has lot of restriction on classical abap statements like(call screen,call
dialog), which are used in most of the bapi.

91
How do we achieve buisness operation in public cloud.

 In case of side by side extension, where you are developing fiori

application in btp you can use the released api for buisness operations.
 In case of on stack extension,where you are developing the code directly on
your core(ex: s/4 hana public cloud) you can use use c1 released cds view,
bdef for buisness operation.
 Sap api hub link: [Link]
workshops/blob/main/rap6xx/rap610/[Link]

Now lets talk about, RAP Facades:

 As I have mentioned above for on stack extensiblity, we can use c1 release

bdef for buisness operations.
 Rap facades are nothing but c1 releases bdef interface.

Refernce for rap facade:

[Link]
documentation-about-rap-facades/qaq-p/12637090

[Link]
workshops/blob/main/rap6xx/rap610/[Link]

92
To understand better lets look at the example:

Requirement: To create sales order and item.

1. To cretae sales order I have chosen “I_SALESORDERTP” bdef interface.

[Link]

2. Use modify entities to trigger the interctive phase workflow so that data is
moved to tx buffer.

3. Use commit entities to trigger the save sequence and persisting data from tx
buffer to db. Also provide final key statement for late numbering.

93
Code:

94
Output:

95
 RAP: Background processing framework ( BGPF )

To understand about bgpf, lets take a problem statement:

 you are an end user and you are supposed to create a sales order with
sales order items. Now, let's say you create a sales order with 100 sales
order items. It takes a lot of time to create a sales order with this many
line items. You will be stuck on a loading page until the operation is
completed.

Solution:

 Now, with the help of BGPF, you can run sessions asynchronously. This
means you can create a sales order in the background and still proceed
with creating another sales order while the previous one is processing.
You no longer have to wait on a loading screen. This is especially helpful
in scenarios involving large-scale processing.

Note: BGPF doesn’t make your processing faster, rather run it on background. So
that you can continue with other session.

Types of bgpf:

 Controlled bgpf: we know that rap works on controlled luw(*). To

maintain transactional consistency we use controlled bgpf. So that we can
write logic based on interactive and save sequence logic.
 Uncontrolled bgpf: we directly write logic in a single transaction.

* controlled luw: is a key reason why classical ABAP is shifting toward RAP. In
classical ABAP, developers are responsible for ensuring data consistency manually.
In RAP, changes are made to the transactional buffer during the interactive phase,
and only consistent data is saved during the save sequence.

96
Working of Bgpf:

There are mainly 2 classes required for bgpf:operation class and starter class:

Starter class Opertion class

 Starter class(in our case local saver class): does the operation and handover
to the bgpf.
 Operation class: holds the logic to be executed asynchronouly in background.

 Bgpf is wrapper of Bgrfc

97
Workflow of bgpf:

1. We first create an instance of bgpf inside starter class( lsc ),

using: cl_bgmc_process_factory=>get_default( ), for
transactional bgpf cl_bgmc_process_factory=>get_for_queue,
For queued bgpf.
2. Save the process for background processing in a separate abap session.
using lo_process->save_for_execution( ).
3. After the first session is executed and commit work is triggered.
4. New session will start for bgpf and bgrfc is called . Inturn bgrfc calls
if_bgmc_op_single~execute of operation class. To switch save sequence,
we can use cl_abap_tx=>save( ).

Requirement: To Maintain a log book of when the buisness object is created.

Even though this is not a large processing . I am using this as an example to show
working of bgpf. We can have normal creation of bo in 1 session and log it on a
table seperately inside another asynchronous session.

98
Steps:

1. Our local saver class acts as the starter class. We use

cl_bgmc_process_factory=>get_default( ) to create an instance of BGPF.
Then, pass the data from the transactional buffer to the constructor of the
operation class. Inside a try-catch block, create a BGPF process to run
asynchronously. Declare what process to be carried asynchronously, we pass
instance of operation class and save the process for background execution

2. After, the save sequence is executer Rap luw commit will happen. Then
your data will be persisted to persistence table. After which 2nd session will
run in background.

99
 ->1 st and 2 nd session

3. After commit work. if_bgmc_op_single~execute will be triggered. Inside

operation class, I have used constructor to get the data from transactional
buffer and used cl_abap_tx=>save( ) to switch to save sequence and append
the log into custom table.

How to monitor bgpf:

1. Go to abap cross trace, and create cross trace for background process:

100
2. After completion of bgpf, you can deactivate andcheck in results [Link]
would see both the sessions

101
 RAP: Business event

Rap business event:

A business event is used for communication between applications, enabling

asynchronous communication between an event provider and an event
consumer.

For example, suppose there are two applications—one for managing shipping
and another for handling billing. If there is a requirement that a bill should be
generated as soon as a product is shipped, both applications need to
communicate with each other. This communication can be achieved using a
business event.

Detailed example with steps:

In this example, I’ve taken a requirement where every time a Business

Partner is updated, a new Business Partner should be created. Since I don’t
have two separate applications, I have implemented the event handling
within the same application. However, you can write the logic in the event
handler class to trigger actions or modify data in another application if
needed.

Steps to create event:

1. Define Event:
Define the event in the BDEF interface.

 Parameters: You can add parameters if needed (optional). Parameters

are used to send additional information to the consumer. Similar to how
parameters work in action
 Side Effects: You can also add side effects in cases where you need to
reload the target (in this example, the target is "Country"). The side
effect will be triggered every time the createBpSideeffect event is raised.

102
2. Raise event:
Event is raised in save sequence, so provide inside save method. Based on my
testing,I tried placing it in a few other methods within the save sequence,
and it appeared to work. However, when I tried raising the event in a method
from the interactive phase, it raised dump. So, try providing in save method
[Link] syntax is raise entity event and the event name and pass the values
to be passed to consumer.

3. Consume Event:
Event can be consumed in 2 ways:
 Local Consumption:
In this case, the event is consumed within the same system. Events are
handled locally through an event handler class.
 Remote Consumption:
Here, the event is consumed by other systems. This is typically done via
SAP Event Mesh, which allows events to be distributed across different
systems. Since Event Mesh is not available in the BTP trial version, I will
not include detailed steps for remote consumption in this document.
Refer this blog: [Link]
by-sap/how-to-create-rap-business-events-in-sap-s-4hana-on-premise-
2022/ba-p/13553312
Note:
To check the availability, pricing, or regional support for any service
provided by SAP BTP—such as Event Mesh—you can visit the SAP
Discovery Center:
[Link]

103
To consume the event, I have created a global class, which serves as the
event handler class. The syntax FOR EVENTS OF <BDEF> is used to handle the
events declared in the specified BDEF.

Global class

The actual logic is implemented inside a local class. To make the local class an
event handler class, it should inherit from cl_abap_behaviour_event_handler.
Then, create a method corresponding to the event you want to handle from
the BDEF.

I have written a MODIFY EML statement, which triggers the interactive phase
of the same application and creates a new record based on the parameters
passed. Typically, this is where we would write logic to interact with another
application. However, since I don’t have a second application, this example is
only intended to demonstrate that the event mechanism works—not to
represent a real-world use case.

Local class

104
 Aunits for RAP

Aunits:
AUnits are unit tests written by ABAP developers to test each functionality of
their code. In RAP, AUnits are used to test functionalities such as validations,
determinations, actions, and CRUD operations etc. Your AUnits should aim
for maximum coverage of your code. It is recommended to follow TDD (Test
Driven Development), where you write the test cases first and then
implement the logic. This ensures that the test cases are based on the actual
requirements and are not influenced by the implementation.

Refernce link for TDD:

 [Link]
guide/test-driven-development-with-abap-unit
 [Link]

Basics of Aunits:
Test classes can be either local or global. Unit tests should typically be
implemented as local classes within the program object that is being tested.
However, you can use global test classes to host reusable logic for unit tests
across different programs. In Eclipse ADT, there is a separate environment for
managing local test classes

Refer this link to learn basics: [Link]

journeys/acquire-core-abap-skills/implementing-code-tests-with-abap-
unit_b23c7a00-c2e8-406d-8969-b00db3f1fd87

Structure of test class:

105
 For Testing: The addition FOR TESTING is used to identify a test class.
These are the classes that will be executed when you run ABAP Unit
tests. I will explain further how AUnits are triggered and how to execute
them.

 Risk Level
 CRITICAL:The test changes system settings or customizing data.
 DANGEROUS:The test changes persistent data.
 HARMLESS:The test does not change system settings or persistent
data.

 Duration
 SHORT:Execution time is imperceptible, expected to take only a few
seconds.
 MEDIUM:Execution time is noticeable, around a minute.
 LONG:Execution time is very noticeable, taking more than a minute.

 Methods in Test Classes

 Helper Methods: Helper methods are ordinary methods of the test
class. They are not called by the ABAP Unit framework. You can use
helper methods to structure the code of your test methods.
For example, prepare_testdata is a helper method.
 Test Methods:Test methods are defined with the addition FOR
TESTING after the method name. Each test method represents one
test. The ABAP Unit framework performs this test by calling the
corresponding test method. Test methods must not have any
parameters. In the above example, aunit_for_cds_method is your
test method.

 Good Practices
 It’s a good practice to have a separate method for each functionality,
with no dependencies inside the method. Each method should be
treated as a single test case.
 Always include both positive and negative test cases.

106
Flow of test case:

 CLASS_SETUP
This static method is executed once before the first test of the test
[Link] this method for fixtures that are time-consuming to create
and for which you are sure the settings will not be changed by any of
the test methods.
Example: Setting up a test double in the test environment.

 SETUP
This instance method is called before each test of the test class. Use
this method for fixtures that you want to create fresh for every test
case.
Example: Creating an instance of the CUT (Class Under Test).

 TEARDOWN
This instance method is called after each test of the test [Link] it to
undo changes made in the SETUP [Link] is especially important if
SETUP modifies persistent data (such as system configuration,
customizing, or master data).
Example: Clearing test doubles so that each test starts with fresh data.

 CLASS_TEARDOWN
This static method is executed once after the last test of the test class.
Use it to clean up or destroy the test environment set up in
CLASS_SETUP, once all tests are completed.
Example: Tearing down the overall test environment.

107
How do we run test class:

To run abap units either execute abap unit test. This will trigger the test class.
If you run abap application it will not trigger test class.

Test double framework:

As I mentioned earlier, your unit tests should check only the functionality
(CUT – Code Under Test) that you have written the test case for. However, in
real-world scenarios, each component is usually interlinked and not
standalone.

What is the issue?

To explain this, let’s take an example. Suppose you are testing an instance
authorization method. This method is dependent on an authorization object.
If the AUTH-CHECK of the authorization object fails, the instance
authorization method will also fail. This means that even if your instance
authorization method is working correctly, the test could still fail due to its
dependency. Ideally, the failure of a dependency should not cause your unit
test to fail when you are testing the functionality of the CUT itself.

Examples of dependencies in RAP

 Instance and global authorizations: Dependency on authorization checks.
 SAVE / SAVE_MODIFIED methods: Dependency on function modules or
BAPIs.
 Determinations: You might use EML of another BO, making your BO
dependent.
 Validations: Your CDS view could be a dependency; if the required record is
not present in the CDS view, the validation might fail.
And there are many more such cases.

108
Solution — Test Double Framework
So, how do we overcome this? Instead of relying on dependencies that are
beyond our control, we mock or stub these dependencies. This allows us to
influence how they behave and interact during testing, thereby avoiding test
case failures due to external dependencies. This approach is implemented
using the Test Double Framework.

The main purpose of both mock and stub is to not to test from actual data
but rather a fake data that we can configure. Because our test class will fail if
its dependent on real time data as it will be different in different
environment.
1. STUB: Stubs just provide predefined response.
2. MOCK: You design how the interaction should be. Like if you provide
this value this is how the output would be and also verify it.

In this documentation I will be primarily focusing on Aunits for Rap. If you

want to learn for other objects aswell refer this video:
[Link]

I will now discuss in detail how we write ABAP Unit tests with a simple example.

Requirement:
Write a positive test case to check the validation check_country, which
should throw an exception if we pass a country code with more than 2
characters. Also, remove the dependency on the CDS view.

109
Steps
Identify CUT and dependencies
Here, I have taken a validation method as an example for testing. The CUT
(Code Under Test) is the validation method, and the dependency is the CDS
view. So, I will use the STUB methodology to configure the response of the
CDS view.

Creation of test class

Once you create the test class, you need to add it as a friend in the local
handler class (since we are testing a validation). This is necessary because all
the methods of the local handler class are inside the private section and
cannot be accessed directly.

Inside the test class

I have already explained the use of SETUP, CLASS_SETUP, TEARDOWN, and
CLASS_TEARDOWN earlier, so I will not repeat that here.
In this example, validate_check_country is our test method. I have added a
test double for the CDS view, because the validation should be tested using
the mock data we provide, not the actual data.
I create the mock data and insert it, so that the CDS view returns this data.
Now, when we pass parameters to the validation, we can check if we get a
value in reported, since we have provided a country code with 3 characters.

Note: This is just an example program. Typically, mocking, adding mock data,
and different functionalities would be implemented in separate methods. It
is not a good practice to combine everything into a single method. Each
method should have only one responsibility. Here, I have combined them
solely to showcase the concept.

110
111
 Deploying rap application:

RAP applications are not directly consumed by end users from Eclipse ADT. They
are mostly consumed in the form of Fiori Launchpad (FLP) tiles.
Deploying applications in the Fiori Launchpad is a long process, so I recommend
referring to the official SAP documentation and videos for detailed steps. You can
also practice the deployment process using a BTP trial account.

Ways of Deploying RAP Applications:

1. Cloud Foundry Environment:

This is usually done by consuming the RAP application in SAP Business
Application Studio (BAS) and deploying it to Cloud Foundry as an
HTML5 application. It will then appear as a tile in the Fiori Launchpad.
Currently, SAP Build Work Zone is widely used instead of the
traditional Fiori Launchpad.
 Why move from FLP to Work Zone?
Refer to this blog to understand the differences and why many are
transitioning:
[Link]
know-the-differences-between-sap-launchpad-service-and-sap-work-
zone/ba-p/13544535
 End-to-end deployment in Cloud Foundry for FLP:
[Link]
[Link]
 Deployment in SAP Build Work Zone:
[Link]
[Link]

2. ABAP Environment:
Deployment can also be done directly in the ABAP environment:
[Link]
[Link]

112