Specifically, SAP Fiori applications are developed using the SAPUI5 Software Development Kit

(SDK), which is a responsive JavaScript framework that includes a rich set of UI controls. SAP
Fiori apps run in the SAP Fiori launchpad in the browser, and it’s no longer necessary.

The connection between the ABAP backend and the SAP Fiori apps running in the browser is
established using the SAP Gateway and the OData protocol.

Moreover, the ABAP RESTful programming model is not only targeted at S/4HANA on-premise
applications, which is the main focus of the book, but also for developing ABAP applications on
the SAP Cloud Platform to extend the S/4HANA Cloud Edition.

Defining data models using ABAP core data services (CDS) over exposing them as an OData
service to creating SAP Fiori UIs using SAPUI5 and UI annotations.

If the SAP Fiori elements app types don’t suit your needs, you must develop a freestyle
application, which gives you full flexibility in terms of designing and implementing the UI of your
application

Usually SAPUI5 code is managed with the Git Source Code Management (SCM) system, which
is also well integrated into SAP Web IDE full-stack

Because SAP S/4HANA Cloud customers no longer have access to the SAP NetWeaver
backend of SAP S/4HANA, SAP is providing another platform for doing side-by-side application
development: the SAP Cloud Platform.

Currently, SAP is offering three migration scenarios to SAP S/4HANA: a system conversion,
where an already-existing SAP ERP system is converted to an SAP S/4HANA system; a new
implementation, which is the “greenfield” approach; or a landscape transformation, where
selective applications are moved to an SAP S/4HANA installation to consolidate the existing
landscape.

SAP S/4HANA is fully built on SAP’s in-memory computing platform, SAP HANA, and offers a
completely new consumer-grade user experience (UX) with SAP Fiori. SAP is, in general, trying
to eliminate redundancies and simplify the system.

The three main layers of the system, from the bottom up, are the database layer consisting of
SAP HANA, the SAP NetWeaver Application Server for ABAP (SAP NetWeaver AS for ABAP),
and the SAP Fiori frontend server (SAP Gateway). The SAP Fiori frontend server receives
incoming HTTP client requests for SAP Fiori applications running in the SAP Fiori launchpad
and the browser as well as for business data via the Open Data Protocol (OData), which uses
HTTP as the data transfer protocol..
For building SAP Fiori applications end-to-end (E2E), the ABAP RESTful programming model
has been the framework of choice since SAP S/4HANA release 1909.
Requests from the SAP Gateway layer are routed through the Service Adaptation Description
(SADL) layer, and depending whether the request is read-only or requires write access, the
request is either passed to the query runtime or the business object runtime, respectively

Enterprise Search (ESH) powers the search functionality in the SAP Fiori launchpad (also
known as SAP Fiori search)

The Analytical Engine, which is included in SAP Business Warehouse (SAP BW), evaluates and
executes analytical queries at runtime
With the introduction of SAP Gateway and its OData channel, SAP has opened the ERP system
up to external systems, clients, devices, and machines. All business entities of the system can
be made network accessible by URIs. The OData protocol provides a standardized protocol for
consuming business entities and their relationships via the RESTful paradigm based on HTTP.
While making use of the same HTTP verbs GET, PUT, POST, and DELETE as a normal
RESTful service, OData extends the standard paradigm with a set of best practices for building
and consuming RESTful application programming interfaces (APIs). For instance, OData adds
standard URL parameters for restricting the requested result set to particular properties
($select), to a certain number of entities ($top), or to entities fulfilling a certain condition ($filter).

ABAP core data services (CDS) is the core technology enabling the VDM; CDS is fully
integrated in the ABAP stack but executed in SAP HANA. Using the CDS data definition
language (DDL), you can define layered and semantically rich data views by selecting data from
the old ERP tables.

Business-oriented, SAP HANA-enabled provision of data significantly improves application

performance because business data calculation and provisioning is, in the best case,
completely pushed down to the SAP HANA database. This paradigm is called the Code-to-Data
paradigm, in contrast to the classic Data-to-Code paradigm where large data sets are
transferred to the application server and then processed in ABAP to provide the actually
required business data. The VDM increases development speed and efficiency by providing
standardized and easy business entity consumption.

To standardize the implementation of business logic in SAP S/4HANA, SAP launched the ABAP
programming model for SAP Fiori with SAP S/4HANA 1610 FPS01. Since then, SAP
recommended to use this programming model for the E2E development of SAP Fiori
applications. In the programming model, the underlying transactional Business Object
Processing Framework (BOPF) node structure is derived from annotated CDS entities, and the
business logic is implemented inside the BOPF in ABAP. The BOPF framework was initially
developed for SAP Business By Design, which was then also reused and integrated into the
SAP Fiori programming model to handle the ABAPbased business logic parts of applications.
CDS views and BOPF business logic can be exposed in a model-based manner either via an
SAP Gateway service builder project (Transaction SEGW) by simply referencing the CDS
entities to be exposed (reference data source scenario) or via an annotation in the root view of
the CDS data model (@OData.publish: true).Even SAP GUI access is required for certain
actions, for instance, to create an OData service using the Transaction SEGW or to activate an
OData service using the Transaction /IWFND/MAINT_SERVICE.

To overcome these shortcomings and to provide a cloud-ready programming model, in August

