第 26 页 / 共 465 页
1 SAP S/4HANA Architecture
interfaces (APIs). For instance, it 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 condition ($filter). One could say that it extends the
RESTful paradigm toward an SQL-like data consumption via HTTP, which, in turn,
eases direct pushdown of queries to the SAP HANA database.
1.1.3 SAP HANA
Naturally, one of the most important goals of the SAP S/4HANA architecture is to
fully exploit the in-memory capabilities of SAP HANA. To promote this, SAP has
introduced a VDM layer on top of the existing business data tables that allows
semantic consolidation of the more and more fragmented data model over the years
without losing compatibility to previous ERP versions. 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 semantically rich data views by selecting data from the old ERP
tables. Technically, CDS views will generate SAP HANA database views on activation,
pushing down calculations and semantic business entity composition and provision
to the database. Putting a harmonized semantically rich virtual view layer on top of
the old database tables abstracts away complex table structures and relationships
that have developed over time and provides a harmonized and business-oriented
view of the data. SAP HANA-enabled business-oriented provision of data signifi-
cantly improves application performance because business data calculation and pro-
visioning 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 latter par-
adigm, however, will never reach the full performance SAP HANA can reach.
As the SAP Basis technology, the VDM and CDS are the backbone of all SAP S/4HANA
application types, including transactional applications, analytical applications, exter-
nal interfaces, and enterprise search (ESH). The VDM is a reusable and stable data
foundation used for internal development at SAP, but it can also be used by partners
and customers. Partners and customers can use and develop on top of explicitly
released views. The VDM increases development speed and efficiency by providing
standardized and easy business entity consumption.
26
第 27 页 / 共 465 页
1.1 Core Architecture
1.1.4 SAP NetWeaver ABAP
Although a clear focus is set on SAP HANA exploitation, and the trend is toward a
two-tier architecture, the middle tier of the SAP S/4HANA architecture still consists of
the SAP NetWeaver Application Server ABAP (SAP NetWeaver AS for ABAP), as was the
case in previous SAP ERP releases. It contains several engines for transactional and
analytical data processing, for instance, the Analytical Engine, which is also part of
SAP Business Warehouse (SAP BW), the Business Object Processing Framework
(BOPF), and the Service Adaptation Definition Language (SADL). In the past, the
implementation of business logic in SAP ERP was very heterogeneous and frag-
mented using many different ABAP frameworks or none at all. This led to unstan-
dardized applications that were difficult to maintain and required a lot of
application-specific domain expertise. To standardize the implementation of busi-
ness logic in SAP S/4HANA, it’s recommended to use the BOPF, whereas the underly-
ing data model is derived from CDS entities, meaning the BOPF purely focuses on the
business logic. SADL is another central entity of the ABAP stack in SAP S/4HANA. This
ABAP technology enables a model-based exposure of CDS entities and their relation-
ships as OData entities, which SAP Fiori apps then consume in a stateless manner via
the OData protocol over HTTP. Transparent to the application developer, it simply
links together the different layers of the system without having to manually code
access between the different layers.
1.1.5 SAP Fiori Front-end Server Based on SAP NetWeaver Gateway
The SAP Fiori front-end 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. It hosts the SAP Fiori appli-
cations that are downloaded for client-side rendering to the user’s browser as well as
the OData services or APIs used for fetching or changing the business data to be dis-
played in the applications. In native SAP Fiori applications, there is a clear separation
between the UI and data, which fosters 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.
27
第 28 页 / 共 465 页
1 SAP S/4HANA Architecture
SAP Gateway supports hub deployment as well as embedded deployment. In a hub
deployment, which is the recommended setup for SAP S/4HANA, the SAP Gateway
components are deployed in a standalone frontend system and are decoupled from
the SAP S/4HANA backend system. This, among other things, increases security as
the external attack surface doesn’t include the backend system. On the other hand, in
an embedded deployment, SAP Gateway and backend components reside in the
same system, which reduces the Total Cost of Ownership (TCO) as only one system is
required. However, this increases the attack surface, and the upgrade cycles of fron-
tend and backend server are coupled.
1.1.6 SAPUI5
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. Apps developed with
SAPUI5 run in the browser and, as they are by nature responsive, adjust their layout
depending on the screen size or resolution of the client device on which the browser
runs. In addition to native SAP Fiori applications, older SAP UI technologies that sup-
port HTML-like Web Dynpro or SAP GUI for HTML are also supported in SAP S/4HANA
and will get the same theming as native SAP Fiori apps when running in the SAP Fiori
launchpad. For older UI technologies, the UI isn’t rendered on the client side, and there
is no decoupling between UI and business data APIs. The UI is rendered on the server
side, and because these applications were solely developed for the desktop, the classic
UIs aren’t responsive.
1.1.7 SAP Fiori Launchpad
End users access SAP S/4HANA via browsers, and the single entry point to the system
is the SAP Fiori launchpad. The home page of the SAP Fiori launchpad displays a grid
of tiles, which serve as the starting points for apps assigned to the current user. SAP
Fiori apps are organized in catalogs, which are created in the SAP Fiori launchpad
designer and later assigned to Transaction PFCG roles on the frontend server. These
roles are then in turn assigned to business users and comprise all applications the
user needs to carry out his daily business tasks. The SAP Fiori launchpad also pro-
vides an integrated search functionality in the header area based on ESH with which
the user can search over all existing and ESH-enabled business entities in the system.
28
第 29 页 / 共 465 页
1.2 Backend
1.2 Backend
In the following subsections, we’ll look at the backend components and technologies
of SAP S/4HANA in detail. First and foremost, we’ll look at the VDM of SAP S/4HANA,
which is enabled by the CDS technology fostering the Code-to-Data paradigm and
code pushdown to the SAP HANA database. The VDM is the foundation for all appli-
cation types in SAP S/4HANA and is enhanced with the BOPF for transactional appli-
cations and the Analytical Engine for analytical applications. The following
subsections provide a basic understanding of the different SAP S/4HANA application
types and which technologies and components of the architecture are involved in
developing different applications for SAP S/4HANA.
1.2.1 Virtual Data Model
On top of the classic SAP ERP tables, the VDM is a core architectural change of SAP
S/4HANA compared to previous SAP ERP releases (Figure 1.2).
R R
R
Virtual Data Model (VDM)
Sales Order Customer
Sales Order
Material
Item
SAP S/4HANA Core Tables (SAP ERP)
> 40,000 tables (technical, cryptic, unrelated)
SAP HANA Platform
Figure 1.2 The VDM Sitting on Top of the Old SAP ERP Core Tables as the Cornerstone of all
SAP S/4HANA Application Types
29
| Virtual Data Model (VDM) Sales Order Customer Sales Order Material Item |
|---|
第 30 页 / 共 465 页
1 SAP S/4HANA Architecture
The VDM abstracts complex and heterogeneously grown table structures away by
putting a simplified and business-oriented layer of CDS views on top of the old data-
base tables. The VDM provides understandable, semantically rich, and simplified
access to business data in the form of consumable business entities without consum-
ers having to understand the complex table structures and foreign key relationships
that have grown for decades in the database tables.
ABAP Core Data Services
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 man-
agement system of ABAP, although they are executed in SAP HANA.
The data definition language (DDL) can be considered an enhancement of SQL and
allows the definition of semantically rich database views selected from either data-
base tables or other CDS views. The CDS DDL has been available since ABAP 7.4 SP 2.
Relationships between views are expressed via a concept called associations. The DDL
can also contain annotations to add domain-specific metadata.
Listing 1.1 shows an oversimplified example of a CDS DDL. The view selects data from
table EKKO, which is a classic SAP ERP table containing purchasing documents and
belongs to the Materials Management-Purchasing (MM-PUR) application compo-
nent. As you can see, the syntax resembles SQL. We also have a projection part, where
we include a few fields of the underlying table, and a selection part (WHERE condition),
where we restrict the results to documents created in 2018. In the projection part, we
can hide cryptic technical database table field names and provide semantically mean-
ingful names using aliases, which is also done in the SAP S/4HANA VDM, for instance,
ebeln as PurchasingDocument.
Associations are used to express relationships between different CDS views. They
resemble joins but are easier to read because they don’t directly program the joins.
When selecting data from dependent views using path expressions, these joins will be
materialized; however, as long as this isn’t the case, associations can be treated as meta-
data, and no joins are executed between the associated views. In the last line of the
projection, we’re propagating the association from purchase documents to purchase
document items to other potential consuming views (_PurchasingDocumentItemDDL).
Aconsuming view could then collect data from documents as well as items and form a
new business entity, for instance, the expression _PurchasingDocumentItemDDL.Pur-
chasPurchasingDocumentItem would select the purchasing document item field of the
30
第 31 页 / 共 465 页
1.2 Backend
Z_PurchasingDocumentItemDDL view via the Z_PurchasingDocumentDDL view, which would
result in the transformation of the association in an actual join on purchase docu-
ments and items.
@AbapCatalog.sqlViewName: 'ZPURCHDOCDDL'
@EndUserText.label: 'Purchasing Document'
define view Z_PurchasingDocumentDDL
// (1) DB source table
as select from ekko
// (2) Association to items view
association [0..*] to Z_PurchasingDocumentItemDDL
as _PurchasingDocumentItemDDL
on $projection.PurchasingDocument = _
PurchasingDocumentItemDDL.PurchasingDocument
{
key ebeln as PurchasingDocument,
ekorg as PurchasingOrganization,
aedat as CreationDate,
@Semantics.user.createdBy: true
ernam as CreatedByUser,
// (3) Exposure of association for
// consuming views
_PurchasingDocumentItemDDL
}
// (4) Restrict documents to 2018
where
aedat between '20180101' and '20181231'
Listing 1.1 Simple Example of a DDL File on Top of the Purchasing Document Table EKKO
CDS views can be consumed via Open SQL or other CDS views; therefore, Open SQL or
CDS itself form the query languages of CDS (Listing 1.2).
SELECT * FROM z_purchasingdocumentddl INTO TABLE @DATA(lt_purch_
docs) UP TO 10 ROWS.
Listing 1.2 Open SQL Selected in ABAP to Select Data from the Purchasing Document CDS View
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. At runtime, the user’s Transaction PFCG authorization objects and their val-
31
第 32 页 / 共 465 页
1 SAP S/4HANA Architecture
ues will be collected and pushed down to the database as filter conditions. This is an
extremely important feature to promote the Code-to-Data paradigm. In the past, to
check authorizations on individual database records or instance levels, the data had
to be transferred to the application server. Then, the individual records were checked
based on the user’s assigned authorization objects’ values.
Listing 1.3 shows how this might have been done in the past. The data is selected from
the database using Open SQL and stored in the internal table lt_purch_docs. In a loop,
each entry is checked to determine whether the user has authorization to display it;
if not, the entry is deleted from the table before it’s passed to the UI for display. How-
ever, this would mean that we lose the Data-to-Code performance benefit gained
with the CDS DDL because only the data selection part is pushed down to SAP HANA,
whereas the required authorization check part is still executed in ABAP and requires
the transfer of potentially large data sets from the database to the application server
via the network.
LOOP AT lt_purch_docs ASSIGNING <fs_purch_doc>.
AUTHORITY-CHECK OBJECT 'M_BEST_EKO'
ID 'EKORG' FIELD <fs_purch_doc>-purchasingorganization
ID 'ACTIVT' FIELD '03'.
IF sy-subrc <> 0.
DELETE lt_purch_docs INDEX sy-tabix.
ENDIF.
ENDLOOP.
Listing 1.3 Classic AUTHORITY-CHECKS in ABAP after Reading Data from the Database
Using Open SQL and Stored in an Internal Table (lt_purch_docs)
Fortunately, beginning with ABAP 7.40 SP 10, CDS DCL files can be used to push down
these instance-level authorization checks to the database. Listing 1.4 shows a simple
DCL file for the Z_PurchasingDocumentDDL view. Like the preceding ABAP code snippet,
it makes use of the standard ABAP authorization object M_BEST_EKO to restrict
access to purchasing documents by purchasing organizations (Figure 1.3). The pur-
chasing organizations for which a user is authorized to see purchasing documents
are derived from the Transaction PFCG roles. The user is assigned to Transaction
PFCG roles, which, in turn, contain authorization objects that have certain authoriza-
tion field values specifically required to carry out the user’s specific business task
according to the least privilege principle. In the following DCL, we make sure that
users can only see purchasing document records with a PurchasingOrganization that
is also contained in the EKORG field of the M_BEST_EKO authorization object instance
32
第 33 页 / 共 465 页
1.2 Backend
assigned to the user via a Transaction PFCG role, for example, purchasing organiza-
tions 0001 and 0002. Additionally, we check for display authority using the acvt
field.
@EndUserText.label: 'Purchasing Document DCL'
@MappingRole: true
define role Z_PurchasingDocumentDCL {
grant select
on Z_PurchasingDocumentDDL
where
( PurchasingOrganization ) =
aspect pfcg_auth ( M_BEST_EKO, EKORG, actvt = '03' );
}
Listing 1.4 Simple DCL File Using the Standard ABAP Authorization Object M_BEST_EKKO to
Filter the Purchasing Documents by Purchasing Organization
At runtime, the executed SQL SELECT will look like the following:
SELECT * FROM Z_PURCHASINGDOCUMENTDDL WHERE PurchasingOrganization =
‘0001’ and PurchasingOrganization = ‘0002’
As you can see, the DCL authorization checks are transparently pushed down to the
database using an SQL WHERE clause.
Figure 1.3 Authorization Object for Purchasing Organizations in Purchase Orders
Virtual Data Model Architecture
To foster reuse but nevertheless provide optimally tailored CDS views for different
usage scenarios and applications, SAP has organized the standard SAP S/4HANA core
CDS views in a layered architecture. The basis of the VDM architecture form the old
33
第 34 页 / 共 465 页
1 SAP S/4HANA Architecture
SAP ERP core tables of the different application components ranged from FI to Logis-
tics (LO) to HR. Figure 1.4 shows the different layers of the VDM architecture. From the
bottom up, it consists of the interface layer, formed by basic and composite views,
and the consumption views layer, which sits on top of the interface view layer.
All types of
consumers
Purpose-built
VDM Consumption Views C_* VDM External API Views A_* for apps and APIs
Convenience
VDM Composite Interface Views I_* views for reuse
Basic VDM for
reuse
VDM Basic Interface Views I_*
Cryptic,
Application Data Tables invisible
Figure 1.4 Different Layers of the VDM Architecture
The lowest layer of CDS views on top of the database tables is called the interface view
layer. It’s the application agnostic and reusable base layer of the VDM. The interface
view layer can be further subdivided into basic and composite views. By convention,
names of CDS views of the interface view layer, basic as well as composite, start with
I_, for instance, I_Material. Distinguishing basic and composite views is done using
the @VDM.viewType: #BASIC/#COMPOSITE header annotation.
The basic view layer of CDS views is the foundation layer of the VDM itself. All upper-
layer CDS views of the VDM, composite and consumption, are supposed to construct
application-specific business entities and access data using those basic CDS views.
Direct database table access of upper-layer CDS views is a bad practice and is forbid-
den. There are a lot of rules that apply to the development of basic CDS views, but the
main aspects and characteristics are as follows:
(cid:2) Basic views usually select data from one database table to allow fine-grained reuse.
(cid:2) If the mandatory attributes of an entity are distributed over multiple tables, the
basic view might already join those together.
(cid:2) Basic views may only have associations with other basic views.
34
第 35 页 / 共 465 页
1.2 Backend
(cid:2) Basic views aren’t supposed to contain any complex calculations, aggregations,
parameters, or WHERE conditions—only a projection of the underlying database
table fields.
(cid:2) Basic views provide semantic field names to hide the technical abbreviated data-
base table field names.
(cid:2) Basic views are agnostic to their potential consumers.
(cid:2) Basic views are free of redundancies, which means that a piece of data can only be
selected using one particular core view (e.g., there is exactly one view for the work
center or cost center entity).
Due to their simplicity, basic CDS views are optimal candidates for fine-grained reuse
and composition of new, more application-specific, views and entities. They already
provide redundancy-free core business entities carrying semantic names and having
semantically labeled properties, but they are still usually based on a one-to-one rela-
tionship between the basic view and the SAP ERP table.
To compose new reusable business entities or bring together all business data
required for a certain existing business entity in one view, the composite view layer is
provided, which sits on top of the basic view layer. The further we move up the differ-
ent layers, the more application specific and business oriented the views get. The
main characteristics of composite views are as follows:
(cid:2) Composite views are based on one or more basic CDS views and may also select
data from other composite views.
(cid:2) Composite views may have associations to other composite and basic views.
(cid:2) Composite views may contain calculations, aggregations, parameters, or Where
conditions.
(cid:2) By nature, composite views introduce data redundancy; for instance, we might
need a reuse view for an analytical use case and for a transactional app that might
return the same data.
Like basic views, composite views are intended for reuse. Unlike basic views, how-
ever, they might already implement application type-specific scenarios, such as par-
ticular calculations, aggregations, annotations, or join scenarios, to provide business
entities and data to application-specific consumption views sitting on top of them.
The uppermost layer of the VDM architecture, the consumption view layer, is
intended for application-specific use cases. Unlike the interface view layers, con-
sumption views aren’t intended for reuse; instead, they address application-specific
35
第 36 页 / 共 465 页
1 SAP S/4HANA Architecture
requirements. By convention, their names start with C_, for instance, C_MaterialDai-
lyDemand. Consumption layer views are additionally annotated with the @VDM.view-
Type: #CONSUMPTION header annotation. External API views, which are used because
they are application specific and nonreusable, are also assigned to the consumption
view layer and are the basis for published OData APIs, for instance, via the SAP API
Business Hub. Their names start with A_, for instance, A_ProductionOrder. The main
characteristics of consumption layer views are as follows:
(cid:2) Consumption layer views address application-specific requirements.
(cid:2) Consumption views aren’t intended for reuse as they are developed for a specific
purpose, for instance, a certain SAP Fiori application or analytical query.
(cid:2) Consumption views are supposed to access data using interface layer views.
(cid:2) Consumption views may have associations to interface views as well as other con-
sumption views.
Consumption views might contain application-specific complex calculations, aggre-
gations, join conditions, or UI annotations, which is what renders their reuse impos-
sible across application borders.
Figure 1.5 shows a complete end-to-end example of an application VDM based on the
sales order entity, which is part of the SD application component.
I_SalesOrder I_SalesOrderItem I_Material I_MaterialText
VBAK VBKD VEDA VBAP MARA MAKT
Figure 1.5 Example of the VDM Architecture for the Sales Order Business Entity
36
etisopmoC
cisaB
selbaT
I_SalesOrderTP I_SalesOrderItemCube
noitpmusnoC
lanretxE
IPA
Selection
C_SalesOrderTP C_SalesOrderItemQuery A_SalesOrderItem
Association
第 37 页 / 共 465 页
1.2 Backend
The lowest level contains the different SAP ERP tables from which data is brought
together using several CDS view layers. The basic view layer (I_SalesOrder, I_SalesOr-
derItem, I_Material, I_MaterialText) directly performs projections on database
tables, whereas the composite view layer provides reusable application-specific views
for transactional (I_SalesOrderTP) and analytical applications (I_SalesOrderItemCube).
Finally, the consumption view layer consists of application-specific views for transac-
tional (C_SalesOrderTP), analytical (C_SalesOrderItemQuery), and external API applica-
tions (A_SalesOrderItem).
1.2.2 The Transactional Architecture (BOPF)
An integral part of the transactional architecture in SAP S/4HANA is the BOPF, which
derives its node structure from business entities of the VDM based on CDS. BOPF is
the recommended ABAP framework for developing new standardized business logic
in SAP S/4HANA. It’s important to note that whereas 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 struc-
ture on the CDS level. Generating the corresponding BOPF node structure from CDS
business entities is supported from SAP S/4HANA OP 1610 SPS 03 onward.
The general idea of the transactional architecture in SAP S/4HANA (see Figure 1.6) is
to provide direct high-performance access to CDS views for read-only scenarios using
the SADL framework, which transparently passes OData requests via SAP Gateway
down to the VDM layer using its query runtime. Modifying access is provided via the
BOPF runtime to invoke business logic. If the modifying access doesn’t invoke any
business logic at all, it can even be further optimized to directly access the database
tables. This avoids building up local buffers and caches.
The SAP Fiori UX requires a decoupling of the frontend and backend as well as a back-
end implementation optimized for stateless request handling. So far, BOPF has been
aimed at stateful business applications, but a lot of effort has been and is still being
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 advan-
tages over stateful applications:
37
第 38 页 / 共 465 页
1 SAP S/4HANA Architecture
(cid:2) Statelessness enables horizontal scaling of APIs as any request can be processed by
any server without any session-related dependencies.
(cid:2) Stateless APIs are less complex as all information required to serve the request is
contained in the current request, so no server-side state synchronization logic is
needed.
(cid:2) Reliability is also improved because if one server crashes, another server can take
over immediately as no previously stored state is required for serving requests.
(cid:2) To improve network efficiency, the responses to requests can be cached on the cli-
ent side.
Framework-based Consumption via SADL
Analytical R Transactional R
Access Access
R
Actions
SADL Query Runtime
R Determinations
BOPF (Side Effects)
Direct Optimized Runtime
transactional
read-only
access read and write R Validations
(bypassing BOPF (Checks)
buffer)
R
CDS Views BOPF Buffer and Data Access
SAP ERP Application Tables Draft Tables
Figure 1.6 Transactional Architecture of SAP S/4HANA Applications
It’s also possible to implement a stateful application scenario using stateless commu-
nication and BOPF, but instead of storing data in an in-memory ABAP session con-
text, data must be stored on the database using draft tables, which are shadow tables
38
| Actions | |
|---|---|
| Actions | Actions |
| Determinations (Side Effects) | |
|---|---|
| Determinations (Side Effects) | Determinations (Side Effects) |
| Validations (Checks) | |
|---|---|
| Validations (Checks) | Validations (Checks) |
第 39 页 / 共 465 页
1.2 Backend
of the original database tables. The user can work on the draft data for several inter-
action steps and round-trips and when finished editing the entity, the draft data can
be activated and written to the actual database tables. This information of a draft
entity that is present for a certain business entity can also be used for locking the
entity for other users (exclusive lock). In the past, locks were bound to an ABAP ses-
sion; now, durable locks can be used to enable stateless locking of an entity beyond
several ABAP sessions and requests.
Business Logic Implementation
Business logic implementation in BOPF comes in the form of actions, determina-
tions, or validations:
(cid:2) Actions
Actions implement operations, for instance, changing the status of an invoice
from Outstanding to Paid.
(cid:2) Validations
Validations don’t change any data but check whether the data is consistent, for
instance, whether price and quantity are defined for an invoice.
(cid:2) Determinations
Determinations execute side effects and are triggered on actions, for instance, if
the quantity of items in an invoice changes, the overall price has to be updated as
well.
ABAP Programing Model for SAP Fiori
The ABAP programming model for SAP Fiori, which is available since SAP S/4HANA
OP 1610 SPS 03, supports four different transactional application scenarios based on
BOPF and CDS:
(cid:2) New application with draft enablement
(cid:2) New application without draft enablement
(cid:2) Draft enablement of existing application
(cid:2) Read-only application with quick actions (BOPF is only used for actions but not for
CRUD operations)
Those different scenarios will be discussed in detail in Chapter 3.
39
第 40 页 / 共 465 页
1 SAP S/4HANA Architecture
1.2.3 Analytics
An integral part of the SAP S/4HANA UX is the seamless integration of analytical con-
tent into standard process steps or applications. Business users in SAP S/4HANA will
be supported with in-process contextual information to aid decision-making, such as
which items to process next. For users who need a more generic view on data, such as
executives or data analysts, SAP still provides generic key-user tools to flexibly ana-
lyze business data, for instance SAP Lumira, or SAP Analysis for Microsoft Excel.
Embedded analytics scenarios for business users are, to a large extent, enabled by
SAP HANA because it blurs the borders between classic online transaction processing
(OLTP) and online analytical processing (OLAP) systems.
With SAP HANA, storing column-based and in-memory data, the speed of aggregat-
ing data has increased substantially and allows real-time analytical reporting and
transactional processing in the same system. Another enabler of in-app analytics is
SAP Fiori with its rich set of analytical controls and templates aimed at analytical use-
cases, for instance, Overview Page (OVP) or Analytical List Page (ALP).
As for other application types, the foundation of all analytical content in SAP S/4HANA
is the VDM based on CDS views. Analytical CDS content can be consumed either via
the OData protocol and the SADL engine or the Info Access Service (InA), Business
Intelligence Consumer Services (BICS), and OData protocols and the Analytical Engine
(see Figure 1.7).
Both engines use analytical CDS annotations, for instance, to determine on which
fields to aggregate the data. The @DefaultAggregation: #SUM annotation will mark a
CDS view field as a measure on which data will be aggregated as a sum. All other fields
in the view will be dimensions by default and form the context of the aggregation, for
instance, number of maintenance requests (measure) by machine type (dimension).
For simple analytical use cases, the SADL engine can be used, whereas for more com-
plex scenarios, such as hierarchy handling or exception aggregations, the Analytical
Engine must be used.
The Analytical Engine is part of SAP_BW in the ABAP server and will, like the SADL
engine, use SQL SELECT statements on the CDS views to retrieve the data. No applica-
tion-specific ABAP code is executed at runtime, and the selection of data and the
authorization checks are completely pushed down to the SAP HANA database.
40
第 41 页 / 共 465 页
1.3 User Experience
BI Clients
Analytical List Smart Business
Object Page (SAP Lumira, SAP
Page KPI
Analysis for Office, …)
Overview Smart Multidimensional
Freestyle App
Page Report
Third-Party Clients
SAP Fiori Shell
Browser Analytical Clients
R
OData R InA/BICS R
R
SAP Gateway/SADL Analytical Engine
R
R Query (CDS View)
Analytic
R Metadata
(KPI, Report,
UI)
Virtual Data Model (VDM)
SAP NetWeaver Application
Server for ABAP
R
SQL View
Standard SAP ERP application tables
SAP HANA DB
Figure 1.7 Analytical Parts of the SAP S/4HANA Architecture
1.3 User Experience
One main objective of SAP S/4HANA is also an improved UX and the transition from
traditional business software UX to consumer-grade UX. The main pillar of the tran-
sition is the newly developed SAP Fiori design paradigm.
41
第 42 页 / 共 465 页
1 SAP S/4HANA Architecture
1.3.1 SAP Fiori
The UX of SAP S/4HANA is fully based on the SAP Fiori design language, which aims
to provide lightweight role-based apps tailored to the users’ specific tasks. Therefore,
the UI of SAP S/4HANA is mostly based on web apps developed with the SAPUI5
framework, as SAPUI5 is one of the supported technologies for implementing the SAP
Fiori UX. SAPUI5 is a JavaScript framework that comes with built-in support for archi-
tectural concepts such as the Model View Controller (MVC) pattern, two-way data
binding, and routing. Apps developed with SAPUI5 run in the browser of smart-
phones, tablets, and desktop PCs and will adapt according to the devices’ capabilities.
1.3.2 SAP Fiori Launchpad
SAP Fiori apps within SAP S/4HANA are hosted by the SAP Fiori launchpad, which
provides the apps with different services, for instance, inter-app navigation, person-
alization, and application configuration. It’s the single-entry point to SAP S/4HANA
for end users on any device and provides the user with role-based access to all apps
relevant for carrying out his specific business tasks.
1.4 SAP S/4HANA Editions
The SAP S/4HANA product offering currently consists of two different editions: SAP
S/4HANA, which is the on-premise edition, and SAP S/4HANA Cloud. In the following,
we’ll explore the different architectures, deployment options, and release strategies
of both SAP S/4HANA editions.
1.4.1 On-Premise Architecture
The scope of SAP S/4HANA, in terms of functionality, localization, and content, can
be considered equivalent to previous SAP Business Suite releases. Additionally, it
provides customers with great flexibility concerning their system usage. Customers
still have full access to well-known administration tools (e.g., Transaction PFCG for
role and authorization management), and, as with previous SAP ERP versions, it’s
possible to tailor predelivered SAP content and applications to specific customer
needs. Moreover, when choosing SAP S/4HANA, customers can fully leverage the
underlying SAP NetWeaver platform and SAP HANA database to develop custom SAP
42
第 43 页 / 共 465 页
1.4 SAP S/4HANA Editions
Fiori apps along with the predelivered SAP Fiori apps. This includes full access to the
ABAP stack through ABAP in Eclipse, also known as ABAP development tools. One
major change compared to previous SAP ERP versions is that customers no longer
have the choice of selecting one of the supported database vendors. SAP S/4HANA
depends on, and is exclusively built for, the SAP HANA database.
Customers can install SAP S/4HANA in their own data centers and have complete
control over the software and their data. They are responsible for the whole lifecycle
management of the system, including upgrades and applying corrections via SAP
Notes. Using this deployment option, customers have maximal flexibility when it
comes to tailoring and customizing applications to their needs as well as doing cus-
tom development on the SAP NetWeaver platform. Customers pay a license fee for
being granted the right to use the software, which usually involves a high up-front
investment.
1.4.2 Cloud Architecture
Compared to SAP S/4HANA, SAP S/4HANA Cloud is somewhat more restricted and
standardized. SAP delivers ready-to-use content and specialized key-user tools to
allow customizations and adjustments, but no access to the SAP NetWeaver backend
is provided anymore. This prevents incompatible changes and modifications by cus-
tomers and ensures seamless quarterly upgrades of the system. All access to the sys-
tem is browser based via the SAP Fiori launchpad, which is a shell that hosts all SAP
Fiori apps, key-user applications for customizing the system, and end-user applica-
tions. The SAP Fiori launchpad is the single entry point to the SAP S/4HANA Cloud
system. If end-user applications support it, they can, to a certain extent, be custom-
ized and extended using key-user tools. This is called in-app extensibility because the
extensions are done in the same system as the enhanced application. If, in addition
to the SAP-delivered applications, custom applications are required, they must be
developed and deployed in a side-by-side extensibility scenario using SAP Cloud Plat-
form. Access to the SAP NetWeaver AS for ABAP via ABAP development tools in
Eclipse isn’t supported anymore.
In the cloud, customers have two possibilities to subscribe to SAP S/4HANA Cloud:
public cloud service or private cloud. Figure 1.8 shows a high-level overview of the dif-
ferent SAP S/4HANA editions, including on-premise.
43
第 44 页 / 共 465 页
1 SAP S/4HANA Architecture
SAP S/4HANA
Public Cloud
Customer Customer
SAP S/4HANA On-Premise
A Tenant B Tenant
Customer
On-Premise
SAP
S/4HANA
System
SAP S/4HANA
Private Cloud
Customer Customer
A SAP B SAP
S/4HANA S/4HANA
System System
Figure 1.8 High-Level Overview of the Different SAP S/4HANA Deployment Options
Public Cloud
In this case, SAP S/4HANA Cloud is provided as Software as a Service (SaaS) by SAP
and runs in a multitenant public cloud environment in SAP data centers. From a
cloud service provider view, it’s important to use the available computing and infra-
structure resources as efficiently as possible to reduce the TCO for providing the ser-
vice.
This is best achieved by making the subscribers share as many resources as possible
but keeping them isolated from other subscribers in their own “tenant.” From a sub-
scriber perspective, it’s important to be isolated from other subscribers of the cloud
service and keep data private. Customers subscribe to the service and continuously
pay a subscription fee for using the service. Key users and end users of customers
access the system via the browser. The lifecycle management of the system lies com-
pletely with SAP. SAP does the system upgrades and applies patches and hotfixes.
44
第 45 页 / 共 465 页
1.4 SAP S/4HANA Editions
Private Cloud
In this deployment scenario, SAP S/4HANA Cloud is deployed in a private cloud envi-
ronment managed by SAP in SAP data centers. Subscribing to a private cloud service
implies a higher degree of isolation from other subscribers; that is, instead of each
customer having its own tenant within a shared system, each customer gets its own
system. How far the responsibilities of subscriber and provider go in terms of lifecy-
cle management of the system depends on individual contractual agreements. This
can range from “hosting” scenarios, where the subscriber takes over the whole
responsibility of the lifecycle management of the system, and the provider only pro-
vides the system and infrastructure, to fully managed scenarios, where the provider
carries out all upgrade and maintenance activities. This private managed cloud sce-
narios can at the moment be realized with the SAP HANA Enterprise Cloud.
1.4.3 Release Strategies
Both SAP S/4HANA and SAP S/4HANA Cloud are supplied with quarterly updates.
However, only SAP S/4HANA Cloud provides continuous access to the latest innova-
tions provided by SAP as it’s continuously supplied with quarterly Innovation
Releases.
For the SAP S/4HANA, on the other hand, SAP is providing one key release per year,
which, for the next three quarters, is supplied with Feature Packs (FPs) that deliver
nondisruptive innovations as well as software corrections and legal changes. After
the third FP, the SAP S/4HANA release goes into maintenance-only mode and a new
SAP S/4HANA version is released.
In maintenance mode, Support Packages (SPs) provide a bundle of software correc-
tions and may include legal changes for SAP S/4HANA releases on a quarterly basis.
An SP might also contain round-offs of existing functionality, for instance, enhance-
ments contracted in SAP Customer Connection programs, but no completely new
functionality or innovations.
Technically, FPs and SPs are shipped as Feature Package Stacks (FPS) and Support
Package Stacks (SPS), which are bundled sets of features or support packages that
must be applied in the given combination.
Figure 1.9 summarizes the different release strategies of the SAP S/4HANA and SAP
S/4HANA Cloud.
45
第 46 页 / 共 465 页
1 SAP S/4HANA Architecture
Innovation Innovation Innovation Innovation Innovation
SAP S/4HANA Release 1802 Release 1805 Release 1808 Release 1811 Release …
Cloud Edition
Q4 Q1 Q2 Q3 Q4 Q1
1709 FPS01 FPS02 FPS03 SPS04 …
SAP S/4HANA Feature Feature Feature Support
On-Premise Pack Pack Pack Package
Edition
1809 FPS01
New release including Feature Pack
Q1-Q4 Cloud Innovations
Figure 1.9 Different Release Strategies of SAP S/4HANA and SAP S/4HANA Cloud
1.5 SAP Cloud Platform
The SAP Cloud Platform plays an important role in extending SAP S/4HANA and SAP
S/4HANA Cloud with state-of-the-art cloud services and applications (Figure 1.10). SAP
Cloud Platform is SAP’s Platform-as-a-Service (PaaS) offering for developing cloud
native applications in Neo (SAP’s own environment), Cloud Foundry, and Kubernetes.
Additionally, it hosts many of the innovative SAP Leonardo services and applications
in areas such as machine learning and Internet of Things (IoT). As customers subscrib-
ing to the SAP S/4HANA Cloud service don’t get access to the SAP NetWeaver AS for
ABAP stack anymore using Eclipse, they must develop custom applications on SAP
Cloud Platform in a side-by-side extensibility scenario. SAP S/4HANA customers, on
the other hand, still have the choice of whether they develop their custom applications
in SAP NetWeaver or switch to SAP Cloud Platform, which might facilitate a migration
to SAP S/4HANA Cloud at a later point because custom code is already ported to a cloud
native platform environment and moved out of the core SAP ERP. SAP Cloud Platform
supports a wide range of programing languages via containerized runtimes, for
instance, Java, Node.js, ABAP, and HTML5. Additionally, SAP Cloud Platform provides a
large set of backing services ranging from data and storage services (SAP HANA, Redis
on SAP Cloud Platform, PostgreSQL) to SAP Cloud Platform DevOps (SAP Web IDE) over
46