2018, SAP released the ABAP RESTful programming model for the ABAP environment (ABAP
Platform 1808). The ABAP environment has since then been part of the SAP Cloud Platform, as
a Platform-as-a-service (PaaS) offering that provides an E2E development experience for SAP
HANA-optimized OData services such as SAP Fiori applications. Since SAP S/4HANA 1909,
the ABAP RESTful programming model has also been available in on-premise installations of
SAP S/4HANA and supersedes the ABAP programming model for SAP Fiori. As in the previous
ABAP programming model for SAP Fiori, the semantically rich data model of applications is
formed by CDS views For transactional processing, business objects are derived from CDS
entities; which operations a business object supports (e.g., create, read, update, and delete
(CRUD) operations and custom actions) is defined via what’s called a behavior definition. A
behavior definition is a new ABAP repository object defined using a Behavior Definition
Language (BDL). The data model and its behavior are then exposed as a business service,
which is essentially a RESTful OData service. A business service consists of a service definition
and a service binding. A service definition is an ABAP repository object that defines which parts
of the data model are to be exposed as a business service. A service binding is an ABAP
repository object used to bind a service definition to a specific client-server communication
protocol, for instance, OData version 2. Unlike the ABAP programming model for SAP Fiori, the
new ABAP RESTful programming model has been directly integrated into the ABAP language
with new transportable development objects: behavior definition, service definition, and service
binding. This integration provides a consistent Eclipse-based E2E development experience and
enables you to use the programming model in the cloud without any additional required
frameworks and tools, only the ABAP language core.

The SAP Fiori frontend server is based on the SAP Gateway component of SAP NetWeaver
and manages the stateless communication between the user’s browser, as the client application
of the system, and the backend.
In native SAP Fiori applications, a clear separation exists between the UI and data, which
fosters the reusability of backend components, whether business logic in ABAP or CDS views.
The SAP Gateway component implements the OData protocol via its OData channel and takes
care of all protocol-specific tasks, for instance, parsing and validating requests, rendering the
response format in either JSON or XML, performing inbound and outbound conversions, and
much more. The frontend and backend server communicate with each other via a trusted
remote function call (RFC) connection.
SAP Gateway supports hub deployment as well as embedded deployment. In a hub deployment
scenario, which used to be the recommended setup for SAP S/4HANA until SAP S/4HANA
1809, SAP Gateway components are deployed in a standalone frontend system and are
decoupled from the SAP S/4HANA backend system. On the other hand, in an embedded
deployment scenario, which has been the recommended deployment option since SAP
S/4HANA 1809, both SAP Gateway and backend components reside in the same system, which
reduces the Total Cost of Ownership (TCO) as only one system is required.

The user interface (UI) layer consists of native SAP Fiori applications developed in SAPUI5,
which is a JavaScript framework that enables the development of responsive HTML5
applications according to the SAP Fiori design language. In addition to native SAP Fiori
applications, older SAP UI technologies that support HTML-like Web Dynpro or SAP GUI for
HTML are also supported in SAP S/4HANA

SAP Fiori apps are organized in catalogs, which are created in the SAP Fiori launchpad
designer and later assigned to Transaction PFCG roles.

The VDM is the foundation for all application types in SAP S/4HANA and is enhanced with the
BOPF (earlier than SAP S/4HANA 1909) or behavior definitions (since SAP S/4HANA 1909)
The technological core enabler of the VDM is the CDS technology, which consists of a DDL, a
query language, and a Data Control Language (DCL). CDS artifacts are new development
objects in the ABAP stack that use the standard transport lifecycle management system of
ABAP, although these development objects are executed in SAP HANA.

Associations are used to express relationships between different CDS views and resemble joins
but are easier to read because they don’t directly program the joins.

Data access via CDS views can be restricted by using the data control language (DCL) of CDS.
In a DCL file, authorizations are declared via standard ABAP authorization objects
BOPF only adds the business logic of the application, the underlying data model is always
derived from the VDM by making use of specific hierarchy annotations for modeling the BOPF
node structure on the CDS level.
BOPF has been aimed at stateful business applications, but a lot of effort has been put into
optimizing BOPF for stateless data processing. Classic SAP Dynpro or Web Dynpro
applications rely on an ABAP session along with application buffers that serve client requests
until the user has finished his work and stored all the data changes. SAP Fiori applications, on
the other hand, fetch data using RESTful OData services, which are stateless like the HTTP that
is used as the data transfer protocol. Statelessness is also a core property of the RESTful
paradigm and has some advantages over stateful applications:

You can also implement a stateful application scenario using stateless communication and
BOPF, but instead of storing data in an in-memory ABAP session context, data must be stored
on the database using draft tables, which are shadow tables of the original database tables.
Users can work on the draft data for several interaction steps and roundtrips, and when finished
editing the entity, the draft data can be activated and written to the actual database tables.

When a user is changing business data and jumps between the input fields on the screen, the
changes are sent to the backend immediately via an OData request that updates the draft
table(s) instead of the original database tables. Each draft update sent to the backend like this is
called a roundtrip

Transactional Application Scenarios In general, the ABAP programming model for SAP Fiori,
available since SAP S/4HANA 1610 SPS 03, supports four different transactional application
scenarios based on BOPF and CDS: New application with draft enablement New application
without draft enablement Draft enablement of existing application Read-only application with
quick actions (BOPF is only used for actions but not for CRUD operations)

shows the different building blocks of the ABAP RESTful programming model. As in the
previous programming model, a data model based on CDS views serves as the foundation. If
only read access to the database is required, the query component takes over the data retrieval
for an OData service. The transactional counterpart of a query is a business object with
additional ABAP-based behavior definition and implementation. The service definition defines
which CDS entities of the data model should be exposed as OData entities. The service binding
then binds the exposed entities to a client communication protocol, as of now OData version
2.0. The business service can then be offered as an SAP Fiori UI, by adding an SAP Fiori
elements UI or other UI clients to the service, or as a web API, for any consumer capable of
consuming an OData REST API, for instance, freestyle OpenUI5 applications.