Authors:

Stefan Elfner
Andreas Kemmler
Katherina Bick
Baré Said
Peter Eberlein
Christoph Luettge Overarching
Axel Herbst
Tobias Stein
Felix Wente
Gregor Tielsch
Christian Conradi
Markus Goebel
Architecture Conceptual
Christoph Birkenhauer
Andreas Huppert
Thomas Nitschke
Heiko Steffen
Document
Philipp Steves
Andreas Poth for
Volker Wiechers
Christoph Mecke
Jens Freund
Ralf Krenzke
Peter Dejon
Manfred Hirsch
Winfried Schleier
Nicolai Jordt
Ralf Kau
Bernhard Drabant Cloud (CL)
Torsten Kamenz
Carsten Ziegler
Holger Bohle
On Premise (OP)
Peter Dell
Martin Schmid Version 1805
Renzo Colle
Carsten Pluder
Danny von Mitschke-C.
Martin Mayer
Stephan Toebben
Jochen Boeder INTERNAL
Peter Enrico Vittoria
Architecture Guideline S/4HANA

Contents
0 Introduction and launch of our new product S/4HANA .................... 9
0.1 Evolution of Strategy ....................................................................................... 9
0.1.1 Public Cloud (PC)  S/4HANA PC .......................................................................... 9
0.1.2 Managed Cloud (MC)  S/4HANA MC ................................................................... 9
0.1.3 One Cloud (CL)  S/4HANA CL .............................................................................. 9
0.1.4 On Premise (OP)  S/4HANA OP ........................................................................... 9
0.2 Consequences to this guideline ..................................................................... 10
1 About This Guideline ......................................................................... 11
1.1 Statement of Directive for S/4HANA .............................................................. 11
1.1.1 Semantic Compatibility ........................................................................................... 11
1.1.2 Feature Completeness ........................................................................................... 11
1.2 Scope of the Architecture Guideline for S/4HANA ......................................... 12
1.3 Rules and their meanings .............................................................................. 12
1.4 Deviation process .......................................................................................... 13
1.4.1 Deviations ............................................................................................................... 13
1.4.2 Roles and Responsibilities ...................................................................................... 14
1.5 Contact Persons............................................................................................ 14
2 Principle of ONE – The Key Driver for Simplification ..................... 15
2.1 Elimination of Redundancy ............................................................................ 15
2.2 Zero Redundancy in Frameworks.................................................................. 15
2.3 Zero Redundancy in Application Data ........................................................... 15
3 S/4HANA Deployments and its Scope .............................................. 17
3.1 Deployment options of S/4HANA................................................................... 17
3.2 Core, Staging and Deprecated Scope ........................................................... 17
3.2.1 Optional Scope ....................................................................................................... 18
3.2.2 Onboarding and provisioning of formerly deleted Software Components .............. 18
3.2.3 Rules for availability of Scope................................................................................. 18
3.3 Managing Release Scope and Functional Scope by Switching Code ............ 19
3.3.1 Customizing ............................................................................................................ 19
3.3.2 Handling Business Functions ................................................................................. 19
3.3.3 Feature Toggles ...................................................................................................... 20
3.4 Shipments of S/4HANA ................................................................................. 21
3.5 Software Component Stack of S/4HANA ....................................................... 21
3.5.1 Categories of the S/4HANA Stack (valid for Figure 3-2, 3-3 and 3-4) .................... 21
3.5.2 Software Component Merge and relabeling to S4CORE and SAPSCORE ........... 22
3.5.3 Reasons for Software Component Merge .............................................................. 23
3.5.3.1 Elimination of Interfaces, Extensions or BAdIs ................................................ 24
3.5.3.2 Simplification of Quarantine Process ............................................................... 24
3.5.3.3 No different deployment options / combinations.............................................. 24
3.5.4 Comparison of INFINITY and sINFINITY Codeline ................................................ 24

© Copyright SAP SE 2017 Internal/Confidential Page 2 of 100

Architecture Guideline S/4HANA

3.6 Most recent Stack Definitions and dependencies for S/4HANA ..................... 24
3.7 Activities to be done right after the software component merge ..................... 25
3.7.1 Pending Database field extension .......................................................................... 25
3.7.2 Elimination of Client-Dependency or Client-Independency .................................... 25
3.7.3 Include Split of ABAP Includes to optimize automated tests .................................. 25
3.7.4 Change of Master Language for all components to English ................................... 25
3.7.5 Handling of Business Functions ............................................................................. 26
3.7.6 Convert Pool Tables / Cluster Tables ..................................................................... 26
3.7.7 Eliminate Match Code Tables ................................................................................. 26
3.7.8 Adjust Date-Dependent Tables............................................................................... 26
3.8 Deprecation Process ..................................................................................... 27
3.9 Target Architecture for S/4HANA Applications............................................... 27
4 User Experience and UI Development .............................................. 29
4.1 Basic Principles and Goals ............................................................................ 29
4.2 UI Technologies for S/4HANA ....................................................................... 29
4.3 Automatic Processing of UIs (Batch Input) .................................................... 29
4.4 Test Automation ............................................................................................ 30
4.5 Semantic Compatibility and Fiori Apps .......................................................... 30
4.6 Transactional FIORI Apps ............................................................................. 31
4.7 Cross Release Interoperability for S/4HANA ................................................. 32
5 Application Development .................................................................. 33
5.1 Usage of HANA Content ............................................................................... 33
5.2 Activation of Optional Scope ......................................................................... 33
5.3 Ensuring Multi Tenancy Capabilities .............................................................. 33
5.3.1 The ABAP Cloud Platform and S/4HANA Cloud Multitenancy Concept ................ 37
5.4 Ensuring S/4HANA Cloud Environment ......................................................... 39
5.5 Changes in Data Models ............................................................................... 40
5.6 Changes in User Interfaces ........................................................................... 41
5.7 Deleting Repository Objects .......................................................................... 42
5.8 Tables classification, delivery class and buffering ......................................... 43
5.9 Ensuring Testability of S/4HANA ................................................................... 43
5.10 Configuration for Applications ........................................................................ 44
5.11 Security for Applications provided in the Cloud.............................................. 44
5.12 Central System Settings ................................................................................ 44
5.12.1 Time Zone ............................................................................................................... 44
5.12.2 SET UPDATE TASK LOCAL .................................................................................. 44
5.12.3 Differentiation between Deployment Options ......................................................... 45
5.12.4 Deleting exceeded log entries from SBAL .............................................................. 46
5.13 Optimistic Concurrency Control ..................................................................... 46
5.14 ABAP Domain Conversion Routines ............................................................. 47
5.15 Database Table Layout ................................................................................. 48
5.16 Generating of Development Objects / Source Code Generators.................... 48
5.17 Object Types and Unique IDs ........................................................................ 49

© Copyright SAP SE 2017 Internal/Confidential Page 3 of 100

Architecture Guideline S/4HANA

5.18 Forbidden and Unwanted Statements ........................................................... 50

5.18.1 Forbidden Statements ............................................................................................ 50
5.18.2 Unwanted Statements ............................................................................................ 50
6 Performance ....................................................................................... 52
6.1 E2E User Response Time ............................................................................. 52
6.2 Resource Consumption ................................................................................. 53
6.2.1 Stateless Programming Model and Draft Infrastructure ......................................... 53
6.2.2 Usage of CDS Views. ............................................................................................. 53
7 Cross System Integration into other applications (Volker Wiechers)56
7.1 General Rules for Cloud ................................................................................ 56
7.2 General Rules for On Premise ...................................................................... 57
8 Extensibility (Tobias Stein, Felix Wente).......................................... 58
8.1 Basic Principles and Goals ............................................................................ 58
8.2 High-Level Extensibility Tool Architecture ...................................................... 59
8.3 Application Enabling for Extensibility ............................................................. 60
8.4 Customer Code Options for the Different Deployments ................................. 63
9 Elimination of outdated technologies S/4HANA .............................. 64
10 Analytics ............................................................................................. 64
10.1 General Architecture ..................................................................................... 64
10.2 General Guidelines........................................................................................ 66
10.3 Current Restrictions....................................................................................... 67
10.4 Further Details............................................................................................... 67
11 Output Management (Christoph Birkenhauer) ................................ 67
11.1 Different aspects of Output Management ...................................................... 67
11.1.1 Print forms............................................................................................................... 67
11.1.2 Printing .................................................................................................................... 67
11.1.3 E-Mail output ........................................................................................................... 68
11.1.4 Output control ......................................................................................................... 68
11.2 Simple List Output ......................................................................................... 68
11.3 General Rules ............................................................................................... 68
11.4 Rules for Print Forms .................................................................................... 68
11.5 Rules for Output Control ................................................................................ 69
12 Information Lifecycle Management (Axel Herbst) ........................... 70
12.1 Data Archiving versus Data Aging ................................................................. 70
12.2 Retention Management ................................................................................. 71
13 Data Protection (Carsten Pluder) ...................................................... 72
13.1 Recognize Personal Data .............................................................................. 73
13.2 Purposes of the Processing........................................................................... 73
13.3 Simplified Blocking and Deletion of Personal Data ........................................ 73
13.4 End of Purpose (EoP) Adaption for Business Partner consuming Applications75
13.5 Read Access Logging ................................................................................... 77
13.6 Masking......................................................................................................... 77

© Copyright SAP SE 2017 Internal/Confidential Page 4 of 100

Architecture Guideline S/4HANA

13.7 Information .................................................................................................... 77

13.8 Consent......................................................................................................... 77
13.9 Notification .................................................................................................... 77
14 Identity and Access Management (Johann Kemmer) ..................... 78
14.1 User Management ......................................................................................... 78
14.2 User Authentication and Single Sign-On (SSO)............................................. 79
14.3 Authorizations ............................................................................................... 79
14.3.1 Authorizations for S/4HANA cloud .......................................................................... 79
14.3.2 Authorizations for S/4HANA on-premise ................................................................ 80
14.3.3 Fiori impact on Authorizations ................................................................................ 80
14.3.4 Data Control Language (DCL) for Core Data Service (CDS) for data retrieval ..... 81
14.4 Rules ............................................................................................................. 81
15 Generic Reuse Components ............................................................. 82
15.1 Business Process Management .................................................................... 82
15.1.1 Workflow for ABAP-based applications .................................................................. 82
15.1.2 Business Events ..................................................................................................... 82
15.1.3 Workflow Inbox ....................................................................................................... 82
15.2 Search........................................................................................................... 83
15.3 Rules Engine ................................................................................................. 83
15.3.1 Business Rule Management Systems .................................................................... 83
15.3.2 Business Rules in sSuite ........................................................................................ 84
15.3.3 Business Rules and Configuration/Extensibility ..................................................... 85
15.4 Attachment Services ..................................................................................... 85
15.4.1 S/4 Target Architecture for Content Storage Integration ........................................ 85
15.4.2 S/4 ABAP Services for Document & Attachment Handling .................................... 86
15.5 Data Cleansing and Duplicate Checks .......................................................... 86
15.6 Application Log.............................................................................................. 86
15.7 Business Object Processing Framework (BOPF) .......................................... 87
15.8 Statutory Reporting Framework – Advanced Compliance Reporting ............. 91
16 S/4HANA System Landscape ............................................................ 92
17 Total Cost of Ownership TCO ........................................................... 93
17.1 General Assumption ...................................................................................... 93
17.1.1 General Statement .................................................................................................. 93
17.1.2 Semantic Compatibility in Hybrid Scenarios and Data Migration ........................... 93
17.2 Lifecycle Management .................................................................................. 94
17.2.1 Zero Downtime........................................................................................................ 94
17.2.2 Zero-Downtime-Option of SUM .............................................................................. 96
17.2.2.1 Database Schema Layout ............................................................................... 96
17.2.2.2 Creation of database schemata ....................................................................... 97
17.2.2.3 Allowed database object types ........................................................................ 98
17.2.2.4 Creating and changing database objects ........................................................ 98

© Copyright SAP SE 2017 Internal/Confidential Page 5 of 100

Architecture Guideline S/4HANA

17.2.2.5 Accessing database objects ............................................................................ 98

17.2.2.6 Non-ABAP XSA-applications ........................................................................... 99

© Copyright SAP SE 2017 Internal/Confidential Page 6 of 100

Architecture Guideline S/4HANA

Revision Log
Ver. Date Who Remarks Chap.
2017-11-20 Actualizations in Chapter 3.1 and 3.2 3.1
Stefan Elfner
3.2
2017-11-15 Changed Chapter ‘Time Zone’ and new
Stefan Elfner 5.12.1
Rules [C-CSC-2] and [C-CSC-3]
2017-10-05 New Chapter and new rules [C-MT-4],
Andreas Kemmler 5.3.1
[C-MT-5] and [C-MT-6]
New Chapter for forbidden and unwanted
2017-09-26 Renzo Colle statements and new Rules [OC-APP-17] - 5.18
1805
[OC-APP-21]
2017-09-26 New Chapter for object types and unique ids
Renzo Colle 5.17
and new Rule [OC-APP-16]
New chapter “Statutory Reporting
Christoph
2017-07-25 Framework – Advanced Compliance 15.8
Birkenhauer
Reporting”
2017-07-19 [OC-UX-1]: Fiori dev guideline link changed
Pev 4.2
to Fiori Dev Guide Portal
2017-03-28 Changed Chapter and Rules Data Archiving
Axel Herbst 12.1
versus Data Aging
2017-02-15 New Chapter for database table layout and
Renzo Colle 5.15
new Rule [OC-APP-15]
2016-11-22 New Chapter “15.1.1 Business Events”, 15.1.2
J.-Christoph Nolte
update wording in Workflow Inbox 15.1.3
Introducing new chapter “3.3. Managing
Release Scope and Functional Scope by
2016-11-18 Jochen Boeder Switching” which includes former chapter 0
5.12.4. “Managing Business Functions” and a
new section on “Feature Toggles”.
2.50
2016-11-04 New Rule [OC-UX-13] for draft handling of
Renzo Colle 4.6
reuse components
2016-10-24 Stefan Elfner BSP listed as outdated technology for Cloud 9
2016-09-29 Harald Evers Rule [OC-UX-11] enhanced 4.6
2016-09-27 Renzo Colle Rule [OC-APP-13] enhanced 5.14
2016-09-27 Renzo Colle Rule [OC-APP-10] enhanced 5.13
2016-09-27 New Rule [O-CSC-4] for local update task in
Renzo Colle 5.12.2
modifying OData services.
2016-08-18 New Chapter Cross Release Interoperability
Stefan Elfner 4.7
for S/4HANA
4 New Chapters including Rules
Semantic Compatibility and Fiori Apps 4.5
2016-08-17 Renzo Colle Transactional FIORI Apps 4.6
Optimistic Concurrency Control 5.13
ABAP Domain Conversion Routines 5.14
2016-07-25 Stephan Toebben New Chapter Attachment Services 15.4
2.40 2016-07-01 Martin Mayer New Chapter Zero-Downtime-Option of SUM 17.2.2
Danny von New Rule [OC-AL-4] 15.6
2016-06-06
Mitschke-Collande New Rule [C-BF-8] 5.12.4
2016-05-31 Stefan Elfner IGS listed as outdated technology 9
2016-05-13 Naming ‘OPEN CDS’ changed to ‘ABAP
Stefan Elfner 5.1
CDS'

© Copyright SAP SE 2017 Internal/Confidential Page 7 of 100

Architecture Guideline S/4HANA

Clear definition that S/4HANA runs only on

SAP HANA DB
Wording Changes in Chapter Analytics 10
2016-05-13 Stefan Elfner
10.2
2016-02-16 Adaptions for test automation in chapter “UX”
Christoph Mecke 4,5
and “Application Development”
Adaptation to reflect current status
Volker Wiechers Changed Chapter Cross System Integration 7
2.30 2016-02-01
into other applications
Stefan Elfner Outdated Technologies with successor 9
Changed Chapter Information Lifecycle
Axel Herbst 12
2.20 2015-10-13 Management
Carsten Pluder New Chapter Data Protection 13
New Rule [C-BF-7] Error! R
eferen
ce
source
2015-06-22 Stefan Elfner not
2.10 found.
Changed Chapter Pending Database field
3.7.1
extension
2015-05-22 Renzo Colle New Chapter BOPF 15.7
2015-05-20 Changed Chapter Information Lifecycle
Axel Herbst 12
Management
Rule M-DPL-2 deleted
3.2.3
2015-05-15 Rule M-UX-10 deleted
4.3
Chapter 7.2 General Rules for Managed
Cloud deleted
Stefan Elfner
New Chapter One Cloud 0.1.3
Changed Chapter Consequences to this 0
2015-05-13
2.00 guideline
All rules for PC anc MC merged to CL

2015-04-30 Introduced Virtual Data Model in Target

Horst Schnoerer 3.9
Architecture
2015-04-30 Inserted chapter ‘Adjust Date-Dependent
Horst Schnoerer 3.7.8
Tables’
2015-04-28 Markus Göbel Updated Rule [OC-DO-3] 5.12.3
Changed Chapter Optional Scope 3.2.13.
2015-04-17 Stefan Elfner New Rule [MP-DPL-6] 2.2
3.2.3
1.20 New Chapter Comparison of INFINITY and
2015-04-10 Stefan Elfner 3.5.4
sINFINITY Codeline
2015-04-09 Revised Chapter Identity and Access
Martin Schmid 14
Management
2015-03-05 Most contributers Revised and Confirmed Chapters
1.12
2015-03-24 Stefan Elfner Changed Chapter Field Length Extensions 3.7.1
2015-01-29 New Chapter Introduction of our new product
Stefan Elfner 0
1.00 S/4HANA
2015-01-29 Stefan Elfner Reset of change log

© Copyright SAP SE 2017 Internal/Confidential Page 8 of 100

Architecture Guideline S/4HANA

0 Introduction and launch of our new product S/4HANA

0.1 Evolution of Strategy
0.1.1 Public Cloud (PC)  S/4HANA PC
In Q1 2014 SAP decided to start the development of a Public Cloud solution (PC) based on a classical ERP
EHP7 stack reduced through all non-necessary software components, separated by core scope and hidden
scope to be able to focus on real simplification and cloud qualities. This gave us high degree of freedom while
we were committed to ‘semantic compatibility’ (see below in this document) especially focused on the data
model.

0.1.2 Managed Cloud (MC)  S/4HANA MC

In early Q4 2014 we extended the cloud offering be the so called Managed Cloud (MC) to build an interims
cloud solution with a ‘close to Core ERP’ functional scope to offer installed base customers - willing to move
from On Premise into Cloud - an additional option. It is clear that the additional functional scope does not fulfill
the cloud qualities at the beginning (like scope of the public cloud) but clearly has to over time. Especially
those non-SaaS like Applications increase the Total Costs of Operations dramatically as we now it already
based on out Hana Enterprise Cloud (HEC) experience.
Therefore it is the clear goal from the beginning of the provisioning of S/4HANA MC to follow the cloud
operation principles based on cloud qualities. We have to work constantly together with customers running
their live business processes inside the MC to understand how a service enabling of our non-SaaS like
Applications shall happen. This approach includes also the complete AS ABAP technology stack and all its life
cycle tools and mechanism to come to a complete E2E cloud enabled software solution.

0.1.3 One Cloud (CL)  S/4HANA CL

Just weeks before SAPPHIRE 2015, we understood, that Cloud Qualities are most relevant to achieve the
provisioning of a real cloud solution and the relevance to avoid, that the Managed Cloud does NOT drift into
the role and behavior of a HANA Enterprise Cloud (HEC) offering. Therefore, the decision was taken to merge
the mentioned two cloud variants Managed Cloud and Public Cloud into ONE S/4HANA Cloud Edition. Further
information of the motivation and explanation of differents editions of S/4HANA can be found here:
\\dwdf213\ACI_LOB_SoH\49_Simplified_Suite\30_Workstreams\00325_Architecture\Guideline\S4HANA_One_Cloud.ppt
x

0.1.4 On Premise (OP)  S/4HANA OP

End of Q4 2014 and first days of 2015 the offering was completed by an On Premise (OP) provisioning in
conjunction with a new product umbrella called S/4HANA.
The S/4HANA OP offering completes the extended Public Cloud scope of the Managed Cloud by having the
option to enable Industry and Extension Components as well as optional ERP and Partner AddOns. This
enablement can be done faster as in the MC offering as Cloud Qualities does not have the highest priority.
As those components and its scope are mainly derived from their former Business Suite provisioning the fast
enablement normally contradicts fast innovation and simplification. The only way to innovate and simplify those
components too, is to build up new components in our separated sINFINITY codeline (details below).

© Copyright SAP SE 2017 Internal/Confidential Page 9 of 100

Architecture Guideline S/4HANA

0.2 Consequences to this guideline

This Guideline was originally designed on the assumption that we will build only a public cloud solution fulfilling
all requested cloud qualities and maximize simplification while following the principle of ONE.
As we develop all three mentioned deployments out of one common codeline (sINFINITY) all rules and
principles defined in this document are still valid. As the conversion of non-SaaS like applications,
frameworks and infrastructure will guide us through the next years certain rules will be excluded or weakened
for OP deployment.
The current tagged identifier was defined as [S1--<topic>-<number>]
This will change as follows…
[O-<topic>-<number>] This Rule is valid for On Premise only
[C-<topic>-<number>] This Rule is valid for Cloud only
[OC -<topic>-<number>] This Rule is valid for On Premise AND Cloud

© Copyright SAP SE 2017 Internal/Confidential Page 10 of 100

Architecture Guideline S/4HANA

1 About This Guideline

1.1 Statement of Directive for S/4HANA
To make S/4HANA a success we need to…
a. Simplify, cloud enable and HANA-optimize the existing code (also to be attractive for net new
customers)
b. Support Hybrid scenarios,
c. Enable existing customers of the Business Suite on HANA to migrate to the new product and
d. Support selected downports to Business Suite on HANA to keep our installed base up to date
To reach these partly contradicting goals (a needs changes whereas b, c and d need stability) we need to find
the right balance between changes -driven by simplification- and stability. Therefore we introduced ‘Semantic
Compatibility’.
On the one hand we have to have an eye on the stability of dedicated entities (e.g. external interfaces and
central data models) which need to remain stable as long as possible. On the other hand, in case simplification
forces such entities to diverge from their stability (e.g. change in data model, field extensions, interface
adjustments), mitigations shall be designed and developed (e.g. field length limitations in case of hybrid
scenarios with initial field input in S/4HANA).
To balance these goals is a task in full responsibility of the product owners of the S/4HANA business processes
– they have to ensure most seamless integration and migration in strong alliance with the respective
workstream for migration.

1.1.1 Semantic Compatibility

Semantic compatibility is determined based on the qualified scope for the S/4HANA and its corresponding
scope in the Business Suite on HANA offering.
We will ensure backward compatibility via a transparent, clear and acceptable migration path – this is required
as the new scope offering needs to pass simplification in all aspects (UI, Principle of ONE, modern business
processes…). A Zero-Event-Migration is intended but not guaranteed, as e.g. data model adjustments and
framework unification are also a result of simplification and will need migration. In addition to that the migration
of existing On Premise configuration most likely will mean a migration project to the offered best practice
configuration in the public cloud. Therefore a Zero-Event-Migration is very unlikely.
Please refer also to chapter 17.1.2.
There is no obligation that existing customer and partner coding can be used in the S/4HANA (see chapter
7.4) and thus does not need to be considered for semantic compatibility.

1.1.2 Feature Completeness

The first version of S/4HANA PC (Q1 2015) will not be feature and function complete compared to the Business
Suite on HANA offering. The offering will contain a sub scope of Business Suite on HANA and new
developments. This non-completeness is true for functional scope and technical features. Over time this
divergence will get smaller driven by a clear scope qualification about business processes to be offered in
S/4HANA. The first shipment of S/4HANA MC (Q2 2015) will have an extended Public Cloud Scope containing
a whitelisted set of BAiO Scope Items covering major parts of the classical ERP Core Scenarios. The most
feature complete deployment of S/4HANA OP which may serve also as a platform for any ERP AddOn (SAP
owned and partners) will be shipped first in Q4 2015.

© Copyright SAP SE 2017 Internal/Confidential Page 11 of 100

Architecture Guideline S/4HANA

1.2 Scope of the Architecture Guideline for S/4HANA

This Architecture Guideline for S/4HANA contains the overall architecture decisions, rules and guidelines that
have to be followed by product development for the S/4HANA and all its deployments based on the AS ABAP
Stack definition of Chapter Error! Reference source not found. and all its dependent cross topics.
All rules written here, act as boundary conditions for all other Architecture Guidelines released by development
units inside the Business Suite as long as they have any relevance for S/4HANA. Please note that checks for
compliance of a particular development with these guidelines will become part of the development process.
This guideline does not define the scope of , i.e. it does not describe, which areas will be simplified. This is
decided in the portfolio process – especially in the Workstream where the ‘Core’ and ‘Optional’ is being defined.
This architecture guideline, however, describes, how applications shall be simplified and how new applications
should be developed in future.

1.3 Rules and their meanings

Rules in this document are tagged with an identifier [OMP--<topic>-<number>]. The following abbreviations
are used for the different topics:

Abbreviation Meaning

AddOn Add-On and Enhancement Packages

APF Application Performance

APP Application Development

AL Application Log

AR Analytical Reporting

ATTS Attachement Services

BF Business Functions

BL Business Logic

BOPF Business Object Processing Framework

CLQ Cloud Qualities

CONF Configuration

CSC Central System Configuration

CSI Cross System Integration

DA Data Aging

DO Deployment Option

DPL Deployment

EHP Stable Core and Enhancement Packages

EP Event Provisioning

EXT Extensibility

GOV Architecture Governance

IAM Identity and Access Management

LM Lifecycle Management

MO Mobile Infrastructure

MT Multi Tenancy

OM Output Management

ONE Principle of ONE – Elimination of Redundancies

PC Public Cloud Environment

PF Print Forms

© Copyright SAP SE 2017 Internal/Confidential Page 12 of 100

Architecture Guideline S/4HANA

REUSE Reusable Software

SC Service Consumption

SP Service Provisioning

SERV Service Provisioning and Consumption

SRCH Search

TA Test Automation

TCO Total Cost of Ownership

UX User Experience

WF Workflow

ZDM Zero Downtime Maintenance

The rules presented in this guideline must be followed for all simplified development1. Especially all local
architecture guidelines shall be consistent with these rules. By default, the rules do not automatically imply that
existing architecture shall be changed. Wherever a rule is also backwards effective, i.e. has an impact on an
existing architecture, this is explicitly stated.

1.4 Deviation process

The following deviation process is defined based on the assumption that deviations will take place as
sure as the sundown every day. Especially within the given time frame the ‘time to market pressure’ is
the most contradictory element which will drive deviations. Nevertheless, everyone reaching out for a
deviation shall reflect the fact, that those deviations will weaken the market potential of the new
S/4HANA product and its different deployment options itself. Therefore the transparency of this
deviation process is key making the management aware during its decision about granting or rejecting
a deviation.

1.4.1 Deviations
Main purpose of Architectural Guideline at SAP is to create a most homogeneous product with a high degree
of conceptual integrity fulfilling all qualities which are relevant for cloud applications in a cloud deployment
infrastructure.
However, when working with guidelines one may find that some of its requirements cannot be fulfilled, be it for
technical, strategic, time-to-market or other reasons. Such deviations from the guideline are handled by change
management which encompasses recording deviations and their rationales, finding appropriate workarounds,
invoke an approval process, and apply mitigation strategies. Within Architecture Governance this activity is
named deviation management.
• All deviations of guidelines, ACDs, and implemented functionality from the S/4HANA Architecture
Guideline must be brought to the attention of the Central AI Architecture represented by Tobias Stein.
• All deviations of guidelines, ACDs, and implemented functionality from the respective Unit Architecture
Guideline must be brought to the attention of the respective Lead Architect.
Deviation management serves multiple purposes; amongst others it helps to create transparency, it helps to
improve the guidelines and it helps to direct technology investments.

As to tracking of deviations the rules can be summarized as follows:

• All deviations of guidelines, ACDs, and implemented functionality from the SAP Architecture Guideline
must be brought to the attention of Central AI Architecture.

1 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

© Copyright SAP SE 2017 Internal/Confidential Page 13 of 100

Architecture Guideline S/4HANA

• For all deviations from the SAP Architecture Guideline, the lead architect of the development area
must file for approval as described in the Deviation Requests.
• A record of all approved deviations from the S/4HANA Architecture Guideline shall be kept by the
Central AI Architecture.

1.4.2 Roles and Responsibilities

The Central AI Architecture initiates the process leading to an S/4HANA Architecture Guideline. It organizes
the necessary communication among the architects' community, program and unit lead architects. They are to
be contacted when discrepancies between the S/4HANA Architecture Guideline and another architecture
guideline are detected. The respective topic governance board – if still active - then gives guidance for a
possible workaround and mitigation. Topic Governance boards are established for:
- System Landscape Governance (Link:
https://wiki.wdf.sap.corp/display/archGov/System+Landscape)
- Reuse Governance (Link: https://wiki.wdf.sap.corp/display/BSREUSE/Reuse+Topics)
- Software Component and Software Layer Governance
Governance of software components and software layers covers the following topics:
o Assignment of software components to software layers,
o Requests for new software layers,
o Dependencies between software components,
o Move of development objects between software components,
o New software components
o Splitting or merging software components
All requests are to be addressed to the Software Layer Governance is done in cooperation between
primary contacts. For all questions and approvals of requests mentioned above please contact Jochen
Freudenberg or Stefan Elfner.
The Program Architect is responsible for the creation of Architecture Concept Documents for the respective
development program. He or she supervises the development projects with respect to consistent product
architecture and gives guidance for designing the product components.
The appropriate IMS Contact is to be identified, informed and mentioned in each single ACD (Link:
https://portal.wdf.sap.corp/irj/go/km/docs/guid/10d8baed-b65f-2b10-ce98-a60c3569289d).

1.5 Contact Persons

Lead Architect AI: Tobias Stein
Lead Architect S/4HANA: Stefan Elfner

© Copyright SAP SE 2017 Internal/Confidential Page 14 of 100

Architecture Guideline S/4HANA

2 Principle of ONE – The Key Driver for Simplification

The Principle of ONE is one of the key drivers for simplification. Many of redundant frameworks, data models,
user interfaces and its derived complexity is based on the fact that in former times similar solutions have been
build based on different technologies. One prominent example here is the (meanwhile deprecated) Dual Stack
of AS ABAP and AS JAVA where at the beginning a lot of synergies where planned but never have been
realized. As a result we got different development languages and environments, different software production
processes, different software lifecycle mechanisms, different software qualities/standards, different user
managements, etc.
It is the clear goal of S/4HANA to avoid any of such divergent development from the beginning. This
Principle has no limitations and is valid on each level - from the bottom of the stack (the HANA
Database) to the top of the user interface (Fiori UIs). Each deviation has to be evaluated for its negative
long term aspects in simplification and therefore also costs in all aspects and for all involved parties.
Even if this is not true for the MC and OP deployment of S/4HANA at the beginning, because of its non-
SaaS enabled extended Scope, any inclusion of former Business Suite Applications embedded in the
ERP Stack or as an optional ERP AddOn has to make transparent, where this principle is violated.

2.1 Elimination of Redundancy

Redundancy in frameworks or in business data leads to several problems. Redundant frameworks increase
development-, support-, and operating cost. It also worsens openness, extensibility, and user experience.
Redundant data take up unnecessary storage, increase data transfer and consolidation cost, and can lead to
update anomalies. Therefore S/4HANA shall be designed and built following strictly the principal of one – That
means zero redundancy shall be targeted in frameworks as well as in application data.

2.2 Zero Redundancy in Frameworks

Frameworks serve similar purposes shall be consolidated in one framework in order to fulfill the zero
redundancy paradigms. A framework will be chosen as the target framework based on evaluation process
executed by the applications and the architecture work stream. Obsolete 2 frameworks shall be put into the
quarantine. Applications using obsolete frameworks have to be adapted to use the chosen framework.
Redundancy in frameworks due to leveraging different technologies such as ABAP or HANA native can be
temporary tolerated during the transition phase from SAP Business Suite to S/4HANA. That means it is
temporary tolerated to have maximal two frameworks serving similar purposes – one in each technology.
Consolidation of ABAP based frameworks shall be oriented toward the target framework in Hana technology.
Examples of redundancy in frameworks are the following:

• Rules Frameworks
• Planning tools
• Workflow engines
• Reporting Tools
• User Management Aspects
• UI Technologies

2.3 Zero Redundancy in Application Data

Redundancy in application data is strictly forbidden. Zero data redundancy is a must-have objective, which
has to be achieved during the transition phase towards S/4HANA. Applications owners shall proactively detect
and eliminate data redundancy within the same application as well as across applications that are part of
S/4HANA. Similar to frameworks consolidation process a data consolidation process shall be executed by the
applications and the architecture work stream. In case two or more data models exist that represent similar
objects or contain data with similar sematic, a data consolidation shall take place in order to achieve zero
redundancy. Based on evaluation undertaken by the applications owners, one data model shall be chosen as
target model. The other data models shall be declared as obsolete and put into the quarantine. Applications
using obsolete data models shall be adapted to use the chosen target data model.

2 Frameworks to be removed after consolidation

© Copyright SAP SE 2017 Internal/Confidential Page 15 of 100

Architecture Guideline S/4HANA

[OC-ONE-1] The creation of any new redundancy in frameworks or in application data is strictly forbidden
[OC-ONE-2] Zero redundancy in frameworks shall be achieved during transition phase – Clear roadmap
to zero redundancy shall be available
[OC-ONE-3] Zero redundancy in application data shall be achieved during transition phase – Clear
roadmap to zero redundancy shall be available. This includes also application indices and
aggregation tables.

© Copyright SAP SE 2017 Internal/Confidential Page 16 of 100

Architecture Guideline S/4HANA

3 S/4HANA Deployments and its Scope

In general applications for S/4HANA can be considered at the beginning mainly as ABAP-based applications
coming from the classical Business Suite. The following chapters provide rules and guidelines for
Simplification, Cloudification and Fiorification of existing applications and also for building new business
applications. A primary goal for simplified and new business applications is to make them Public Cloud Ready.
The following chapter provides an overview over the target architecture of Simplified Business Suite
applications consisting of renovated/refactored parts and new business logic.

3.1 Deployment options of S/4HANA

This architecture guideline is based on the assumption that all three deployment options of S/4HANA
mentioned in Chapter 0 are build out of one single Codeline. All definitions and rules are based on the boundary
conditions and rules defined as ‘Cloud Qualities’ in the respective Workstream.
The architecture guidelines has the aim to make only slight differences in rules according its three deployment
options to avoid any ongoing differentiation in its single codeline approach. Whether the Product S/4HANA is
deployed into On Premise or into Cloud. Especially following Chapters are valid for both deployment models:

• Lifecycle Management
• Data and Configuration Migration from On Premise Business Suite to S/4HANA
• Upgrade from S/4HANA Version [n] to Version [n+1]
The advantages of the intended cloud qualities which are essential for SAP to achieve, are in most cases also
advantages for an On Premise deployment.
Following Picture describes very simple how the different deployment options with different enabled scope are
being built out of one so called sInfinity Codeline Software Stack (see also Chapter 3.5).

Figure 3-1: Built Model out of one sINFINITY Codeline

The meaning and task of the Development Consolidation Layer will be explained in next chapters.

3.2 Core, Staging and Deprecated Scope

Scope (Business Processes and Features) mostly belongs to related primary software artefacts. If this scope
and its software artefacts are not defined as former optional software AddOns, we have to expect, that this
scope is interwoven into secondary software artefacts.

© Copyright SAP SE 2017 Internal/Confidential Page 17 of 100

Architecture Guideline S/4HANA

The initial definition of the S/4HANA Public Cloud Scope CORE was based on the Business All in One (BAiO)
baseline packages whereas roundabout 100 Process Scope items across the major application areas like
Materials Management, Sales and Distribution, Services, Financial Accounting and Controlling focusses on
~400 business transactions.
All these 400 business transactions were contained inside the initial Stack of S/4HANA located in one software
component named S4CORE for S/4HANA on Premsie [sInfinity System ER9] or SAPSCORE for S/4HANA
Cloud [sInfinity System ER6 for Cloud only Artefacts]. There are major parts of scope which is still
classified as On Premise only scope, compatibility scope or even deprecated scope.
Outdated scope and its artefacts shall be classified as deprecated – [Field TDEVC-PACKTYPE = ‘D’].

3.2.1 Optional Scope

Not applicable any more

3.2.2 Onboarding and provisioning of formerly deleted Software Components

This process is finished

3.2.3 Rules for availability of Scope

[C-DPL-1] Hidden Scope shall not be accessible for any cloud user and cannot be enabled by SAP
Cloud Management.
[OC-DPL-3] Deprecated Scope shall not be accessible for any user.
[O-DPL-4] Optional scope based on optional software components is only available for S/4HANA On
Premise because all cloud offerings shall have an identical stack definition.
[OC-DPL-5] New Scope shall only be available after explicit activation through mechanisms of SET
[C-DPL-6] Industry Switches or Extensions Switches based on the switch framework or any non SET
like mechanism are forbidden and shall be redesigned to fulfill the requirements of SET
configuration. In S/4HANA CLOUD business functions are freezed.

© Copyright SAP SE 2017 Internal/Confidential Page 18 of 100

Architecture Guideline S/4HANA

3.3 Managing Release Scope and Functional Scope by Switching Code

There are several good reasons to switch between different source code variants. In S/4HANA the following
three switching technologies are available – each specialized for a dedicated use case:
• Customizing settings – runtime switch stored in C-tables to determine and run specific variant of
implemented business functionality
• Business Functions – compilation switch based on Switch Framework to activate additional software
artifacts (to be used only in context of industry processes or for optional scope in on premise)
• Feature Toggles –runtime switch which exists only temporary to decouple functional upgrade from
technical upgrade
In the following rules and limitations in using the different switching options are explained:

3.3.1 Customizing
Customers scope and configure S/4HANA Cloud using Packaging Framework and Best Practice Content only!
See rules for availability of scope [OC-DPL-5] and rule for Delivering Innovation as customer option in Public
Cloud [OC-PC-11]
All definitions and rules for predefined configuration content, configuration methodology and Fiori based cloud
user configurations can be found in following WIKI: https://wiki.wdf.sap.corp/wiki//x/Zb3bXw

3.3.2 Handling Business Functions

See rule for availability of scope (copy for your convenience)
[C-DPL-6] Industry Switches or Extensions Switches based on the switch framework or any non SET
like mechanism are forbidden and shall be redesigned to fulfill the requirements of SET
configuration. In CLOUD business functions are freezed.
Exceptions may apply for industry processes to be made available in S/4HANA Cloud. For this a new type of
“Business Function Scoping” is in preparation. If you are interested in piloting it, please contact Erich
Ackermann.
From former Enhancement packages there are over 1000 Enterprise & Industry Business Functions and
Enterprise AddOns, which customers so far can choose to activate or to leave them switched off. In order to
reduce complexity, the following options will be available in S4H:
[C-BF-1] For S/4H Cloud all existing Business Functions shall have a state predefined by SAP as either.
• Always On
• Always Off (Default behavior if not defined explicitly)
This state is common to S/4HANA Cloud and shall not be changeable on a per customer basis
Status “Always On” can be chosen by the product owner if
• it’s relevant for the Cloud scope
• and if there is no known side effect on other Cloud scope
• And if it is ensured that any switched table content of the Business Function is
repackaged as SaKP content according to the SaKP guidelines.
The planned status of a Business Function shall be maintained as attribute of the BF in SFW2.
In follow-on shipments the following status changes are allowed:
• Always Off -> Always On

[O-BF-2] For S/4H On Premise Deployment all existing Business Functions shall have a state
predefined by SAP as either.
• Customer Switchable. (Default behavior if not defined explicitly)
• Always On
• Always Off
Status “Customer Switchable” is the same behavior as in the past. It’s up to the customer to
decide, whether he wants to activate a BF or not.

© Copyright SAP SE 2017 Internal/Confidential Page 19 of 100

Architecture Guideline S/4HANA

Status “Always On” can be chosen by the product owner, if

• This results in no or low additional upgrade effort for customers regarding adaption
of configuration, change of business processes, training of users and potential
adaption of custom code.
• Or if development of additional simplifications is not possible, if the BF is not active
by default also On Premise.

Status “Always Off” means, that new customers cannot activate this BF in S4H OP. Existing
customers who have already activated this BF, cannot upgrade to S4H OP! So use it
with care. This is primarily intended for industries which are not yet released in S4H OP but
technically part of the stack.
The planned status of a Business Function shall be maintained as attribute of the BF in SFW2.
In follow-on shipments the following status changes are allowed:
• Always Off -> Always On
• Always Off -> Customer Switchable
• Customer Switchable -> Always On

[OC-BF-3] If a Business Function is defined as “Always On” by SAP in all three S/4H deployment
options (Cloud and On Premise) the Business Function and Switches can be removed in
some cases, so the functionality behind the Business Function further on is not switchable
anymore. Details see
\\Dwdf213.wdf.sap.corp\aci_lob_soh\49_Simplified_Suite\30_Workstreams\25_Architecture\
BusinessFunctions\Business_Function_Removal.docx

[OC-BF-4] New, S4H specific development shall not be switched via Swtich Framework. This refers to
further developments in functionality which is designated as the “go-to” functionality in S4H
and which is recommended to be used by customers – typically new, already simplified
applications. Contrary to old, redundant functionality which we offer in S4H only in order to
reduce the initial upgrade effort for customers.

[OC-BF-5] New Business Functions introduced in further developments of old functionality in the
context of EHP8 or future Enhancement Packages, which reach S4H via upports are also
subject to rules [*BF-1-4 and 6-7]. Preferred option in this case is - if a status of “Always On”
is possible in all three deployment options in line with rules [*BF-1-2] – to not introduce the
Business Function in the first place in the S4H codeline.

[C-BF-6] Contrary to On Premise deployments, where consultants on customer side decide if and
which non-cascading delivery customizing is cascaded from client 000 to productive clients,
this is exclusively handled by SET (SaKP) processes and tools in Cloud deployments. So if
you declare a Business Function as “Always On” in Cloud and this Business Function
contains Switch BC Sets with client-specific, non-cascading table content (table delivery
class C,G) you have to get in contact with the SET PO of your development area (see
https://wiki.wdf.sap.corp/wiki/display/SimplSuite/Best+Practice+Content ) to ensure, that this
content is handled in line with other best practice content (repackaged or at least added to
the white list for a clean client setup).

[C-BF-7] DDIC shall not be switched in S/4HANA Core code line. DDIC shall be the same in S/4 On
Premise and S/4 Cloud for the common parts, means software component S4CORE.

3.3.3 Feature Toggles

A feature is a distinctive functionality of S/4HANA, which provides a specific benefit for users/customers.
Feature toggling is a best practice in Cloud development to decouple functional upgrade from technical
upgrade. Feature toggles allow to toggle a feature on and off. By this they support continuous delivery, beta
test (canary launch) with selected customers, and phased rollout of functionality.
There is no beta test in on premise. Thus feature toggle is in on premise either always off (hidden code delivery)
or always on (released).

© Copyright SAP SE 2017 Internal/Confidential Page 20 of 100

Architecture Guideline S/4HANA

As of now (this version of the guideline) feature toggles are in pilot phase and support hidden code delivery
only. If you are interested to try feature toggles, please contact Vijaya A Bhaskar or Jochen Boeder.
[OC-FT-1] One „Feature“ shall be enabled/disabled by one feature toggle. Arbitrary functional pieces shall not
be bundled as a feature.
[O-FT-2] In on premise release feature toggles shall be used only to hide a feature (“hidden code delivery”).
There is no beta test using feature toggles in on premise.
[C-FT-3] Feature toggles are temporary. After final release of a feature to all customers, the feature toggle
shall be removed and the corresponding source code cleaned up.
[OC-FT-4] Feature toggles must not be exposed to customers directly. They can be activated either directly by
SAP or indirectly by the customer selecting scope items.
[OC-FT-5] In case a features is partly implemented in S/4HANA Core and partly in SAP HCP, each feature
part shall use a separate feature toggle according to its technology platform. The dependency shall be
managed manually until supported by the central feature repository.
As a guidance a feature should be implemented with least amount condition statements possible to limit the
effort to remove them afterwards. Often it is sufficient to hide the new feature on the UIs and APIs.

3.4 Shipments of S/4HANA

The different Shipments of S/4HANA are defined in Chapter 0.1.

3.5 Software Component Stack of S/4HANA

3.5.1 Categories of the S/4HANA Stack (valid for Figure 3-2, 3-3 and 3-4)
Blue SCs SCs have been built out of the corresponding software component from the On Premise Suite Stack
ERP EhP7 SP05 and have performed a code split – means a full copy of the former business suite code.
Grey SCs are not in the scope of the targeted core but they are interwoven by blue SCs. They are realized via
virtual software components as their source of development is the business suite on premise delivery codeline.
They are not open for development and consolidated into the HIDDEN software component. In the meantime
these SCs play a minor close to no role anymore.
Yellow SCs are not in the scope of the targeted core, are technically decoupled from the dark blue or grey
SCs. They are only available in S/4HANA On Premise and can be merged into the blue SC in case the Cloud
scope is being enlarged through a stack extension request procedure. Achieving Cloud Qualities are
mandatory as entry condition into S4CORE.
Blue/Grey Hatched SCs is the so called Quarantine/Staging component where code artifacts constantly will
be enabled for cloud provisioning.They are open for development
Green SCs are based on the current most recent available AS ABAP NetWeaver Technology Stack.

© Copyright SAP SE 2017 Internal/Confidential Page 21 of 100

Architecture Guideline S/4HANA

Figure 3-2: 1805 Stack for sInfinity Development – internal Grouping [ER9]

3.5.2 Software Component Merge and relabeling to S4CORE and SAPSCORE

After all SCs of the initial stack are classified concerning their target category, all remaining SCs classified as
a blue SC are being merged into one final S/4HANA On Premise Software Component S4CORE. This Stack
is opened for general application development.

Figure 3-3: 1805 Stack for sInfinity Development – [ER9]

© Copyright SAP SE 2017 Internal/Confidential Page 22 of 100

Architecture Guideline S/4HANA

Figure 3-3: 1805 Stack for sInfinity Development – [ER9]

Figure 3-3: 1805 Stack for sInfinity Cloud only Development – [ER6, ER3]

3.5.3 Reasons for Software Component Merge

A software component from its original definition is the smallest self-contained unit which can be maintained
separately. One or more software components are bundled in a software product instance which defined the
smallest installable/upgradeable unit.
As an experience from the On Premise Software Stack there are numerous unwanted but known dependencies
between software components. This prevents us in the On Premise World of maintaining software components
individually.
Even without those unwanted dependencies the inner stack interoperability between software components
cannot be ensured and finally lead to the definition of support package stacks.
Therefore we decided to go for ONE main software component supporting ONE deployment option.

© Copyright SAP SE 2017 Internal/Confidential Page 23 of 100

Architecture Guideline S/4HANA

Without massive and sustainable changes inside the software stack (stable interfaces, elimination of
dependencies, version interoperability, 100% clean package definitions…) this one component approach will
remain. This shall also be a role model for a next Suite on HANA release.

3.5.3.1 Elimination of Interfaces, Extensions or BAdIs

Already interwoven software layers like SAP_APPL and EA-APPL still have a lot of interfaces and even BAdIs
from former times where R/3 Enterprise Extensions where founded. As the current separation of software
components is pure theoretically the aim is to bring together what belongs together – there is no need any
more for this type of separation.

3.5.3.2 Simplification of Quarantine Process

As the current quarantine methodology on premise is based on the requirement that for every software
component where objects are being separated, an own quarantine component in a 1:1 relation has to be
defined, the demand is clear to merge strongly interwoven software component before starting any quarantine
processes.

3.5.3.3 No different deployment options / combinations

As of now, there is neither the need to establish different deployment options and/or combination nor the need
to provide ‘Enhancement Package’ capabilities, where different software components might reduce the effort
for lifecycle processes. The current approach to also realize minimized downtimes in a Cloud based
infrastructure in combination with the full load approach embedded in the zero downtime maintenance
procedure expect simple software structures – means ONE application software component S4CORE.
Based on the full load approach the size of the software component is not relevant for the duration of the
lifecycle and maintenance processes. Modifications – a major downtime origin – are not given in our cloud
approach.
As we have a bunch of initially excluded software components (industries, extensions, new dimensions and
AddOns) which might drift into the S/4HANA Scope without having established cloud qualities and needed
simplifications, those optional components will most likely be available only for the S/4HANA On Premise
deployment.

3.5.4 Comparison of INFINITY and sINFINITY Codeline

As mentioned above, the sINITITY code line - which has been build out of a copy of dedicated core software
components from ERP EHP7 - has the aim to accelerate simplification and innovation based on SAP HANA
with the purpose the serve as one codeline for all three deployment options PC, MC and OP. Where the OP
deployment is a symbiosis of the sINFINITY codeline and also dedicated parts of the INFINITY codeline. The
INFINITY codeline is nothing else as the current Business Suite on HANA Development Codeline for current
and upcoming enhancement packages of SAP ERP.
The following picture shows the current development landscape and relations of INFINITY and sINFINITY.
The most interesting part is the mentioned symbiosis for the S/4HANA On Premise Development Consolidation
where all Simplifications of ‘sFIN’ and ‘sLOG’ are being merged with all formed decoupled software
components (Enterprise Extensions and Industry Solutions) which were not taken into consideration when
doing simplifications in S4CORE.

3.6 Most recent Stack Definitions and dependencies for S/4HANA

The most recent definition of the INFINITY and sINFINITY Development Stacks can be accessed here inside
the presentation of <S4_HANA_EHP8_Stack_And_Handling_of_Industries_EAs_AddOns_Vxx>
\\dwdf213\ACI_LOB_SoH\49_Simplified_Suite\30_Workstreams\25_Architecture\S4HANA_StackDefinition

© Copyright SAP SE 2017 Internal/Confidential Page 24 of 100

Architecture Guideline S/4HANA

3.7 Activities to be done right after the software component merge

3.7.1 Pending Database field extension
The current collection of all proposals is stored here:
\\dwdf213.wdf.sap.corp\aci_lob_soh\49_Simplified_Suite\30_Workstreams\25_Architecture\FieldLengthExten
sions
We all agree that the positioning of a new product like S/4HANA without the realization of long term demanded
field length extensions like material number, value fields or FI-document position field, this new product will
not convince in that area. It is also clear that in case we are not able to introduce such field length extensions
in the first shot of the on premise edition in Q4 2015 it will be challenging to introduce such extensions at a
later point in time.
It is clear that within the remaining time until development close in August 2015 we will not be able to introduce
all requested field length extensions as those changes – dependent on its usages – are capable to destabilize
the complete development environment.
Therefore, after the successful POC for the material number (MATNR) (investigation on different approaches,
consequences and definition of needed tools and conversion capabilities to ensure, to be able to drive any
requested and meaningful field length extension for all different deployment options for S/4HANA), it was finally
confirmed by the Management to execute the extension of the field MATNR (Material Number) on its domain
definition from CHAR(18) to CHAR(40) and to deliver it with S/4HANA 1511.
All activities to this POC are given here:
https://wiki.wdf.sap.corp/wiki/display/SimplSuite/MATNR+Field+Length+Extension

3.7.2 Elimination of Client-Dependency or Client-Independency

Not yet collected as enabling of multi tenancy capabilities - where this type of elimination is the first step - is
currently not Prio 1 for the AS ABAP technology and its dependent applications. Please refer also to chapter
5.3.

3.7.3 Include Split of ABAP Includes to optimize automated tests

Not yet decided as code would diverge at a very early point in time. This would also have a negative impact

3.7.4 Change of Master Language for all components to English

It has been decided that the Master Language for the S/4HANA is being set to English. The procedure to
realize the Language Switch is described here.

https://wiki.wdf.sap.corp/wiki/display/SimplSuite/Mandatory+Developer+Onboarding+Information#Mandatory
DeveloperOnboardingInformation-MasterLanguageSoftSwitch

The logon language will be defaulted with English and can’t be changed.
All new objects will be created in the new Master Language. In case of changes to existing objects where the
master language is German, the following Popup will be suppressed and internally process with the option
‘Change orig. language’.

© Copyright SAP SE 2017 Internal/Confidential Page 25 of 100

Architecture Guideline S/4HANA

Figure 3-7: Decision Popup for change of master language

Please be aware in case a sub-object e.g. a function module is being changed for its master language that
this will enforce that the complete main object – here the function group – and all its sub objects will be
changed concerning the master language.

3.7.5 Handling of Business Functions

This chapter is superseded by chapter 3.3.2

3.7.6 Convert Pool Tables / Cluster Tables

Remaining POOL tables GLP1, GLP2, GLPPC, GLS1, GLS2, GLSPC, GLP1, GLP2, and JVS1 will be
transferred to the Quarantine Process.
[OC-DDIC-1] It is forbidden to create new POOL or CLUSTER Tables
[OC-DDIC-2] Existing POOL or CLUSTER Tables shall be converted to TRANSPARENT Tables or
transferred into the Quarantine Process.

3.7.7 Eliminate Match Code Tables

They shall be deleted.

3.7.8 Adjust Date-Dependent Tables

Some business entities have date-dependent attributes. In most cases the corresponding database tables
have either a ValidityStartDate (e.g. BEGDA, DATAB, FROM_DATE) or a ValidityEndDate (e.g. ENDDA,
DATBI TO_DATE) as key field and often the corresponding ValidityEndDate or ValidityStartDate as attribute
field.
Examples:
DB table ETAB1: EKEY | TO_DATE || FROM_DATE | ATTR1 | ATTR2 
DB table ETAB2: EKEY | FROM_DATE || ATTR1 | ATTR2 
DB table ETAB3: EKEY | COUNTER || FROM_DATE | ATTR1 | ATTR2 
If such tables do not contain upper and lower date boundary (like ETAB2 and ETAB3), a complex SQL
statement is needed to determine the records which are valid for a certain key date. If you would like to select
the valid record from ETAB2 for a parameter P_KeyDate the select statement would look like this:
select * from ETAB2 as A inner join
(select EKEY, max(FROM_DATE) from ETAB2 where FROM_DATE <= P_KeyDate group by EKEY) as B
on A.EKEY = B.EKEY and A.FROM_DATE = B.FROM_DATE
A self-join with a subselect containing an aggregation function would be necessary which has a negative
impact on performance and can currently not be expressed in a single CDS view (as subselects are not
supported by ABAP CDS).
Therefore the following rule is strongly recommended:
[OC-DDIC-3] If entries of a table are only valid for a certain date interval, the table shall contain columns
for upper and lower date boundary (e.g. ValidityStartDate and ValidityEndDate) which are
interpreted as closed interval. If one of both is missing, it shall be added to the table and filled
properly by the application. For low-date use ‘00010101’, for high-date ‘99991231’.
The requires some more effort in the update logic for such tables but it improves read access to such tables
(which usually occurs much more often than updates).

© Copyright SAP SE 2017 Internal/Confidential Page 26 of 100

Architecture Guideline S/4HANA

3.8 Deprecation Process

The Deprecation process has the aim to completely separate outdated scope and its software artefacts from
the S/4HANA Infinity Stack to continuously reduce the footprint of unused and therefore hidden functionality.
For details of the quarantine process please refer to the following Wiki:
https://wiki.wdf.sap.corp/wiki/display/SimplSuite/.

3.9 Target Architecture for S/4HANA Applications

The target architecture at runtime is depicted in the diagram below. It accentuates prominent Suite application
technology stacks in its horizontal arrangement whereas the semantics of the agents along with the
incorporated technologies and frameworks are vertically oriented.
In the figure, the Fiori Shell Layer represents the variety of client technologies available for the users’ workplace
to interactively process transactional and/or analytical and/or search related data.
As a first step towards target architecture several engines, frameworks are classified inside the S/4HANA
Layer consuming the S/4HANA Tables directly via Business Logic inside Transactional Logic or CDS Views
exclusively. The Analytical Engine contains no business.
ABAP CDS views can be used in any application logic in order to push down application logic from ABAP into
HANA. The Virtual Data Model (VDM) consists of ABAP CDS views which follow dedicated guidelines. The
Virtual Data Model based on CDS builds a semantic layer on top of the existing Suite database model hiding
its technical details. It is subject to central governance and shall provide a well-defined, homogeneous data
model providing all necessary metadata for consumption tools as well as associations between different views.
The usage of ABAP CDS views following the VDM guidelines is mandatory for the following use cases:
• Any analytical content (e.g. queries, cubes etc. exposed via generic analytical tools like Lumira,
Design Studio, …)3
• New transactional or analytical FIORI applications (following the S4HANA target architecture, please
pay attention to performance constraints)
• Smart Business KPIs
• Fact sheets and object pages
Finally, HANA is the one and only Persistence of the business data and configuration stored in S/4HANA
Tables.
Please remark that the following picture shows the Gateway Component as an embedded component in the
S/4HANA ABAP Stack. This is correct for the S/4HANA Cloud provisioning whereas the S/4HANA On Premise
deploement expects and recommends a separate UI Frontend server.

3 Currently, the usage of Design Studio and Lumira is not recommended in S/4HANA. See Current Restrictions
for details.

© Copyright SAP SE 2017 Internal/Confidential Page 27 of 100

Architecture Guideline S/4HANA

High-Level Runtime Architecture (TAM Component Diagram)

© Copyright SAP SE 2017 Internal/Confidential Page 28 of 100

Architecture Guideline S/4HANA

4 User Experience and UI Development

4.1 Basic Principles and Goals
Goal: Ensure a unified look of all S/4HANA applications. The solutions that are part of S/4HANA must
“feel like one Suite” and it must be easy to recognize that they are products of SAP. We want
to have a recognizable SAP UI Brand in the Web Browser and we need consistency with global
marketing campaigns.
However, there is an important constraint for the efforts to unify the look of the former Business Suite
applications: Existing customers shall not be forced to conduct new end user trainings for existing
functionality. Therefore UI Simplification is Key which is currently driven by the convincing FIORI
Initiative. We expect that existing UIs will be disruptively exchanged by self-explaining new FIORI
Based Applications.

4.2 UI Technologies for S/4HANA

S/4HANA is a new product with aim to achieve a modern state of the art UI–Technology. Therefore
the simplified, browser based and self-explaining approach of FIORI is the 1st priority for any new
applications for professional and occasional users. As configuration and administration tasks won’t
be eliminated in a public cloud environment, those applications shall also be provided by FIORI UIs.

[OC-UX-1] All new applications for any purpose of User Accesses (Application, Configuration
and Administration) shall be developed based on the FIORI UX paradigm. All Fiori
design principles and Fiori development guidelines for Business Suite are also valid
for S/4HANA. In case there is a dedicated deviation this will be mentioned in same
Fiori development guidelines.

As mentioned before in the deviation section, we expect the first rule won’t be applicable for all
applications defined for the business scope of S/4HANA. Therefore there is – especially for already
existing applications – a 2nd choice for UI technology to be allowed in the S/4HANA product:

[C-UX-2] All existing applications inside the defined scope which cannot be converted or re-
build into FIORI applications shall make use of WebDynpro ABAP Technology
based on the Floor Plan Manager (FPM) concept or WebGUI (HTML GUI).
[O-UX-9] All existing applications inside the defined scope which cannot be converted or re-
build into FIORI applications may stay based on SAP-GUI.
[OC-UX-3] For use cases were the visualization of the location context (via geocodes) is
needed the Visual Business component shall be used. For use cases were the
visualization of 2D and/or 3D CAD drawings is needed the Right Hemisphere
component shall be used. Further information and detailed rules will be linked into
this document as soon as possible.
[OC-UX-4] Rules for the usage of Adobe interactive forms (aka SAP Interactive Forms by
Adobe) can be found here. See also 11.1.1 (Rules for Print Forms)
[C-UX-6] Configuration and Administration UIs for Cloud Managing End Users (Shared
Service Center, SAP-IT Administrators) might have access on existing applications
(e.g. Transactions like SPRO, ST*, SM*, SE*). There is no access of Cloud
Customer Users to IMG (SPRO).

4.3 Automatic Processing of UIs (Batch Input)

The handling and behavior of Batch Input is too complex to be used as any type of automated or
semi-automated data input. Therefore this technique is not allowed to be used in any Business
Processes or Applications for S/4HANA Cloud offering. Any external data input has to be done via

© Copyright SAP SE 2017 Internal/Confidential Page 29 of 100

Architecture Guideline S/4HANA

• OData services (recommended)

• SOA services
• BAPIs (On Premise only)
• RFCs (On Premise only)

[C-UX-6] Batch-Input is not allowed in any Applications or Processes for S/4HANA Cloud
offering.
[OC-UX-7] Batch-Input is only allowed for Configuration, Administration and especially Test
Automation purpose in case the executing user belongs to a cloud infrastructure
managing role. The target is to get rid of batch input in applications.

4.4 Test Automation

Every Application shall provide automated frontend test and unit test to ensure minimization of test
efforts after any maintenance procedure.

[OC-UX-8] Frontend test automation and unit tests for all S/4HANA applications is mandatory

4.5 Semantic Compatibility and Fiori Apps

As described in chapter 1.1.1. it is ensured that the qualified scope for S/4HANA is compatible to its
corresponding scope in the Business Suite on HANA or a clear transparent and acceptable migration
path is offered (Simplification Database).
Further it is stated that there is no obligation that existing customer and partner coding can be used
in the S/4HANA (see chapter 7.4) and thus does not need to be considered for semantic compatibility.
Another dimension in this compatibility discussion is the introduction of new FIORI apps beside the
existing SAPGUI (or WebGUI and WebDynpro in the Cloud). It is a clear statement from Wieland
Schreiner and Rudolf Hois (Owner of FIORI in S/4HANA) that the compatibility with regard to scope
as well as customer and partner coding first of all applies to the existing SAPGui UIs with the rules
stated before. FIORI apps by definition usually don’t cover the complete scope of an existing SAPGUI
transaction one to one, but address only part of the scope and evolve over time in scope or even
further additional role-based apps. This is an accepted approach for an S/4HANA roadmap with
regard to the scope of FIORI app vs. the complete scope of S/4HANA.
Further due to the different (backend) programming model required for native FIORI apps also
extension points for customers and partners might not be available within the FIORI app or might be
affected otherwise (e.g. called more often, at different points in time or with a different overall context
and ABAP memory state). Thus existing customer and partner coding might not be called any more
at all or needs to be reviewed for functional correctness when invoked within a FIORI app. Thus in
such cases if the same options shall be offered also from the FIORI app it might be necessary to
introduce additional alternative extension points from application side. For existing extension points
rated as uncritical (when properly used by the customer or partner) need to indicate problematic
extension point implementations for the preparation of a migration to S/4HANA.
Obviously the applications need to ensure that in case extension points do not run in the context of
FIORI apps that no inconsistencies can arise from this. It could be that in such cases interoperability
of the FIORI app and the old transactions is not given.
[OC-UX-10] FIORI apps may not be compatible with regard to the invocation of extension
implementations. Applications need to check the existing extension points and
indicate in the simplification list which might not run in the context of Fiori and/or
offer new extension points accordingly.

© Copyright SAP SE 2017 Internal/Confidential Page 30 of 100

Architecture Guideline S/4HANA

4.6 Transactional FIORI Apps

FIORI apps in S/4HANA follow the REST-based communication paradigm via OData. A hard coupling
of the UI session and the backend session is not allowed to enable the necessary server elasticity in
the Cloud. This implies that every modifying server request leads to a consistent and reliable resource
state that can be retrieved at any time from any device. Depending on the needed functionality and
the complexity of the application there are two options to implement a FIORI app in such an
appropriate way.

1. The FIORI app is very simple or any kind of business logic necessary based on the user
interaction is provided in the client implementation or orchestrated and invoked from the client
side via functional (non-modifying) services. The modifying request is sent to the server at the
end of the user interaction and invokes further server business logic and stores a consistent state.
Example: Leave Request with very few business logic during user interaction and major logic only
during leave request submission.
2. The FIORI app is requiring major server logic during user interaction that is not or cannot be made
available via functional services, e.g. due to massive reuse of existing backend functionality. As
the modifying requests do not lead to a consistent state (in the sense of a business consistency)
in this approach the transactional application shall be draft-enabled.
Example: Purchase Order with major business logic invocation during user interaction.

As the draft-enablement adds further features like “data-loss prevention”, “start now, continue later”,
“device switch” and even “collaborative editing” it might be requested (by the product owner) that also
FIORI apps without major business logic invocation apply the draft concept.
Example: Leave Request where I can plan my next vacations, but do not yet submit it to my manager.

[OC-UX-11] FIORI apps shall apply the draft concept by providing a draft-orchestrated OData service
and enabling the underlying application for draft handling if they need:
a) modifying server requests for business logic invocation during user interaction
b) pessimistic locking of active data to protect draft processing against conflicting changes of
existing application logic used by classic UIs or process integration scenarios.
c) Draft features and related UX qualities (data loss, continuous work, shared editing, …)
Conversely, Fiori apps may disregard applying the draft concept if
d) logic is purely triggered via (parameterized) quick actions
e) the entire state can be kept in a single view on the UI and saved at once.
In all cases, the consistent state of draft or active entities needs to assured by implementing eTags.
In case of e) applications must be aware that these data entry apps only provide optimistic
concurrency control and have a different UX behavior than apps with draft enablement4.

Further as based on this rule many applications and business objects will implement draft-enabled
Fiori apps it is obvious that also any embedded reuse component with own persistency that can be
maintained together with the using business object has to support this concept. Otherwise the UI
behavior would not be consistent and data of the using business object is stored when cloding the
browser where data of the reuse component is lost. Examples are Attachments, Notes, Proces Route,
Pricing, etc.
Reuse components that are maintained separately and only based on active data do not necessarily
need to adapt the draft concept. Examples are Application Log, etc.

4 Limitations of Smart Templates for non-draft enabled apps can be found here:
https://wiki.wdf.sap.corp/wiki/display/fioritech/Non-Draft-App+restrictions+and+limitations

© Copyright SAP SE 2017 Internal/Confidential Page 31 of 100

Architecture Guideline S/4HANA

[OC-UX-13] The adaptation of the draft concept for reuse components with own persistency that can
be maintained together with its using business object (i.e. with an “aggregate”-dependency) is
mandatory.

4.7 Cross Release Interoperability for S/4HANA

There is no interoperability planned between S/4HANA 1511 and S/4HANA 1610. This means:
customers have to upgrade both Frontend and Backend to S/4HANA 1610.
[OC-UX-12] Starting with S/4HANA 1610 cross release interoperability is a must. Further details
can be found here…
https://wiki.wdf.sap.corp/wiki/display/fiorisuite/Frontend+Backend+Interoperability#F
rontendBackendInteroperability-CrossReleaseInteroperabilityforS/4HANA

© Copyright SAP SE 2017 Internal/Confidential Page 32 of 100

Architecture Guideline S/4HANA

5 Application Development
5.1 Usage of HANA Content
S/4HANA is clearly and only based on SAP HANA DB. The following rules apply regarding the usage
of HANA specific functionality:

[OC-APP-1] The use of HANA specific features is generally allowed and there is no need to cover
the usage of such features in Optimization BAdIs (as it is needed for the Business
Suite 7 i2013 Quarterly Shipments).
[OC-APP-2] Everything (performance, functionality …) which can be reached with ABAP, Open
SQL and ABAP managed HANA features (views, procedures, table functions)
should be done by using these techniques as they still have advantages in the area
of extensibility, supportability, life cycle management and operations compared to
the corresponding HANA managed objects (calc views, …)
[OC-APP-3] It is not allowed to create new HANA repository objects if they don’t fulfill the lifecycle
requirements of Zero Downtime Management (ZDM). Existing HANA repository
content shall be migrated / converted to ABAP managed artefacts or to HDI
supported content.
[OC-APP-4] New Virtual Data Models (VDM) used e.g. in S/4HANA shall be realized via ABAP
CDS. Existing VDMs which shall be used in S/4HANA shall be migrated / converted
to ABAP CDS.
[OC-APP-8] ABAP managed stored procedures and table functions are fully supported and shall
be used in case they offer a better performance as ABAP CDS views or if they offer
functionality which is not available with ABAP CDS.
You will find more information, tips and tricks and best practices about CDS Views and AMDPs in
the following Wiki: https://wiki.wdf.sap.corp/wiki//x/KrQMY

5.2 Activation of Optional Scope

The current assumption is that optional scope does not meet cloud qualities criteria. This means
especially that there is no pre-configuration content and no self-service configuration UIs. This means
it is not selectable and not visible to cloud customers.
The only deployment where optional scope may be activated is the S/4HANA On Premise. This can
then easily be realized via the proven technology of business functions of the switch framework.
[O-APP-5] The activation of optional scope shall be done via business functions using the
switch framework.

5.3 Ensuring Multi Tenancy Capabilities

In all cloud offerings the users (“consumer”) share “something”, but do not share everything. For cloud
business applications -like Model S- sharing is organized through tenants. A tenant represents a
user organization, most likely an enterprise, which experiences the service as if they were operating
it in a dedicated environment, without interference from other tenants.

What is shared and how isolation is reached depends on the Multi Tenancy (MT) implementation
concept.

Typically the following areas are using and therefore depending on the multiple tenancy concepts

• Isolation of tenant data  Used for Backup & Restore

© Copyright SAP SE 2017 Internal/Confidential Page 33 of 100

Architecture Guideline S/4HANA

• Application System Provisioning /Tenant provisioning

• Isolation of tenant execution characteristics (performance, availability)
• Tenant-aware security, management and operations, reporting
• Isolation of tenant customizations and extensions to business logic
• Tenant-aware error-tracking and recovery
• Tenant-aware resource and SLA management
• Horizontal scalability to support real-time addition of new tenants or users

From a customer point of view isolation and integrity of the tenant is the primary requirement while it
is in the provider’s interest to have a maximum of shared “resources” to minimize the cost. Resources
can be hard- and software. For hardware resources providers typically try to “underprovide” the
tenants needs while assuming that the probability that the maximum allowed usage of the resources
seldom occurs and is still manageable (not fatal).
For HEC scenarios or typical IaaS vendors the datacenter, the network and the virtualized hardware
is shared. The main mechanisms to enforce isolation are in the network and in the virtualization
techniques for hardware.
Other SaaS implementations have chosen to implement the multi tenancy by application frameworks
sometimes supported natively by application programing models and languages. In case of larger
tenant sizes they use database techniques like DB-schemas and/or multiple databases to achieve
data isolation and efficiency.

Where do we start with S/4HANA?

• The ABAP system does not use database techniques to reach data isolation – they use a
concept only known to the application server based on the “client” field
• We intent to push more execution into the database. To have a proper MT support or even
an enforcement of MT database techniques for isolation must be used.
• The tenant (data) separation is not enforced by the application server – only enabled
• The multi-client separation rules are very often violated in the current ABAP coding
• ABAP extension mechanisms are largely ABAP language oriented. They lead to system
artefact (source code / DDIC) which are shared within one system.

As a consequence of the high implementation costs it was decided that we do not introduce a MT
concept based on the ABAP client field in the foreseeable future – like we did it with ByD. We still
fulfill the customer requirement for isolation through the fact that tenants will get their own ABAP
system. While database management as well as some hardware costs could be reduced by
leveraging the “HANA multiple DB” feature, this does not address the TCO reduction a multi-tenant
application server could provide. They are addressing different cost drivers. The “Hana multiple DB”
concept does not imply any specific rules for application development as long as we are consuming
data from one schema out of one “tenant DB” which is the case for Model S.
On the other hand the ABAP client field is used also for other proposes than data separation between
the clients; it is also essential for the separation of “system” managed artifacts by the provider and
the actual “tenant” data. This “separation of concern between business users and provider IT“ is
something we must foster for any SaaS implementation regardless of the MT concept. The rules for
the application code to support system from tenant isolation are very similar to achieve the separation
between tenants, what are “must haves” to fulfill the customer requirement of “isolation”.
With the introduction of the delivery models of the “managed cloud” and “OnPremise” shipment of
S/4HANA product variants also the OnPremise lifecycle management methodology, tools and
processes must be supported as well – at least in the early product version until we extended the
validity of the “public cloud” procedures to the other delivery types. In the classical ERP systems
essential procedures make use of multiple clients. They are a fact that to be supported without
compromises. Also we make use of multiple (application) clients in public cloud installations e.g. for
trial systems where strict isolation requirements are relaxed.
The following rules are motivated for 2 reasons:

© Copyright SAP SE 2017 Internal/Confidential Page 34 of 100

Architecture Guideline S/4HANA

1. Guide new development or bigger changes planned in existing areas towards an

architecture which will ease the potential later to be established „true multi-tenant
application based on a multi-tenant app server“
2. Guide efficient IT provisioning, for which we must implement the mentioned „separation of
concern between business users and provider IT“
Rules only motivated by (1) are phrased as “should”, because they only apply for “new” parts in the
stack, while rules which are motivated by (2) very often are phrased as “shall”.
[C-MT-1] Shall: Ensure that administrators do not have access to any application data
Explanation:
Assume that all system administrators are logging in into a system via a user account in a dedicated
ABAP client – let´s say “011” – while the customer uses the client “002” for productive use. The
transactions available to the system administrator only provide access to data in client “011” and into
tables which are not client dependent.
It must be assured that neither customer data is visible nor can be changed from the system
administration client.
Remark: This means of course that the system administrator does not have access to development
tools which allow access to all part of the system.
As a rule of thumb it is assumed that application code does not have a need to write any application
data into system tables, neither transactional data nor configuration data. Of course within one
transaction changes to application (client dependent) tables implemented in application code may be
mixed with changes to system tables implemented in system code. Due to the fact that this difference
between system code and application code is not sharply defined e.g. by the ABAP language this can
only be a rule of the thumb.

[C-MT-2] Shall: Business application code should not be dependent on system configuration
System configuration defines system behavior which is by nature independent of any customer choice
or decision.
The default is that the business application code does not depend (directly) on any system
configuration. Therefore all customizing tables of the application code should be client dependent.
There are some allowed exceptions to this general rule:
1. Reading of system configuration defined and managed by system coding is allowed, but
should be used thoroughly.
2. In cases where a business component delivers out of one code line to Models S and also
into On Premise ERP the behavior might depend on the system type (Models S or on
Premise). To manage to different behavior definition of system configuration is allowed. For
that purpose a central ‘System Type Switch’ CL_SYS_TYPE_????` (To be implemented)
will be provided.
System configuration should deliver in SaaS-environments together with the coding as part of the
software change process. For Models S all systems (of the same version) will have the identical
system configuration concerning the application behavior.
[OC-MT-3] Should: Eliminate “cross client data access” in business applications
For business application code there is no valid use case known where data from more than one
application clients (potential tenants) should be processed in one transaction. The processing of data
belonging to different ABAP-clients is strictly forbidden with the exception of the involvement of client
“000”.
The ABAP client “000” is used as the “delivery client”. Some applications therefore may read the
system default configuration from client “000” while the tenant specifics are persisted in same table
but in the appropriate ABAP client. Here we recommend for every new implementation to use a client
independent table of delivery class “S” for shipping the system default and merge the effective value
during read with a value from an ABAP client dependent table of delivery class “C”

© Copyright SAP SE 2017 Internal/Confidential Page 35 of 100

Architecture Guideline S/4HANA

Copy procedures as part of the business applications, like they are present in the OP suite stack,
where data is copied from one (business) client into a different (business) client are not allowed. If
there is a need for a cross tenant data copy use replication techniques of other allowed data move
approaches. Even for the OP suite we recommend to eliminate this cross client data copy procedures
– you may use “remote copy” patterns which ensures that permissions for reading and writing of the
2 users (the sender user and the receiver user) are implemented.

© Copyright SAP SE 2017 Internal/Confidential Page 36 of 100

Architecture Guideline S/4HANA

5.3.1 The ABAP Cloud Platform and S/4HANA Cloud Multitenancy Concept
Multitenancy in S/4HANA Cloud is implemented by using HANA Multitenant Database Containers,
introducing a Shared Container for tenant - independent data, thus reducing the RAM footprint for
Tenant Containers.
To reduce tenant footprint, and to allow optimizations of software change management procedures,
so called “Shared Containers” are used which are holding common data (software and configuration
artifacts) shared by all tenants.
A set of ABAP “Runtime Containers” sharing the same software version for the entire software stack
is called a “Runtime Cluster” if they all share the same Shared Container. Each Runtime Container
can have one or multiple ABAP Application Server instances. These instances are dedicated to
specific tenants. Of course, Runtime Containers from different tenants can share hardware, e.g. via
server virtualization.
A multitenant HANA System is used per Runtime Cluster, with a dedicated HANA Container per
tenant and a single Shared HANA Container. Changes of table content in the Shared HANA Container
are done by software change management tools, performed only as part of release upgrade and
patching procedures. The ABAP Platform Data Dictionary manages the structure of shared tables
with tenant-local content and SQL union views (see next section) in cooperation with software change
management tools.

The main benefits of that approach are the following

 There is a strong isolation of tenant runtime and data
 Flexible tenant management is already supported by HANA (move, scale,
start/stop, backup & restore)
 Hardware is shared which allows reuse of underutilized hardware
 There is a high degree of compatibility to existing ABAP and native HANA
applications so that adoption effort is very small.
 Reduction of HANA footprint by sharing of artifacts identical for all tenants

You will find more information about the MT concept in the Wiki of the WhiteBird MT and Resource
Sharing Workstream.

© Copyright SAP SE 2017 Internal/Confidential Page 37 of 100

Architecture Guideline S/4HANA

The "Sharing" concept of ABAP Platform Cloud and S/4HANA Cloud (1711 onwards)
When speaking of "sharing" in the S/4HANA cloud environment, it means to deliver SAP owned
artifacts, code and table content, just once for a large set of customer "tenants". This set of SAP
owned shared artifacts, the "shared container", is used by many tenants and therefore must be read-
only from the tenant perspective. Content of the shared container in consequence can only be
modified by software updates, for example patches of upgrades. Any attempt to write a "shared
object" from the tenant results in a dump.

Consequently, any code generating program that creates or modifies programs, function modules,
interfaces, classes and the like based on customer configuration cannot produce "shared content",
but must write into the respective tenant container only. For this purpose we must distinguish "shared
content" and the "tenant specific" complement. This is based on the object catalog (TADIR) attribute
"GENFLAG" which indicates a generated object. Any object listed in the object catalog with an initial
(space) GENFLAG is a sharable object and will be stored in the shared container, thus cannot be
modified from an application.

This leads to the following rules:

[C-MT-4] IF a generated object has a TADIR entry AND can be (re-)generated in a cloud tenant
context THEN this TADIR entry must be generated with TADIR-GENFLAG <> space.
Remarks:
1. Whether TADIR-GENFLAG has to be set to 'X' or 'T' (which are currently, June 2017, the
only supported values beside space) is dependent on the generating scenario, see F1-
documentation of TADIR-GENFLAG.
2. This refers to code generation in tenant containers only; any "design time generation" of
objects which are then transported ‘normally’ (just as any other development object) is not
concerned.
3. No issue are also generated objects without TADIR entry and those located in software
component LOCAL respective package $TMP as these will never be shared.
4. Find more details in wiki Correct code generation programs for shared cloud usage.
See also the General Generation Guidelines [C-GEN-1] in section 5.16.
[C-MT-5] Write accesses to REPOSRC in tenant containers are generally limited to:
• sources that belong to the tenant (i.e. within namerange Z*, Y*; generated sources with
TADIR-GENFLAG <> space, see C-MT-4; sources in software component LOCAL like
objects in package $TMP; sources without TADIR entry)
• administrative fields of sources which do not belong to the tenant. Administrative fields are
the columns UNAM, UDAT, UTIME, IDATE, ITIME, SDATE and STIME ( “last change to
this source”-like fields and “last overall change to this program”-like fields).
Remarks:
1. Any write attempt beyond this limitation will result in a runtime error (in systems which are
setup as multitenancy systems).
2. Find more details in wiki Adoption to REPOSRC sharing.
[C-MT-6] Ensure that the Package Classification is done correctly.
All tables which belong to (development) packages which are classified as 'O' or 'D' (Package is only
relevant for S/4HANA On Premise or Deprecated) are seen as not relevant for the Cloud. In the Cloud
such tables will be moved to the Shared Containers and by this the corresponding memory is saved
in the Tenant Containers. It is important to know that tables in the Shared Containers are set to Read-
Only mode! Application programs cannot change the contents of this tables anymore (it is however
possible to move such tablea back to the tenant containers, if required, see remarks below)! It is
therefore important that the package classification is done properly!

Remarks:

© Copyright SAP SE 2017 Internal/Confidential Page 38 of 100

Architecture Guideline S/4HANA

1. Package classification is stored in table TDEVC in column PACKTYPE

2. There are the following values for PACKTYPE:

• C: Package is relevant for S/4HANA Cloud

• D: Package is a deprecated package
• H: Package is a HOME package
• O: Package is only relevant for S/4HANA On Premise

3. Moving a table into and out of the Shard Container is not possible in Extraordinary Patches
but only within Hotfix Collections and Upgrades.
4. Report CALCULATE_STACK (Transaction FSCS) can be used to verify the package
classification for a whole bunch/set of packages at once.
5. In the following excel we are providing up-to-date tracing information from systems CC2
and CCF about all Write Accesses to OnPremOnly tables. Such write accesses can be an
indication that the respective tables are used in cloud relevant business scenarios! The
more different users access the table and the more often a table is accessed the stronger is
the indication that it is relevant for the cloud: WriteAccessToOnPremOnlyTables.xlsx
6. In case of wrong package classifications, send the packages to be changed to
[email protected]

5.4 Ensuring S/4HANA Cloud Environment

“Public Cloud” isn’t a well-defined technical term, but existing offerings like Success Factors, Sales
Force, Work Day, NetSuite set de facto standards what Public Cloud means from a customer
perspective (please refer to the following picture):

© Copyright SAP SE 2017 Internal/Confidential Page 39 of 100

Architecture Guideline S/4HANA

Figure 5-1: Overview of Cloud Qualities

Based on the above list of cloud characteristics and the cloud qualities derived out of the same the
following “Do’s and Don’ts” transformed in Rules shall be taken into account by development.
Note: This is not a general “Developer Guideline” but focus on aspects only which are of special
importance in a public cloud environment.

[OC-PC-1] In general avoid everything which makes the operation of the system expensive
(system provisioning, monitoring, patching and upgrade)
[OC-PC-2] Do not introduce new functionality which requires monitoring activities by the cloud
provider. If a new functionality requires monitoring, you shall deliver an automatic
health check (to be checked with Karolin Laicher) and a recommended action for
the operators. It is essential that such check creates incidents in SPC without the
need for manual checks in the backend
[C-PC-3] Technical configuration  it shall be possible to make a system copy if new
functionality is implemented. Therefore it is forbidden to use SIDs, hostnames, etc.
in any configuration
[OC-PC-4] Avoid system complexity (i.e. additional server, central components, etc.)
[C-PC-5] Functionality shall be 100% web consumable – it is forbidden to develop or use
functionality which requires a VPN connection to the customer
[OC-PC-6] Upgrade shall run fast, secure and automated. XPRA’s during patching or upgrade
and incompatible DDIC changes are forbidden
[OC-PC-7] Manual post processing after patches, updates or upgrades shall be avoided
[C-PC-8] New functionality shall not be shipped with by-weekly patching
[OC-PC-9] New functionality shall be 100% compatible to the previous release – especially
important for hybrid and integration scenarios which require stable interfaces for
several releases and different software stacks/products
[OC-PC-10] New configuration and pre-delivered content for new functionality (or existing one)
shall be provided along with the code. Newly developed configuration Fiori apps
shall be assigned to the pre-delivered role content in a segregation of duty compliant
way.
[OC-PC-11] New Innovation or new functionality shall be delivered inactive. The customer shall
be able to decide whether to use it or not. The activation shall be done by
configuration Fiori apps for cloud key users.

5.5 Changes in Data Models

For sure, we expect - following the simplification and “Principle of ONE” guidance - that existing data
models will be changed. Those changes are being tracked through the mechanisms of the semantic
compatibility. Nevertheless every development project shall make planned changes transparent
beforehand providing at least an Architectural Concept Document (ACD).
[OC-APP-6] Every development project aiming to change the S/4HANA data model derived from
Business Suite on HANA shall make those changes transparent
[OC-APP-7] Any change of the S/4HANA data model based on OMP-APP-6 also contains the
necessary adjustments of conducted external interfaces as well as smooth
migration rules and mechanisms. This is covered by the responsibility of the
initiating product owner.

© Copyright SAP SE 2017 Internal/Confidential Page 40 of 100

Architecture Guideline S/4HANA

5.6 Changes in User Interfaces

[OC-APP-9] All End User relevant changes in user interfaces - as long as they are not mandatory
to ensure data and process integrity - shall be defaulted as SWITCHED OFF inside
the business configuration and/or scoping environment. Concerning Business
Application Configuration please refer to Chapter 5.10.

© Copyright SAP SE 2017 Internal/Confidential Page 41 of 100

Architecture Guideline S/4HANA

5.7 Deleting Repository Objects

Even if S/4HANA is a ‘new’ codeline, the basis was selected software components out of ERP EHP7.

Figure 5-2: Stack Evolution – Creation of S/4HANA Core

To ensure that initially excluded software components which may be added to the S/4HANA stack at
a later point in time are able to be prepared for such a deployment, we have to ensure, that every
ABAP repository object which has be transferred from the SoH Stack to the S/4HANA Stack and were
a deletion is intended, takes part within the general deprecation process which is explained here.

[OC-APP-8] Any deletion of former ERP EHP7 Repository Objects shall be processed via the
general Deprecation Execution.

© Copyright SAP SE 2017 Internal/Confidential Page 42 of 100

Architecture Guideline S/4HANA

5.8 Tables classification, delivery class and buffering

In the core definition of S/4HANA we were able to reduce the number of transparent tables from
~81,000 down to ~16,000. This is a reasonable number where we have to re-evaluate all settings as
table classification, delivery class, data class and buffering.

Figure 5-2: Stack Evolution – Creation of S/4HANA Core

5.9 Ensuring Testability of S/4HANA

Reliable and cost efficient regression testing is a must when developing and running cloud software
to keep quality high and costs low. A dense safety net of automated tests is required to safeguard all
critical functionality of S/4 Cloud and OP (following the “Cloud First” strategy also for test code).
Therefore also cross topics described in the following chapters of this document have to ensure that
the respective capabilities of S/4HANA can be tested automatically. This is true for the functional
correctness but also for all other software properties where test automation can be used (e.g. security,
performance). All chapters of this document have to give advice how test automation can be achieved
for each cross topic. Details have to be worked out in the Architecture Concept Documents (ACD) or
other documents. The following rules to ensure test automation have to be recognized:
[OC-TA-1] New or touched code shall have statement coverage of > 50% by automated tests
[OC-TA-2] Critical changes in existing code shall have automated tests following a risk based
approach
[OC-TA-3] All OData services shall have automated tests which ensure formal and functional
correctness
[OC-TA-4] All bug fixes triggered by customer messages shall be safeguarded by automated
tests
[OC-TA-5] ABAP Unit tests have to be created as close to the tested code (SUT) as possible.
For ABAP the same package/class is the preferred way. For exceptional cases (e.g.
integration like tests, critical tests) the following new software components shall be
used (do not create these kinds of tests in HOME):
SAPOCORE_H: OP relevant only
SAPPCORE_H: Cloud & OP relevant

© Copyright SAP SE 2017 Internal/Confidential Page 43 of 100

Architecture Guideline S/4HANA

5.10 Configuration for Applications

All definitions and rules for predefined configuration content, configuration methodology and Fiori
based cloud user configurations can be found in following WIKI:
https://wiki.wdf.sap.corp/wiki//x/Zb3bXw

5.11 Security for Applications provided in the Cloud

All definitions, rules and restrictions for software security relevant topics can be found in following
WIKI:
https://wiki.wdf.sap.corp/wiki/display/SimplSuite/Security

5.12 Central System Settings

5.12.1 Time Zone
The time zone for all systems of S/4HANA independent from its location (data center) will be set to
UTC (Universal Time Coordinate).
[OC-CSC-1] All applications have to ensure that for customer/tenant local behavior of different
time zones the local date and local time has to be calculated and displayed
accordingly via SY-DATLO and SY-TIMLO.
[C-CSC-2] When creating a new tenant for S/4HANA Cloud table TTZCU (Customizing time
zones) has to be defined concerning field TZONESYS always with UTC for all clients
of the tenant.
[C-CSC-3] All client dependent entries of table TTZCU has to be defined concerning field
TZONEDEF according the business relevant time zone for the tenant which shall
be evaluated during the onboarding process.

Here is an example for a customer in EMEA:

5.12.2 SET UPDATE TASK LOCAL

The update behavior for all systems for the S/4HANA CLOUD has been centrally changed to disable
any V1 UPDATE TASK posting mechanism.
Therefore each cloud system will be setup by setting the ABAP Parameter
abap/force_local_update_task to 1 (default 0).

© Copyright SAP SE 2017 Internal/Confidential Page 44 of 100

Architecture Guideline S/4HANA

[C-CSC-2] Applications do not need to change the code to obtain a local update task as this is
being done centrally. In addition, the statement ‘CALL FUNCTION <XYZ> IN
UPDATE TASK shall not be changed to ensure data integrity for all such function
module calls keeping them in the same Logical Unit of Work (LUW).

Figure 5-3: Central Change of Update Behavior in Backend

With this definition we are only able to influence the so called V1 posting. We still have plenty of V2
and V3 posting calls were the initial assumption is, that these postings contain redundant data for
secondary persistencies
[OC-CSC-3] V2, V3 Posting shall be reviewed according their potential to create redundant data,
questioned and disabled
The update behavior for all systems for the S/4HANA OnPremise has not been changed overall. For
modifying OData services it is strongly recommended that modifications are done using a local update
task to prevent issues with subsequent GET-requests (HTTP 404).
To ensure a local update task the statement can be set in any modifying method or alternatively in
the following central methods:
• CONSTRUCTOR
• /IWBEP/IF_MGW_APPL_SRV_RUNTIME~CHANGESET_BEGIN
• /IWBEP/IF_MGW_SOST_SRV_RUNTIME->OPERATION_START (if soft state
can be activated for a service)
[O-CSC-4] Applications need to adapt the code to obtain a local update task for modifying
OData services if not done so far. In addition, the statement ‘CALL FUNCTION
<XYZ> IN UPDATE TASK shall not be changed to ensure data integrity for all such
function module calls keeping them in the same Logical Unit of Work (LUW).

5.12.3 Differentiation between Deployment Options

In order to help applications to differentiate between these deployment options the following
mechanisms have been implemented
• A Business Function SIMPLIFY_PUBLIC_CLOUD, available from NW 7.40 SP10 and 7.60
SP00 onwards which will always and only be active in Cloud Systems.
• A Business Function SIMPLIFY_ON_PREMISE, available from NW 7.50 SP00 and 7.60
onwards which will always and only be active in On Premise systems.
• These Business Functions are set system-wide, not per client!
• In addition in class CL_COS_UTILITIES methods are available to check the activation
status of these Business Functions

© Copyright SAP SE 2017 Internal/Confidential Page 45 of 100

Architecture Guideline S/4HANA

o IS_S4H
▪ True, if SIMPLIFY_PUBLIC_CLOUD or SIMPLIFY_ON_PREMISE is
active.
o IS_S4H_CLOUD
▪ True, if SIMPLIFY_PUBLIC_CLOUD is active
o IS_S4H_PUBLIC_CLOUD
▪ True, if SIMPLIFY_PUBLIC_CLOUD is active.
o IS_S4H_ON_PREMISE
▪ True, if SIMPLIFY_ON_PREMISE is active.
o When using these methods, do only a positive check / check only against return
value true. Because if any of the methods returns false, this could mean different
things.
The following rules apply for using these mechanisms:
[OC-DO-1] In case no different behavior between deployment options is required, none of these
mechanisms must be applied.
[OC-DO-2] In case different behavior between deployment options is required which can be
achieved by other measures described in the architecture guideline, these other
measure shall take precedence over usage of the business functions. Specifically
this means
• Where the deployment specific behavior can be achieved by pure
configuration, this shall be handled via pre-delivered content (SaKP
content)
• On level of Transactions & WebDynpro Applications it will be ensured via
the IAM concept that customers can only see can access functionality
which is explicitly whitelisted Cloud.
[OC-DO-3] In case different behavior between the deployment options is required, which
cannot be achieved by other means this shall be achieved by either assigning own
Switches to one or more of these three Business Functions and putting the
respective functionality behind these Switches (preferred) or by a code switch
checking the status of the Business Functions via the provided methods. Any usage
of the central Business Functions is subject to approval (get in contact with Markus
Goebel) and is to be documented at
https://wiki.wdf.sap.corp/wiki/display/SimplSuite/Usage+Governance+of+Central+S
4H+Switches
[OC-DO-4] For functionality which is assigned to existing Business Functions introduced in the
past via an Enhancement Package, the Business Function assignment shall not be
changed. Here the existing Business Functions shall be kept and are subject to the
rules described in chapter 5.12.4.

5.12.4 Deleting exceeded log entries from SBAL

Applications using the central application are forced to ensure that an expiration date is being set
according to legal and/or application relevant conditions. The respective field inside the Application
Log Interface is ‘Expiration Date’ [ALDATE_DEL].
[C-BF-8] For S/4H Cloud the cleansing job [SAP_REORG_APPLLOG] shall be set up
periodically to delete all log entries where the ‘Expiration Date’ [ALDATE_DEL] is
exceeded.

5.13 Optimistic Concurrency Control

In many cases the state of an object or better the fact whether it has changed since the last access
is needed. This is highly relevant for S/4HANA in the context of FIORI apps .Example are
• the HTTP ETag handling (see https://de.wikipedia.org/wiki/HTTP_ETag) to support optimistic
locking in scenarios with stateless consumption and

© Copyright SAP SE 2017 Internal/Confidential Page 46 of 100

Architecture Guideline S/4HANA

• draft handling to detect whether an edit draft document still fits to the related active document
or is outdated.

The calculation of this information depends on the capabilities of an application and might be quite
expensive from a calculation as well as a data transfer point of view by getting much data from the
database. Further the calculation approach might not be sufficient and wrong implementation needs
to be prevented. A last changed data and time is not sufficient if it is only on the accuracy “second”.
As potential conflicts are quite low the application can mitigate it by ensuring a unique update time,
e.g. by adding a second in case of a conflict with sub-second updates. The same applies for a long
timestamp with even less probability due to not synchronized application server clocks where
uniqueness needs to be ensured by adding a unit in case of a conflict (i.e. a resulting identical
timestamp during an update). Change documents are not sufficient and even not reliable as the
customer could deactivate them completely and not all changes are recorded via change documents.
Last not least a document hash of the complete document is an approach often chosen. As a fallback
this is ok, but from a performance point of view this is not the best approach and it might get critical
when (node-) enhancements are added. So the only reliable approach is a timestamp, a UUID or a
document version set on each change. If none of these is available the introduction of a timestamp is
the recommended approach.

[OC-APP-10] To support optimistic concurrency control applications shall provide a reliable

timestamp that is updated with every change on granularity of a business object or business object
nodes if these are lockable separately. When writing the timestamp potential conflicts with identical
(or earlier) timestamps have to be mitigated by using the existing timestamp and adding a unit.

5.14 ABAP Domain Conversion Routines

Conversion routines (conversion exits) are used to provide input and output conversion on field level
(mainly for UI consumption and the end user). Due to the pushdown of functionality in our FIORI UIs
from OData directly to SQL like sorting and filtering these functions are applied to the internal
representation of the field values. Depending on the implementation of the conversion routine this
could lead to various issues.
The sorting might not be understandable by the user anymore (as the lexicographic order might
change due to the conversion).
The filtering might not be understandable by the user especially for free text search, “type ahead” or
pattern-filters with filter conditions “contains” or “starts with” as in this case the conversion may not
be applied to the search term.
Further issue arise if the conversion routine is also used for input conversion and the internal
representation is shorter than the external representation. In this case a wrongly entered value might
not be convertible and due to the higher length the unconverted value cannot be stored as such in a
draft document.
[OC-APP-11] For FIORI apps do not use data elements and domains with conversion exits if possible.
Verify the purpose of these conversion exits and if it still applies in the FIORI app or can be solved
differently.
Especially pure UI onversions (i.e. conversions that are not used for the same purpose in an API)
shall not be used for OData services, but UI formatters shall be used as these are supreme for this
purpose.
[OC-APP-12] If a conversion routine is still needed in a FIORI app and the conversion can be
expressed via join to a conversion database table (usually of delivery class S, E, C, or G) define a
CDS view for this conversion table and add a corresponding association from the relevant CDS views.
Add the external representation field evaluating the association on consumption level as read-only
field. Use the field with the external representation for sorting and filtering and the field with the
conversion for data entry.
[OC-APP-13] If a conversion routine is still needed in a FIORI app and the conversion can be
expressed via means of CDS as a calculated field model the external representation as calculated
field on basic view or consumption view level as read-only field. Use the field with the external

© Copyright SAP SE 2017 Internal/Confidential Page 47 of 100

Architecture Guideline S/4HANA

representation for sorting and filtering and the field with the conversion for data entry. To ensure no
negative performance impact implement reverse exits (e.g. in SADL) for filtering and sorting if possible
to delegate these operations to the original field again instead of the calculated ones.
[OC-APP-14] If a conversion routine is still needed in a FIORI app and the conversion is complex or
contains customer exits check if the external representation can be stored in addition to enable [OC-
APP-12]. If this is not possible check the impact of the conversion with regard to the unsupported
features and ensure these features are not used (e.g. “not filterable”) or make the impact transparent
in the documentation of the app.

5.15 Database Table Layout

When creating new business objects and related persistence and database tables you should take
into account to optimize the database layout for the main usage.
Usual layout is a (composed) semantic key where dependent entities share the key of their parent
and introduce an additional key field (that is unique only in the context of the further key fields derived
from the parent entity).
Some application (e.g. BOPF-based applications, but also other) have a technical ID (usually UUID)
as primary key. For these scenarios you have to take the following considerations into account.
First, as the analytical consumption (via analytical engine) is not capable to understand a tripel of
UUID, Semantic ID and Text / Description a UUID-based model does not really fit analytical
consumption with regard to the generic functionality. Thus the analytical consumption model has to
provide views that follow the semantic model which leads to additional JOINs in the consumption
views to provide the full key accordingly.
Second, in case of a unique technical ID on every entity the field which establishes the link of sub-
entity to its parent is not necessarily a key field on the sub-entity (as its technical ID is globally unique
and not only in the context of the parent entity and parent technical ID). However if the key of an entity
does not contain the key of its root entity, scale out and partitioning in HANA cannot be defined in
such a way, that all entity instances of one “business object instance” (e.g. sales order header and
sales order item instances) are located in the same partition. This prevents technical optimizations.
Therefore in such data models at least the technical ID of the root entity shall be defined as an
additional key field in all related sub-entities.
[OC-APP-15] If an application uses unique technical IDs for its data model and persistence model
the technical ID of the business object root entity shall be provided as additional key field (even if not
necessary from a uniqueness point of view) to ensure scale out and partitioning scenarios in HANA.

5.16 Generating of Development Objects / Source Code Generators

Generating of Development Objects or Source Code Generation is the generation of the respective
artifacts at runtime in customers systems. "Design time generation" of objects which are then
transported and handled ‘normally’ (just as any other development object) and are not re-generated
in customer systems is not concerned here.

Ensure that generating of development objects is only done if really required and that it cannot be
avoided at all. Cloud systems, especially those utilizing multi tenancy, are meant to support volume
business; and volume business partly contradicts individual generation of development artifacts...

IF generating of development objects is required and cannot be avoided the following shall be
considered:

[C-GEN-1] General Generation Guidelines:

1. If a generated object has a TADIR entry, the TADIR-GENFLAG must be set

according to rule [C-MT-4], which you will find in section 5.3.1.

© Copyright SAP SE 2017 Internal/Confidential Page 48 of 100

Architecture Guideline S/4HANA

2. Strictly separate generated artifacts from design time artifacts (by name or
namespace), e.g. do not generate includes into a function group delivered by SAP.
3. Best make sure that generated artifacts are NEVER delivered to customers but are
generated in customer systems only/directly. This can for example be achieved by
generating into package $TMP
4. Generate only into dedicated namespaces, which are not used for object delivery,
but only for generation. Best Practice is to use dedicated development namespaces
that begin with /1 for code generation.
5. Always ensure that the generator scenario ‘detects’ when the generator should run
and (re-)generate its generated objects. Do not rely solely on lifecycle management
processes to save generated objects during upgrade.

5.17 Object Types and Unique IDs

There are many use cases where object types are needed. Examples are the generic referencing of
any objects, the use of reuse components that store data for and as part of another object (like
attachment, notes, etc.) or the generic consumption of objects (like the OpenText integration,
business events, workflow or situations). To achieve a better harmonization especially for newly
introduced reuse components (like the new notes component) or consumption frameworks (like
situations) and to prevent introducing even more proprietary code lists of object types we have
introduced the SAP object type as central object type definition as well as the SAP object node type.
Every object that wants to make use of certain new reuse components or other users that rely on this
object type definition has to introduce the required SAP object types or SAP object node types.
Usually (as seen in the exampled given before) the relation and usage is on instance level. Thus also
an identification of instances of object types or object node types is needed in addition. If possible the
readable semantic identification (primary key of the database or basic CDS view representative) is
used (especially for external integration like OpenText). This is also the general rule for external
communication to used the semantic (readable) key fields. In very specific cases (e.g. referencing
different object types in heterogeneous lists) a readable ID has to be exposed externally as a read-
only information. This field (of type STRING) is a concatenation of the semantic key fields separated
by “/” without spaces, e.g. “4711/10/10”. Especially output conversions for each single field are
invoked before the concatenation takes place.
In many cases a single identification field is used to simplify the consuming framework or reuse
component and the application has to provide such an identification. For object nodes with single key
or UUID-based object nodes this works out of the box. In other cases sometimes UUIDs are
introduced, but usually the relevant key fields are concatenated somehow. The latter is also the
recommendation if already such integrations exist, but also for newly introduced keys due to the better
readability e.g. in debugging.
To leverage this information the object type and the identification has to be exposed. This is done in
the relevant CDS views (usually a #BASIC VDM view) where the object type is annotated via
@ObjectModel.semanticObject and the unique identification field is annotated via
@ObjectModel.uniqueIdField. If no single identification field exists a dedicated field has to be
introduce (usually with name suffix UniqueID). As even for a simple concatenation the CDS
functionality is not sufficient the only way to introduce such a field today is by explicitly calculating the
field within the application code and storing it in the application table. The introduction of such a field
is also reasonable for performance reasons if the application data shall be JOINed with the reuse
component data.
[OC-APP-16] For every SAP object type or SAP object node type there shall be a related CDS view
that provides a unique identification field that is indicated via annotation @ObjectModel.uniqueIdField.
Remark: Obviously the unique identification needs to identify a single record of the view, i.e. a read
access with only this field should return at maximum one record. This implies that for time-dependent
entities that have no time-independent entity (e.g. cost center) such a CDS view has to be introduced.

© Copyright SAP SE 2017 Internal/Confidential Page 49 of 100

Architecture Guideline S/4HANA

5.18 Forbidden and Unwanted Statements

5.18.1 Forbidden Statements
Usually in S/4HANA existing code is used for any consumption that previously was developed for a
SAPGui application. Other consumption channels are API-consumption e.g. BAPIs, SOAP web
services or OData services, but also UI-consumption via WebDynpro. Obviously any SAPGui-specific
statement is not allowed to be processed and in most cases also leads to a dump (e.g.
DYNPRO_SENT_IN_BACKGROUND). Nevertheless these can be seen daily in our S/4HANA
development systems.
[OC-APP-17] ABAP source code that does not run in a SAPGui environment shall not process any
SAPGui-specific statement and has to be adapted accordingly.
The following statements are not allowed to be processed in detail:
CALL TRANSACTION (without USING), SUBMIT, REPORT, MODULE, CALL SCREEN, MESSAGE
(without INTO), CALL SELECTION-SCREEN, SELECTION-SCREEN, PARAMETERS, SELECT-
OPTIONS, WRITE (without INTO), FORMAT, ULINE, SET BLANK LINES, SKIP, NEW-LINE, BACK,
POSITION, SET LEFT SCROLL-BOUNDARY, NEW-PAGE, RESERVE, HIDE, SET MARGIN,
PRINT-CONTROL, READ LINE, READ CURRENT LINE, MODIFY LINE, MODIFY CURRENT LINE,
SCROLL LIST, DESCRIBE LIST, LEAVE TO LIST-PROCESSING, LEAVE LIST-PROCESSING,
WINDOW, SET PF-STATUS, GET PF-STATUS, SET TITLEBAR, SUPPRESS DIALOG, LOOP AT
SCREEN, MODIFY SCREEN, SET CURSOR, GET CURSOR, CONTROLS, REFRESH CONTROL,
EXIT FROM STEP-LOOP, SET HOLD DATA, SET SCREEN, LEAVE SCREEN, LEAVE TO
SCREEN.
While the previous list of statements leads to a dump in most cases or does no harm to the system
the second type of forbidden statements is in the context of APIs where the change and COMMIT-
control is on consumer side. This is the case for BAPIs as well as for non-changing SOAP- or OData-
APIs. In this context any changing operations are not allowed.
In any case logging or writing of traces etc. can be done via a secondary database connection and a
database commit.
[OC-APP-18] ABAP source code that runs as part of an API where the transaction (i.e. the COMMIT)
is controlled by the consumer (e.g. BAPIs) shall not process any COMMIT WORK or ROLLBACK
WORK.
The rule implies that also no secondary logical units of work (e.g. via CALL FUNCTION STARTING
NEW TASK or similar) shall be started as part of the API-call. During COMMIT WORK this might be
allowed. Another allowed example is the usage of a ROLLBACK WORK inside a Gateway OData
implementation if the change set is implemented by the application. This is conform to the rule above
as in this specific case the transaction control for the rollback is with the application and not with the
consumer (i.e. Gateway in this example).
[OC-APP-19] ABAP source code that runs as part of an read-only API shall not process any changing
operations.
The following statements are not allowed to be processed in detail:
COMMIT WORK, ROLLBACK WORK, CALL FUNCTION STARTING NEW TASK, CALL FUNCTION
IN BACKGROUND TASK, CALL FUNCTION IN UPDATE TASK, CALL FUNCTION DESTINATION,
OPEN DATASET, TRANSFER, READ DATASET, GET DATASET, SET DATASET, TRUNCATE
DATASET, CLOSE DATASET, DELETE DATASET.

5.18.2 Unwanted Statements

Beside forbidden statements that cause real issues there are further statements that might lead to
issues depending on their usages outside of a SAPGui environment and thus have to be reviewed
and adapted or removed.
CALL DIALOG processes GUI-related application code, but within the same memory area and logical
unit of work. Therefore in general this could work, but should be avoided and reworked if possible. A

© Copyright SAP SE 2017 Internal/Confidential Page 50 of 100

Architecture Guideline S/4HANA

transaction started with CALL TRANSACTION USING runs in an own logical unit of work so no
complete rollback is possible afterwards.
[OC-APP-20] ABAP source code that runs not in a SAPGui environment shall check and adapt or
remove the usage of CALL DIALOG and CALL TRANSACTION USING. Especially the required
addition WITH or WITHOUT AUTHORITY-CHECK of CALL TRANSACTION shall be explicitly added
if the statement is not removed.
Further in the special context of draft handling and OData-services the usage of PERFORM ON
COMMIT and PERFORM ON ROLLBACK is critical and has to be reviewed. If within draft processing
existing code is called that works with these statements the application needs to be prepared that to
store the draft data a COMMIT WORK is always done by the infrastructure. Therefore ideally these
statements are not used or it is ensured that the right things are done. Especially if multiple logical
units are spanned within one OData request ($batch with multiple change sets) the application cannot
rely on the fact that the ABAP session is closed after a COMMIT WORK. The same is true if the
Gateway soft state is used (while this has to be enabled actively). Further even if the code running
during PERFORM ON COMMIT does the right thing the application has to verify whether further
requests within the same ABAP session register the required PERFORM ON COMMIT routines
again.
[OC-APP-21] ABAP source code that is called during draft processing shall avoid using PERFORM
ON COMMIT and PERFORM ON ROLLBACK. If these statements are used the application has to
ensure that the overall application works as expected.

© Copyright SAP SE 2017 Internal/Confidential Page 51 of 100

Architecture Guideline S/4HANA

6 Performance
By removing aggregates and indexes and by using one Data Model for OLTP and Analytics one major
goal of S/4HANA with respect to performance is to reduce the memory footprint and to increase the
throughput. At the same time we want to improve user experience by offering Fiori UIs consuming
stateless OData services based on a Business Objects Modell exposed via CDS views.
This Programming model together with the fact that we have to reuse big parts of the business logic
code gives us some challenges with respect to performance. In the following chapter it is described
what we have to consider to meet the expectations with respect to the main performance
characteristics:

• E2E user response time

• Resource consumption
• Throughput and scalability

6.1 E2E User Response Time

One major aspect of good user experience is a responsive UI. This means we have to respond to a
request or interaction triggered by a user (on any supported device) in a way that continuous non-
disruptive working is possible everywhere. This puts same clear KPIs to our delivery:

• User interactions where immediate response is expected we shall not wait for a
synchronous request from the backend to return because typical network times in WAN
may already exceed expectation (< 200 ms)
o Typing
o Tapping to another field
o Static drop down list boxes
o …
This does not mean that we may not send or request data from the backend triggered by
such interaction but we cannot hinder the user continuing with his work. You should consider
carefully which level of “total consistency” is needed for each user interaction. For example
entering multiple line items tabbing from field to field should normally not interrupt the user
until the Business Object has executed all determinations and validations to be ready for save
after each field input! (See also draft architecture and resource consumption below)
• For a typical user interaction where data from the backend is needed to continue to work we
have to ensure sub-second response time. As a rule of thumb this translates to KPIs for
the client for network and for the backend:
o 350 ms rendering time on the client
o 300 ms network delivery time
o 350 ms backend execution time (including gateway and application)
To ensure not to exceed network time our goal is to have only one (exceptionally two)
synchronous http request to the backend (per user interaction) and only moderate data
exchange (~10 KB of business data after compression). From this we can derive some simple
rules which have to be applied:
o Enable consumption of CDN (Content Delivery Network) including device cache
(browser, mobile apps …) for Metadata and Code lists (static dropdown list) to
minimize access times to static content
o Bundle data request of different aspects form one BO (respectively CDS view) into one
OData request
o Bundling of data request belonging to different BOs (CDS views) by batching them in
one OData request
o Only request data which is shown to the user (resp. which are needed for
computation on the client).
▪ This means you have to restrict the selected field to the minimal set which is
needed for the current screen
▪ You have to enable paging for all mass data retrieval in lists and in other
hierarchies

© Copyright SAP SE 2017 Internal/Confidential Page 52 of 100

Architecture Guideline S/4HANA

As we talk about elapsed time at this point parallelization may help on all levels:
o Parallel requests from the client to the backend
o Parallel request from gateway to application
o Parallel execution of DB request within HANA

As it is clear that this will have a significant drawback to resource consumption (discussed below
in detail) we have to carefully balance the gain in responsiveness and increase of resource
consumption. As a counter example we would not recommend to retrieve different aspects of
some BO hitting at the end the same CDS view neither by requesting parallel OData calls nor by
parallel execution of batched calls from gateway into the application executing big parts of
identical code (on the Application Server and on HANA). The best solution for this would be to
have one OData call retrieving all needed data with one application call. As this problem might
arise due to independent components of the UI on the client, this must be solved by an
appropriate UI pattern framework.

6.2 Resource Consumption

6.2.1 Stateless Programming Model and Draft Infrastructure
With the shift to a stateless Programming Modell we have to change the way we implement business
logic inside the Application Server. In the “old” state full model the application took on startup a copy
of all needed data, evaluated configuration and worked on all subsequent interaction on this private
copy. This leads to expensive startup time but reasonable execution times and resource consumption
for subsequent interactions. If we would simply reuse the code as it is and only throw away the state
at the application server (keeping only the user changes on the UI or persistency) we would have to
pay the high startup price for each interaction. In a stateless programming model the paradigm of
requesting only what is needed for the current page should hold all the way down to the persistence.
As there will be no reuse of the prepared data (state) in the next request it is a waste of resources
(and time) to do. For good stateless application we have to learn to invoke and process parts of
objects much better as we did in the past. This includes to have at any stage the right level of
consistency: Which determinations and validations are needed for a given change request. So the
following principles are key to get good performance and reasonable resource consumption:

• Only process data needed for the current request

• Do not execute validations and determinations which are not needed for the current request.
We have to know exactly which changes will invalidate which validations and which
determinations have to be executed again (This is especially important for large objects where
changes are made only on a small subset)
• Mainly one should only persist the attributes the end-user has changed or created. We should
only Save additional derived fields if:
o We can avoid re-executing expensive code (validations or determinations)
o We can simply decide whether these derived fields are still valid
o We can handle derived fields with "UNDO and REDO"
To only persist the changes of the current request is in particular important for large Business
Objects.
• Read requests should typically be served without intensive business code: validations only for
change requests determinations and only for derived fields not part of the draft persistency.

6.2.2 Usage of CDS Views.

The usage of CDS views can have quite a significant impact with respect to resource consumption
on the persistency layer. This is in particular true when CDS views are consumed executing business
logic. From an architecture point of view there are two main differences compared to the way we have
accessed business data before.

© Copyright SAP SE 2017 Internal/Confidential Page 53 of 100

Architecture Guideline S/4HANA

In the past only transactional data and some master data had been accessed from persistency; all
kind of Meta Data (customizing, texts, etc.) have been cached on the Application Server. Using CDS
the retrieval of a simple direct accesses may be replaced by a complex (layered) view including joins
with Meta Data and authorizations.
The second key difference is that in the past data, which had to be retrieved, was determined as part
of the business logic evaluating attributes of the already processed data (significant part of our code
consists of IF ELSE blocks or huge CASE Loops where on attribute level it is decided which data is
needed (from persistency) for further processing).
This is fundamentally different now: As the execution plan of a database statement is computed on
statement level not considering the actual attributes the execution of the plan at runtime cannot cut
away unnecessary branches which was done in the sequential processing in the past. This may result
in dramatic resource increase in particular if we use nested or stacked views and imperative code
within. This problem might improve in future by HANA but this needs huge efforts and will probably
not be available when we have to ship the product.
One thing we should also keep in mind: With the client server architecture of R/3 we had the possibility
to scale out on the application server layer. The data which could be consumed not relying on
transactional consistency like Meta Data and Master Data have been distributed to the application
servers or even to the clients and the infrastructure assured that data was most effectively consumed
on the right layer. In today’s vocabulary this is nothing else but an implementation of a Content
Delivery Network (CDN) together with Client Sides Statement Routing to ensure optimal scalability
behavior. This strategy is still a valid one and we should not apply the principal of bringing code to
the data as the only way to implement business applications reducing the application layer to a pass
through of OData request to the Database. We will need both strategies in order to build a high
performance and high scalable solution and we have to carefully decide when to move the code to
HANA as the scalability of HANA for scale out and scale up is still to quite limited.
For that we have to follow some rules to not dramatically increase the resource consumption of the
persistence layer and spoil the end user performance and the scalability limits in particular for
accesses which are executed inside “high volume” transactions:

• Inside transactional processing (e.g. creation of sales orders) you must not use views to retrieve
data of single business object instances (or small lists of objects accessed via a list of object
keys) if the views are accessing data which is buffered in the application server or if the views
are complex views doing complex expressions and/or calculations. This becomes even more
important if the views are called not only once but several times within a transaction (there
might be in future a possibility via client side statement routing to use the views but make also
usage of a cash infrastructure which would only pass the corresponding requests for the
transactional data to the persistency)
• In general complex views (doing complex calculation and/or accessing buffered tables) should
only be used in code push down scenarios where the result set that has to be transferred to the
Application Server can be reduced dramatically. In such a case it is more efficient to do the
calculations and the evaluations of the configuration data directly on the DB. OLAP scenarios
are typical candidates where the usage of such complex views is required and where their
usage makes
• Do not use CDS views where huge aggregates have to be computed within “high volume”
transactions. For those cases where we have removed aggregate tables and shadowed them
by compatibility views we have to ensure that we do not replace a simple direct access to a
former aggregate to an aggregation on the fly within transactional processing(this will be even
more important looking towards an on-premise shipment for S/4HANA.)

Two typical solution patterns to avoid this situation:

• In many cases we have been using read modules to encapsulate and cash accesses to the
persistency. These read modules typically read all aspects (with select *) to be able to serve
different requesters without additional access to the database. As in many scenarios data
from the aggregates is not needed we have to redesign these read modules to avoid these
accesses.

© Copyright SAP SE 2017 Internal/Confidential Page 54 of 100

Architecture Guideline S/4HANA

• For the situation where we need aggregate information within “high volume” transactions.
We need a cache infrastructure to be able to access the needed information with
reasonable resources. This has to be build.

© Copyright SAP SE 2017 Internal/Confidential Page 55 of 100

Architecture Guideline S/4HANA

7 Cross System Integration into other applications

(Volker Wiechers)
Cross System Integration is an own workstream in the S/4HANA Program where all process
integrations aspects and technologies are evaluated and defined. Inside this guideline the major rules
will be published.
More details and rationales behind the rule could be found in our Wiki.
To be focused within our rules, we are using three potential cross system integration categories.
These categories are distinguished by the organization that builds and operates the cross system
integration:
• SAP Public Cloud internal integration: Out-of-the-box integration between SAP cloud
products, operated by SAP.
• Pre-packaged integration: Template-based integration to selected SAP on premise and third-
party applications, operated by customer.
• Customer-built integration: Integration based on APIs provided by SAP, orchestrated and
operated by customer.

An ongoing debate is the selection of the “right and best” integration infrastructure. In the past, SAP
has introduced various technologies and applications build their integration on top of it. Among others,
the most used technologies are RFC, ALE, SOAP Web Services and newest OData. None of these
technologies and infrastructures where designed, which respect to the ABAP environment, for public
cloud operations. This includes technology, infrastructure and the adaptation by the application. To
lift all technologies, even the oldest, to become public cloud ready, will be a massive investment in all
areas. Therefore we decided to invest only in technologies that are based on internet standards like
SOAP Web Service and OData. Which one of the remaining technologies is the best for all kinds of
integration is not a pure architecture decision. The availability of tools, matureness and market
penetration are important boundaries conditions. Where OData has proven it strength in data centric
scenarios like UI and analytical consumption, there is less experiences within the sSuite, how to use
OData for application-to-application integration as found in common A2A or B2B scenarios, which
were in the past the domain of asynchronous messaging infrastructures.
To give sustainable guidance if and how to implement the common business transaction pattern on
top of OData, we will collect your input sustained by POCs. This is an ongoing activity. Please visit
our wiki and this architecture guideline for updates.

7.1 General Rules for Cloud

[C-CSI-1] Any integration technique leaving the technical system boundary for any type of
integration (A2A, B2B...) shall be evaluated and qualified by the integration
workstream.
[C-CSI-2] Cross System integration should use OData or SOAP WS technology.
[C-CSI-3] SAP Cloud internal integration could use any existing integration technology as long
SAP cloud operations has a cost efficient way in place to operate this integration.
Contact the process workstream for an assessment.
[C-CSI-4] All public remote APIs must be documented The documentation must include easy
understanding examples. Because no central API repository serving all kinds of
APIs is available, applications should document their APIs within their application
documentation.
[C-CSI-5] All public remote APIs must be stable or explicite tagged as beta release which
implies, that this API is subject to change in upcoming releases.
[C-CSI-6] All public remote APIs from on application area must be consistent with respect to
naming of operations and structures (nodes) and behavior. Naming should follow
the terms presented through the user interface (UI).

© Copyright SAP SE 2017 Internal/Confidential Page 56 of 100

Architecture Guideline S/4HANA

[C-CSI-7] All public remote APIs must be tested. SAP Cloud internal and pre-packaged
integration must be tested end to end. Performance KPIs must be recorded.
[C-CSI-8] For simplifying the on-boarding of existing customer, existing IDOC and
BAPIs/RFCs could be used in special cases. This moves the operations from SAP
cloud operations to the customer IT and therefore the integration workstream must
be involved to define all required tasks.
[C-CSI-9] If SAP application development replaces an existing end-to-end integration based
on IDOC or BAPI/RFC by a semantic compatible based on OData or SOAP WS, the
application must provide pre-packaged integration to simplify and speed up the re-
implementation of this integration by our customer.
[C-CSI-10] Pre-packaged and customer-built integration should be based on OData or
synchronous SOAP web services
[C-CSI-11] If an application provides an asynchronous messaging inbound interface, the
application must provide an UI for end-user/business-experts to resolve potential
errors. NOTE: a simple XML-based message editor is by no means a sufficient
alternative. The application interface framework (AIF), a SAP custom development
product now included in S/4HANA, could be used for this purpose.
[C-CSI-12] All business objects exchanged in an integration scenario must have an explicit link
to their system of record. These objects must be immutable outside the specified
system of record (explicit data owner ship).
[C-CSI-13] Integrations requiring an integration middleware shall use SAPs cloud enabled
products. Options are HANA Cloud Integration (HCI) for process centric and HANA
EIM for data centric integrations. Integration to SAP on-premise products could
leverage exiting SAP on premis products like SAP PI & PO and SLT as well.
[C-CSI-14] All integrations must be assigned to a “Communication Scenario” and must use the
“Communication Arrangement”.
[C-CSI-15] Business customizing required by an integration shall be provided by SET content
or as customer grade UIs.

7.2 General Rules for On Premise

[O-CSI-15] All remote APIs must be stable and follow the established API lifecycle approach.
[O-CSI-16] All remote APIs from one application area must be consistent with respect to naming
of operations and structures (nodes) and behavior. Naming should follow the terms
presented through the user interface (UI).
[O-CSI-17] All remote APIs must be tested. SAP internal integration must be tested end to end.
Performance KPIs must be recorded.
[O-CSI-18] All business objects exchanged in an integration scenario must have an explicit link
to their system of record. These objects must be immutable outside the specified
system of records (explicit data owner ship).
[O-CSI-19] Existing SAP on-premise integration like SAP PI/PO and SLT could be used for on-
premise, on-premise to SAP Cloud and B2B integration.
[O-CSI-20] Because no central API repository serving all kinds of APIs is available, applications
should document their APIs within their application documentation.
[O-CSI-21] To speed up and simplify the implementation of an integration by our customers,
pre-configured content should be provided. The best option for this are SET “Best
practices for integration”

© Copyright SAP SE 2017 Internal/Confidential Page 57 of 100

Architecture Guideline S/4HANA

8 Extensibility (Tobias Stein, Felix Wente)

8.1 Basic Principles and Goals
Typically two out of three public cloud customers need to extend their systems with custom fields
and this is especially applicable for the S/4HANA as the scope will grow over time. In the public
cloud environment we cannot just offer the extensibility mechanisms that the Business Suite has
today. We need to offer simplified extensibility to business users which are business experts instead
of IT experts, having no programming skills. This also means that we cannot expose SAP GUI and
Eclipse-based extensibility mechanisms to these users just as they are. We need to provide these
features in a way that they can be consumed by key business users.
Another important aspect is that in order to be successful in the cloud we need to control our costs.
One important factor here is the non-billable efforts that are caused by extensibility. Therefore it is
very important that we build on top of mechanisms that are modification free and do not cause after-
import or after-upgrade efforts.
Nevertheless customers do not just adapt the UI or add simple tags – they typically adapt the
business functionality of our products of course. So we cannot follow a „side by side“-approach. The
extensions have to be part of the extended software artefacts themselves. And therefore we will
need to technically build S/4HANA-extensibility on top of the existing concepts that are already used
in the Suite: like extension includes and BAdIs. Also the way how we transport between test and
production systems remains and utilize additional concepts like zero downtime.
It is very important to approach extensibility end-to-end: this means that we have to combine
extensibility patterns (like adding new fields, adding new tables and also rule based checks) with
the possibility to add extensions to UIs, print forms and reports and to map them along processes.
So here we touch many flexibility cross-topics that have to be enabled for field extensibility
mechanisms.

Flexibility Use Cases

The diagram above shows flexibility use cases with a rising complexity as a fan diagram
”Field extension” means to add a single field to a particular place within an application (e.g. Sales
Order Header) in a 1:1 relation behaving in the same way as the SAP standard application.
“Node extension” (sometimes also called “Table Extension”) means that a new entity in a 1:n or 1:1
relation is added with an own persistence.
Besides structural extensibility patterns also behavioral extensibility patterns will be be realized, for
example:
• Mapping structural extensions along processes
• Adapting process or workflow steps
• Influencing value checks or value help by rules

© Copyright SAP SE 2017 Internal/Confidential Page 58 of 100

Architecture Guideline S/4HANA

• application specific changes of pricing, rebate, tax algorithms

The basis of extensibility for Business Experts is a set of predefined extensibility patterns. The
extensions following a pattern are ready-to-use. This means after the extension process, they are
working already (including persistence, application integration) and can be configured in the UI
immediately.
We already have extensibility tools and mechanisms available in the Suite. But each tool has its
own capabilities and none of those is actually cloud-ready.
To enable Business Users for this task, a user friendly tool support is required, called “Business User
Extensibility Tool”. Its basis is a tool approach which allows end-to-end extensibility for predefined
extensibility patterns starting from the place which Business Users know best – the UI. Therefore it is
integrated in the UI configuration. Nevertheless the extensibility approach is not only UI related, but
extends the application together with the persistence completely, even in end-to-end processes
across several applications. In addition other approaches could be realized, like integration of the
extensibility tool into business configuration or process maps.
In its neighborhood the business user extensibility tool has several other configuration tools like UI,
Form and Report configuration tools. For these tools, extensibility support is enabled as well, meaning
tool created extensions can be easily applied to UI, Forms and Reports (e.g. via drag & drop) like
SAP standard fields.
We need a central extensibility solution that is targeting cloud business users Directly in the
application UI, Business Users can navigate to UI adaptation and field extensibility.
Such a tool approach has already been realized with the ByDesign Extensibility Tool and Application
Enhancement Tool (“AET”) in SAP CRM. Thus a new tool for sSuite should make use of the
experiences in this area and reuse concepts or implementation parts where possible.
Besides the definition of system-wide extensions, personalization for end users will be offered,
allowing them to configure the UI for themselves without influencing other users.
Last but not least, developer extensibility will be offered with the goal to allow development tasks
related to extensibility in a controlled way. For this purpose, a web based IDE will be offered allowing
developers to implement code. Compared to today’s Suite, the scope of code based extensions is
reduced: Only released (B)APIs can be consumed and only release language elements (DSLs and/or
ABAP) are available to ensure the system’s integrity cannot be spoiled.

8.2 High-Level Extensibility Tool Architecture

High-Level Extensibility Tool Architecture

© Copyright SAP SE 2017 Internal/Confidential Page 59 of 100

Architecture Guideline S/4HANA

As mentioned, UI configuration is the starting point for Business User Extensibility. Regardless which
UI technology is used, UI configuration shall allow the following features:
• Personalization of UIs for End users
• Adaptation of UIs for Business Experts. Common use cases are reduction of UIs (e.g. by
hiding parts), combination of UIs into one UI, rearranging UI elements, adding of new
elements to UIs. The adaptions can be deployed to test and productive systems or tenants.
• Acting as an entry point for the business user extensibility tool.
As several UI technologies might be used for a single application, the following has to be stated:
• Not all UI technologies are expected to trigger extensibility (e.g. Web Dynpro).
• Full coverage of extensibility, including extensibility tool navigation, is granted for Fiori Type
1 – 3 UIs.
• All used UI technologies must allow personalization and extensibility (including adding
extension fields to UIs).
To make the extensibility approach available for other platforms (e.g. HCP) as well, the extension
definition UI will be loosely coupled to the backend. It will follow the same OData and Fiori UI paradigm
as the S/4HANA applications.
Wherever possible, the extensibility registry refers to existing models like HANA Live or the extension
includes, which are the basis for multi-layer DDIC extensibility.
For tool-based extensibility of non-model-driven applications, a central metadata registry is a
precondition. The extensibility tool would access the repository about:
• Application definition with clearly defined relations on node level
(simplified and business user understandable “BO” model)
• Extensibility metadata describing which applications are extensible by which patterns. The
steps to be done for those extensions by the tools are defined here as well.
• Assignment of UIs, forms and reports to extensible applications structures
• A simplified process model defining end-to-end processes on message and application
level.
In future even cross platform extensions will need to be handled, so the registry needs to be
accessible across platforms.

8.3 Application Enabling for Extensibility

These following rules are mandatory for all application objects in the core scope of Model S. The list
of rules and tasks for application enabling for extensibility can be found in the Model S Wiki:
https://wiki.wdf.sap.corp/wiki/display/SimplSuite/Rules+and+Tasks+for+Application+Develop
ment

General Guiding Principles

ID Area Guideline

[OC-EXT-GEN-1] Upgrade All extensibility capabilities offered to customers must

Stability continue to work after patches and upgrades without
manual or automated after-import efforts.
Therefore no modification is allowed and copy-
based extensibility mechanisms must foresee
automatic merge.

© Copyright SAP SE 2017 Internal/Confidential Page 60 of 100

Architecture Guideline S/4HANA

ID Area Guideline

[OC-EXT-GEN-2] Multilayer Extension mechanisms shall be multi-layer enabled

Extensibility allowing parallel or stacked extensions
Examples: (1) Both customer and industries can
extend the same software artefacts, (2) Industry
extensions can be extended by customers

[OC-EXT-GEN-3] Efficiency Extensibility mechanisms shall be optimized both for

manual extensions (e.g. by a service center) and
automatized extensibility (e.g. by a Business User
Extensibility Tool), resulting in low development
and/or generation effort and the shortest downtime
possible.

[OC-EXT-GEN-4] Transport All extensions are created and transported with ABAP
based mechanisms in a way, that a transport contains
an extension completely without the need of further
LCM activities.

[OC-EXT-GEN-5] Technology Technical or application based frameworks, engines

Enablement and APIs supporting extensible applications, must
provide extensibility themselves.
Examples: Middleware technologies, pricing engine,
external application interfaces

[OC-EXT-GEN-6] UI All UI technologies used by extensible applications

Extensibility must provide Personalization and Adaptation of
standard and extension attributes, obeying to the rules
above. For Fiori UIs this is described in a separate
guideline: Extensibility

Development Guidelines for Field and Process Extensibility

ID Area Guideline

[C-EXT-FIELD-1] Extensibility All applications that are part of the core scope
Model have to register their relevant application artifacts
Registration to the extensibility tool (as described in the
separate guideline).

[C-EXT-FIELD-2] Extension All applications that are part of the core scope
Includes have to implement extension includes for all
extensible nodes of an application object and
guarantee it is transport from DB up to service
implementations. It must be possible to extend a
Model S application end to end (in all layers:
backend, oData, UI). Inside your application use a
“move-corresponding” logic in all transfers from the
persistency structures to other internal structures.

© Copyright SAP SE 2017 Internal/Confidential Page 61 of 100

Architecture Guideline S/4HANA

ID Area Guideline

[C-EXT-FIELD-3] Gateway / OData For Gateway development you have to make sure
Extensibility that all OData services are built up from CDS
views or DDIC structures that are extensible with
Extension Includes. Every OData entity must be
bound either to a CDS view or to an ABAP DDIC
Structure.

[C-EXT-FIELD-4] Migration of Migrate all existing customer includes

Customer corresponding to BO nodes which are classified
Includes as extensibility relevant by Solution Management
to Extension Includes.

[C-EXT-FIELD-5] Application Substitute application specific field extensibility by

Specific the extension include approach whenever
Techniques possible (consult Model S Extensibility team).

Ensure that the specific approach fulfills the

general extensibility rules.

[OC-EXT-FIELD-6] BAdIs Make standard and extension fields available

within Validation, Calculation, Mapping and
OData Exposure BAdIs as well as in relevant
application specific BAdIs. Do not use customer
exits, but convert them into kernel-based BAdIs or
provide new BAdIs.

[OC-EXT-FIELD-7] Unit Tests Provide Unit Tests for extensible applications.

[OC-EXT-FIELD-8] Documentation Provide Documentation for Application specific

for Service Extensibility Techniques to be used as Guideline
Center for Service Center.

© Copyright SAP SE 2017 Internal/Confidential Page 62 of 100

Architecture Guideline S/4HANA

8.4 Customer Code Options for the Different Deployments

Based on the decision matrix for S/4HANA On Premise and Cloud the following matrix shows the
different options for customer code in the AS ABAP Stack.

Customer code options for the different deployments

© Copyright SAP SE 2017 Internal/Confidential Page 63 of 100

Architecture Guideline S/4HANA

9 Elimination of outdated technologies S/4HANA

There are dedicated technologies and reuse components which are no longer state of the art or just
outdated in a modern technology and application stack. Following are the most prominent ones – a
substitution and migration path will be provided for each topic in the following sub chapters:

To be extended…

10 Analytics
10.1 General Architecture
The architecture for S/4HANA Analytics is described in detail in a concept paper which is available
via the S/4HANA Analytics. An overview and the most prominent guidelines are described in this
chapter.

The Analytics architecture follow these general assumptions

• All S/4HANA scenarios (e.g. transactional and analytical) shall use the same landscape
components to reach a low TCO. Especially topics like user, role and authorization
management, lifecycle and application management shall be implemented only once via one
infrastructure component consistently use through all scenarios.
• A common meta model, Virtual Data Model (VDM), shall be the basis for the different scenario
types, i.e. Analytics & Planning, Search, and Transactional scenarios. Future integration of
additional scenario types shall be possible on top of the existing model.
• For the most part the data model of S/4HANA are the standard Business Suite DDIC tables
which remain unchanged. For specific areas these will be changed or created newly in the
context of the simplification efforts.
• Generic UI consumption for Search, Smart Business, UI5 ALV, or Design Studio Ad-Hoc
application shall be enabled.
• The architecture shall a support a pushdown to later without any change to the data model.
• The architecture shall support a deployment model in the public cloud, where end users and
key users shall only have web access to the system and be enabled to do all relevant steps
to configure and run the scenarios on their own.

To fulfill these requirements the general S/4HANA architecture relies on a common data model
provided via ABAP CDS Views as depicted in the overall architecture diagram.

© Copyright SAP SE 2017 Internal/Confidential Page 64 of 100

Architecture Guideline S/4HANA

UI

Lumira / UI5 /
Design Studio Analytical Table

ABAP Server

Analytic Engine

CDS View

HANA DB

SQL View

Table

Analytical parts of S/4HANA architecture

S/4HANA data are exposed via a virtual data model (VDM) for analytical reporting. The VDM is
implemented using ABAP CDS Views. At runtime the views are consumed via the Analytical Engine
which is part of the ABAP server. The Analytic Engine evaluates the metadata of the CDS views,
especially the analytical annotations, to enable the analytic functionality, e.g. formula aggregation,
exceptional aggregation, or hierarchy handling. For data retrieval the Analytic Engine calls the HANA
SQL views which are generated from the CDS views.
The Analytic Engine exposes the data via different channels for UI consumption. All channels in the
S/4HANA must be http-based to support a cloud deployment. For On-Premise shipments the usage
of other channels can be considered. Long-term it is desired to consolidate all accesses via OData.
For the time being additional protocols like InA are used to enable the usage of UI tools not able to
consume OData (like Design Studio).
On the UI level two default consumers are defined for S/4HANA.Ad-Hoc reporting is enabled via a
generic Design Studio application which allows a flexible analytic evaluation based on the VDM.
Second, analytical data can be integrated into UI5 applications, e.g. via the Analytic Table control,
and use OData for access to the views. The OData services are provided in a generic way by the
Analytic Engine.
In more detail, the following diagram shows how the CDS views are modeled and integrated into the
Analytic Engine runtime.

5 For the usage of Design Studio see the Current Restrictions.

© Copyright SAP SE 2017 Internal/Confidential Page 65 of 100

Architecture Guideline S/4HANA

Dev Environment Content Runtime

DS web
Design Studio DS Application application UI5 ALV
(SAPUI5)

InA OData OData

Query Builder
(Web)
CDS View NW BW Analytic
(Query) Engine

InfoProv API

CDS View
DDL Editor NW ODP runtime
(ODP)

OpenSQL

DDIC Table QL Engine

Design- and runtime aspects of analytics architecture

All modeling is done in the CDS views. They are consumed by the Analytic Engine via generic APIs
using the CDS views as metadata provider and data source. Data retrieval is achieved via the VDM
(comparable to Info Providers/ODPs in BW). On top of these VDM views other CDS views provide
the needed analytic metadata (comparable to a BEx query in BW). See the detailed modeling
guidelines for guidance regarding layering and modeling of these views.

10.2 General Guidelines

Out of the described architecture several guidelines can be derived for all analytic scenarios in
S/4HANA.
[OC-AR-1] Analytical scenarios / application shall be based on a general, consistent Virtual
Data Model (VDM) implemented via ABAP CDS views. Necessary analytical
metadata shall be provided via annotations of these views.
The analytical metadata (annotations) of the views are interpreted by the Analytical Engine to
expose the data for the analytical clients.

[OC-AR-2] No ABAP coding or BW content shall be used for analytic data access or
metadata description.
[OC-AR-3] No HANA-managed content shall be used for Analytics

In order to allow the later migration to a HANA-based approach it is necessary that all functionality
is contained in the views. This offers the possibility to push down the whole evaluation and
execution down to HANA when the necessary view and engine functionality is available in HANA
directly. Especially, this requires that no application-specific ABAP coding is used within the end-to-
end processing of an analytical request from a client. Only generic engine coding must be executed
in this process.
[OC-AR-4] All backend connectivity shall use the ABAP server via integrated Gateway server
(OData) or protocols provided by Analytic Engine (InA). No access is allowed using
HANA XS engine.
To simplify the system landscape it is mandatory to allow only one access channel to the backend.

© Copyright SAP SE 2017 Internal/Confidential Page 66 of 100

Architecture Guideline S/4HANA

10.3 Current Restrictions

Several restrictions exist for the current implementation of the Analytics architecture. The most
prominent ones are mentioned below. For the status of these restrictions refer to the guidelines WIKI.
• ABAP CDS doesn’t support all needed functional features in its current state. Details can be
found in the list of ABAP CDS requirements.
• For some use cases the performance of CDS views is different from the existing HANA
calculation views as the pre-optimization features of HANA calculation engine are not used.
Issues are collected and addressed centrally.
• Query Builder: the diagram depicts an end-user enabled tool for the creation and adaption
of analytic queries. This tool might is not available for the first shipment of S/4HANA. For
the time being, the customer/user can only use the pre-delivered queries. Adaptions of
these queries are only possible via the generic Design Studio application.
• Design Studio Template: currently the generic Design Studio application still has severe
functional and quality issues which prevent a productive usage in S/4HANA applications.
Therefore, it is temporarily replaced by the WD Grid. As soon as Design Studio template
has reached a stable state (planned for Q2/2016) the usages of WD Grid shall be replaced
by the Design Studio template.
• Lumira: Lumira currently doesn’t support ABAP CDS views. A roadmap for the support is
currently under discussion.

10.4 Further Details

• S/4HANA Analytics Workstream WIKI
https://wiki.wdf.sap.corp/wiki/pages/viewpage.action?pageId=1591365933
• S/4HANA Analytics concept paper
\\dwdf213\ACI_LOB_SoH\49_Simplified_Suite\30_Workstreams\18_Analytics\20_Concept\
Model_S_Analytics_Concept.pdf
• CDS View implementation guidelines WIKI
https://wiki.wdf.sap.corp/wiki/display/SuiteCDS/CDS+in+the+Business+Suite+Home

11 Output Management (Christoph Birkenhauer)

This architecture guideline contains all the aspects that an application must consider when using
print forms or outputting simple lists. There is a separate architecture concept document for all
infrastructure-related aspects, which only affect technology (NetWeaver, HANA platform) and cloud
operations.

11.1 Different aspects of Output Management

11.1.1 Print forms
A print form is a device-independent, pixel-perfect representation of a printable document.
Examples for print forms are customer invoices, dunning letters, cheques, and labels with bar
codes. Print forms can be rendered into different formats, for instance PDF, Postscript, or ZPL
(Zebra Programming Language for label printers).
Print forms are generated based on templates, which define the layout of a print form. SAP ships
templates for all scenarios that generate print forms. These templates follow a common style guide.
Customers can adapt them. Besides changing the layout, they can add fields with transactional
data.

11.1.2 Printing
Print forms can be displayed in the UI as PDF documents and printed locally via the client (frontend
output). They can also be printed by printers in the customer network without requiring a UI
connection (backend output).

© Copyright SAP SE 2017 Internal/Confidential Page 67 of 100

Architecture Guideline S/4HANA

Furthermore output management addresses the output of simple lists, which were generated in the
past with the help of a WRITE statement and the ABAP spool.

11.1.3 E-Mail output

Print forms can be sent as PDF attachment of an e-mail from the backend without involving the UI
client or the customer e-mail infrastructure. The cover letter (e-mail body) is generated from an
HTML template.

11.1.4 Output control

There is one infrastructure for all applications that generate print forms. In particular there is one UI
experience for the end-user when triggering the output, monitoring the output, and viewing the
results. Furthermore there is one configuration approach for all scenarios that require automation
(output parameter determination).

11.2 Simple List Output

UIs often display tabular data that does not fully fit into the corresponding UI area. The end user may
need to scroll both vertically and horizontally. Furthermore individual columns may be hidden and
filters may control which rows are displayed.
Such tabular data cannot be printed or exported as PDF directly. Instead it must be exported in a
spreadsheet format from the corresponding UI control first (e. g. Excel) and then printed or further
processed in the spreadsheet application.
If a list is to be printed or output as PDF document without first displaying it in the UI, print forms must
be used. There is no generic PDF rendering for tabular data.

11.3 General Rules

[C-OM-1] Disable “Print Version” in WebDynpro ABAP ALV. (Reason: “Print Version”
generates a PDF document with the help of a NW AS Java application, which is not
installed in S/4HANA Cloud for TCO reasons.)
[OC-OM-2] Do not use ABAP WRITE statement to create printable lists. Instead use print forms
if backend output without previous display in the UI is required.

11.4 Rules for Print Forms

[C-PF-1] Adobe XML Forms Architecture (XFA) is the only print-form technology supported
by S/4HANA Cloud. Do not include any references to SAPscript (as far as print
forms are concerned) and Smart Forms in UIs and documentation.
[C-PF-2] Create form templates for every scenario that supports print forms. Follow the
development guideline <….>, which includes an updated version of the style guide.
[C-PF-3] Reconcile the fields of your form templates with the form templates that are included
in the Best Practices of SAP Business All in One.
http://help.sap.com/saap/sap_bp/BBLibrary/General/US/Forms_overview_where_
used.xls contains a list of all Best Practices form templates. You can analyze these
Smart Forms in the following system:
Server: iwdfvm4667.wdf.sap.corp
System number: 06
Log on to client 320 with user DEMO, password best123, and copy user DEMO to
your own user.
[C-PF-4] Create sample data for every form template according to <guideline to be provided
by August 15th, necessity to be discussed>.

© Copyright SAP SE 2017 Internal/Confidential Page 68 of 100

Architecture Guideline S/4HANA

11.5 Rules for Output Control

To be finalized

© Copyright SAP SE 2017 Internal/Confidential Page 69 of 100

Architecture Guideline S/4HANA

12 Information Lifecycle Management (Axel Herbst)

Cloud Managing Authorities have to ensure that operational aspects like keeping only a minimum of
data in memory are established. Moreover, legal requirements e.g. controlling where and how long
to store data, have to be met.
Targeting TCO reduction, simplification, and operations - in alignment with new physical data models
that avoid redundancy -, the new technology Data Aging for separating HOT (Current) and COLD
(Historical) data gets preference to Data Archiving. Nevertheless, Data Archiving and the ILM
framework continue to exist in S/4HANA.
Note that the Data Privacy guidelines are covered in chapter “Data Protection”.

12.1 Data Archiving versus Data Aging

In S/4HANA Cloud, Data Archiving shall be avoided – the only exception is to meet Data Privacy
requirements (see chapter “Data Protection”).
In S/4HANA On Premise, the criteria to choose what fits best, an Archiving and/or Aging solution,
include purpose, dynamics, ownership, and use of the data for which the footprint is to be reduced.
The following list helps you decide what kind of object(s) should be implemented:

a) The development of an AGING OBJECT is appropriate if

• Purpose: Memory footprint reduction
• Fast growing tables, mostly inserts
• Content belongs to the customer, real business data
• Flexible SQL queries (incl. possibility to define views) are required, even if only needed in
exceptional cases and with accepted higher response times
• Data is usually classified as Transactional Data, incl. (application) log-like data

b) The development of an ARCHIVING OBJECT is appropriate if

• Purposes: Data footprint reduction (memory and disk space), “hiding” of obsolete/invalid/no
longer to be referenced data that should not yet be destroyed (“safety copies”), data
snapshots, retention requirements, minimum backup/recovery effort;
if archiving is to be used for the purpose of DPP (Blocking/Destruction) - see chapter “Data
Protection” for details
• Static table content, rare inserts, reads for a long period of time
• Object is not linked to a single business process instance, often shared between many
business process instances
• Static access paths are sufficient, queries can be predefined (and supported by archive
indexes), no need for built-in operational analytics – see chapter 10 Analytics
• Data falls into one of the two categories:
b1) Customer-owned
- Master data like material master, business customizing, org data like cost centers
b2) SAP-owned
- Meta data, source code, help texts, monitoring/tracing data, communication payload (e.g.
RFC payload)
- Data to operate the system correctly from a technical point of view

Overall, the following rules apply:

[OC-DA-1] If there is the need to move data out of the HANA main memory, the development
of a Data Aging object is mandatory. Along with Aging, access coding needs to be
adjusted in those exceptional cases where it would be wrong to process only
HOT/Current data (default visibility).

© Copyright SAP SE 2017 Internal/Confidential Page 70 of 100

Architecture Guideline S/4HANA

[OC-DA-2] Existing archiving objects can be used further in S/4HANA – however, in Cloud only
for Data Privacy reasons. Reading capabilities for old archives created with ADK
are required if corresponding conversion/migration scenarios are offered.
[OC-DA-3] The development of new archiving objects is also allowed in S/4HANA if this is
justified by the above listed criteria.
For the development of Data Aging in S/4HANA, consult the Development Guide in the Data Aging
Wiki. For Archiving Object development, Product Standard guidelines are available in the SAP Portal
go/ilm.

12.2 Retention Management

Retention management targets mainly the control over the place and duration of data storage.
Especially in OnPremise, certain data must be kept on storage systems that are located in dedicated
geographical regions. Moreover, some application domains (esp. in the so-called regulated
environments) require WORM-like, immutable storage. Finally, data must be deletable at the end of
its lifecycle – we call this data destruction. However, data destruction is not only triggered by DPP
(see chapter “Data Protection”) but it is also a general means to decrease TCO as it helps reducing
the HANA data footprint and downstream efforts like mirroring, replication, extraction, and
backup/recovery.
Policy-based declaration of retention times and execution support for data destruction should be
uniformly provided for all eligible data, regardless whether this is legally required or just to simplify
system operations.
[OC-RM-1] In S/4HANA, all released archiving objects shall be ILM-enabled for data destruction.

Note
Even though further deletion techniques exist, we encourage you to implement destruction via
ILM enabled archiving objects for the sake of a uniform user experience – especially if the data
to be deleted is subject to be “safety copied” before by some customers.

© Copyright SAP SE 2017 Internal/Confidential Page 71 of 100

Architecture Guideline S/4HANA

13 Data Protection (Carsten Pluder)

Data protection is associated with numerous legal requirements and privacy concerns. In addition to
compliance with general data privacy acts, it is necessary to consider compliance with industry-
specific legislation in different countries. This section describes the specific software requirements to
support compliance with the relevant legal requirements and data privacy.

Note
SAP does not provide legal advice in any form. This is explicitly to be followed in architecture,
configuration and documentation. In cases where examples are required, they have to be
marked as examples. In documentation, SAP notes, or any other written communication, SAP
software supports the customer by providing functions to:
• Simplify the deletion of personal data.
• Report on existing data to an identified data subject
• Restrict access to personal data
• Log read access to personal data
• Log changes to personal data
• (…)

Some basic requirements that support data protection are often referred to as technical and
organizational measures (TOM). The following topics are related to data protection and require
appropriate TOMs:

• Access control
Authentication features as described in section <link to “13.2 User Authentication
and Single Sign-On (SSO)”>.
• Authorization
Authorization concept as described in section <link to “13.3 Authorizations”>.
• Read access logging
As described in section Read Access Logging.
• Communication Security
As described in section <link to “5.3 Ensuring Multi Tenancy Capabilities”??>.
• Input control
Change logging is required to log changes to personal data.
• Separation by purpose
Is subject to the organizational model implemented and must be applied as part of
the authorization concept.

Caution
Personal data has to be stored with regard to a corresponding legal entity or a
corresponding organizational unit!
Further requirements targeting data privacy compliant handling of person
related data are listed in the following and described where necessary in the
following chapters. Not all points are covered yet, details and requirements for
open topics will be added in the future.
• Deletion / Blocking
• Documentation of the “purposes of the processing”
• Masking

© Copyright SAP SE 2017 Internal/Confidential Page 72 of 100

Architecture Guideline S/4HANA

• Information
• Anonymization
• Consent
• Notification

13.1 Recognize Personal Data

Personal information are particulars about personal or material circumstances of an identified or
identifiable natural person (data subject).
Sensitive personal data are special categories of personal data. Sensitive personally identifiable
information definition is for example based on the legal definition provided in Sec. 3 par. 9 German
Federal Data Protection Act: “‘Special categories of personal data’ shall mean information on racial
or ethnic origin, political opinions, religious or philosophical beliefs, trade-union membership, health
or sex life." (See also Art. 8 EU Directive on Data Privacy). In addition to the legal definition provided
by the German Federal Data Protection Act, sensitive personally identifiable information comprises
of data reflecting "criminal activities" as this latter is in other countries' Data Protection acts.”
Find more information on how to identify personal data also in the definitions of the product standard
security: https://wiki.wdf.sap.corp/wiki/display/PSSEC/Privacy+Personal+Data
Help and examples can be also found in the document "How to Recognize Personal Data".

13.2 Purposes of the Processing

Processing of personal data is forbidden, as long as the following conditions are NOT met:

• The data “is processed fairly and lawfully;”

AND

• The data is “collected for specified, explicit and legitimate purposes and not further
processed in a way incompatible with those purposes.” (Art. 6 Section 1 EU DIR
95/46)
Beyond the end of the primary purpose, for which the personal data was initially stored, personal data
can still be retained for other explicit legal reasons such as retention periods prescribed by law,
statutes or contracts.

13.3 Simplified Blocking and Deletion of Personal Data

A typical potential scenario in certain countries is that personal data shall be destructed after the
specified, explicit, and legitimate purpose of the processing has ended but only as long as no other
retention periods are defined in legislation, for example, retention periods for financial documents.
Legal requirements in certain scenarios or countries also often require the blocking of data (meaning
to restrict their further processing or use) in cases where the specified, explicit, and legitimate
purposes of the processing has ended but the data is retained in the database due to other legally
defined retention periods.
In some scenarios, personal data also includes referenced data. Therefore, the challenge for
destruction and blocking is to handle first referenced data and finally data such as business partner
data.
We use SAP Information Lifecycle Management (ILM) to support the entire data lifecycle including
the storage, retention, blocking, and deletion of personal data for S/4HANA OP and Cloud.
Here we differentiate the following terms in regard to the data lifecycle:

• End of Business (EoB) – represents the completion of the business respectively the
end of the primary purpose.
• End of Purpose (EoP) – represents the time, when further processing of personal
data after End of Business ends. This time period until EoP can be permitted or

© Copyright SAP SE 2017 Internal/Confidential Page 73 of 100

Architecture Guideline S/4HANA

prescribed by other legal provision or if the data subject has consented. A typical
example is financial reporting, which allows processing of personal also after end of
business.
• End of Retention (EoRT) – represents the time, when all other retention periods
beside the primary purpose to store data have expired. Then the data has to be
destroyed.
As conclusion this results in the following requirements:

The approach (as already implemented in the SAP Business Suite) is to destruct the whole object
e.g. “Order” and not only certain fields. This approach should only get challenged based on customer
requirement or in special cases of “sensitive personal data”.

Note
Retention management is not only done to manage data destruction after end of retention in
regard to data privacy. It is also related to volume management, covering data footprint
reduction via Archiving. Note that these topics targeting TCO reduction are covered in chapter
“Information Lifecycle Management”.

In summary this results in the following requirements:

[OC -DP-1] The definition of ILM objects is required to enable the destruction of data including
retention management for application objects storing person related data that are
applicable for other retention periods beside the primary purpose.
[OC -DP-2] Application objects storing person related data that are not applicable for other
retention periods have to provide a destruction functionality, which can destroy all
data for which the primary purpose is completed.
[OC-DP-3] Application objects that are relevant for blocking of transactional data after end of
purpose have to provide an ILM enabled archiving object. Archiving moves the data
from the database to archive files, marks by this the data implicitly as blocked and
imposes an access restriction to prevent further unauthorized processing of the
data.

© Copyright SAP SE 2017 Internal/Confidential Page 74 of 100

Architecture Guideline S/4HANA

13.4 End of Purpose (EoP) Adaption for Business Partner

consuming Applications

Master data as the business partner is by definition created without processing purpose. This can be
defined only considering the applications objects referencing the business partner. This means that
end of business, end of purpose and end of retention of a business partner is to be derived from the
highest time reference as to be determined by all depending applications. The following two figure
are examples for blocking and for destruction periods of a business partner with related business and
how the phases interrelate.

Figure 1: Information life cycle phases for residence period and important events for blocking, such as
start of residence time, end of purpose (EoP), and end of residence time.

As shown in Figure 1, each business document can have its own residence period with reference to
a business partner. During the residence time, data remains in the database and can be used in case
of subsequent processes such as returns, warranty issues, or even new business. The end of purpose
for a business partner is reached when the longest residence time of all related business documents
is over. After the residence time, expired data has to be blocked so that regular users and processes
cannot access this data any more, but only authorized users, such as data privacy officers or auditors,
can access it.

© Copyright SAP SE 2017 Internal/Confidential Page 75 of 100

Architecture Guideline S/4HANA

Figure 2: Information life cycle phases for retention periods and important events for destruction, such as
start of retention time, end of purpose (EoP), and end of retention time.

As shown in Figure 2, the retention time starts with the end of business and ends according to legal
requirements after a certain period of time, such as 7 or 10 years. Business partner data is stored
because of its use in related business documents. Retention periods are usually not defined for the
business partner master data. Instead, the retention period is defined by the retention periods of the
related business documents. After the longest retention time of the related business documents has
expired, the business partner master data has to be destroyed. Therefore, the business partner data
remains available until the last related business document data that uses a particular business partner
is destroyed.
To determine per business partner (including linked ERP Customer/Vendor) the usage in dependent
applications, to realize blocking after end of purpose and to store relevant start of retention information
a central End of Purpose check functionality is implemented. In a nutshell the blocking and deletion
concept for business partners has to fulfill the following requirements:

• For each business interaction, e.g. order, delivery and invoice it is possible to maintain
different residence and retention periods based on country- and customer specific
requirements. In case more than one residence/retention period is valid the longest is
applied.
• After expiration of the longest residence period the business partner is blocked.
• After expiration of the longest retention period the business partner and all related
data is destroyed.
In consequence the blocking of business partner master data requires then the following deliverables
by all dependent applications:
[OC-DP-4] Application objects with a reference to the business partner master data have to
provide an End-of-Purpose (EoP) check or at least a Where-Used-Check (WUC) to
enable blocking and deletion of business partners.
[OC-DP-5] Application objects with a reference to the business partner master data have to
consider a blocked business partner by preventing new business and providing
display access only for authorized users.

© Copyright SAP SE 2017 Internal/Confidential Page 76 of 100

Architecture Guideline S/4HANA

13.5 Read Access Logging

If no trace or log is stored that records which business users have accessed data, it is difficult to track
the person(s) responsible for any data leaks to the outside world. The Read Access Logging (RAL)
component can be used to monitor and log read access to data and provide information such as
which business users accessed personal data, for example, of a business partner, and in which time
frame.
In RAL, you can configure which read-access information to log and under which conditions.
… to be continued

13.6 Masking
… to be continued

13.7 Information
… to be continued

13.8 Consent
… to be continued

13.9 Notification
… to be continued

© Copyright SAP SE 2017 Internal/Confidential Page 77 of 100

Architecture Guideline S/4HANA

14 Identity and Access Management (Johann Kemmer)

Identity and Access Management deals with users and their authorizations. It is in this sense not
just another application, but the basis for a secure and compliant system operation. It’s important to
understand that for cloud and on-premise we do have completely different preconditions and
requirements.

• In S/4HANA cloud, SAP owns and operates the systems and to do so, requires users with
dedicated authorizations. The IAM concept in the cloud has to clearly separate SAP’s and
the customer’s “user and authorization scope”. In addition, it has to support automated
content lifecycle handling. For example, after system update, the authorizations of the
business users need to be updated automatically so that the customer business is not
disrupted. To reach these cloud qualities, SAP application development has to provide IAM
content and there is no flexibility for customers to “modify” this content. If customers request
more flexibility in S/4HANA cloud, we have to switch to the on-premise IAM model and run
the system in a hosting approach, like we do in the Hana Enterprise Cloud today.
• On-premise, the customer owns the S/4HANA system which will integrate with the
customer’s existing on-premise landscape. We must support a smooth migration path for
the customer-specific IAM content from older Suite systems, in addition application
development also has to provide IAM content for new, simplified components. In contrast to
the cloud, we can’t limit the granularity and flexibitity which the customer is used from older
Suite systems. While we strive for improved content lifecycle handling, a fully automated
handling is not possible and not desired. For example, on-premise admins want control
about changes of the authorizations in their systems after upgrade.

Considering these different assumptions and requirements, it is obvious that we need 2 different
IAM concepts for cloud and on-premise. On the other hand, we build both concepts on the same
user management and authorization (SU01/PFCG) runtimes, rely on the same IAM content models
and we target the same or similar improvements, addressing the pain points and TCO drivers that
today’s on-premise customers are facing.

14.1 User Management

User management in S/4HANA builds on the ABAP user management (SU01). For cloud scenarios,
SAP-owned and customer-owned users have to be clearly separated. Full transparency is needed
about which SAP-owned users exist and what they are used for. For this, all user are created based
on user categories that defined unique namespaces and user groups. There are three types of user
categories.

• SAP-owned users acting on behalf of SAP (for example DDIC)

• SAP-owned users acting on behalf of the customer (for example integration users)
• Customer-owned users (for example business users or communication users)

Most SAP-owned users are managed via the Cloud Access Manager (CAM). The tool can be
considered as kind of IDM system for SAP-owned users required for operating the cloud solution.
User category definition and the associated role content for all user categories is defined in the
product development system and delivered via regular transports.

Customer-owned users include the business users and the customer-owned technical users.
Business users are created for and linked to a real person represented in the system as business
partner. Technical users are created as part of the use-case specific configuration, for example the
configuration of an integration scenario.

© Copyright SAP SE 2017 Internal/Confidential Page 78 of 100

Architecture Guideline S/4HANA

In the S/4HANA public cloud scenarios, users are typically created for business partners of type
employee. These users are maintained during employee upload from the leading HCM system.
Customers don’t have access to the full SU01 functionality in cloud scenarios.

All S/4HANA systems have the Identity Model switched on. The Identity Model defines the relation
between business partner and business user. Note that this is an incompatible change compared to
former Suite systems. Classical suite applications that deal with users but did not define the relation
to business partners need to be evaluated and potentially adapted to support the Identity Model in
case these applications are still relevant in context of S/4HANA.

14.2 User Authentication and Single Sign-On (SSO)

Business user authentication and single sign-on (SSO) in the S/4HANA cloud scenarios is set up via
SAP Cloud Identity as default identity provider (IdP). SAML 2.0 is the SSO technology. Customers
may connect their own IdP to their SAP Cloud Identity tenant, which can then act as proxy. Business
users don’t have local credentials in the S/4HANA system.

Opposed to business users, communication users and SAP-owned users have local credentials in
the S/4HANA system as they are used for direct point to point communication with protocols that do
not support or require the SAML frontend SSO flow. Certificates are the preferred type for local
credentials of communication users and SAP-owned users. Only in exceptional cases, password
based authentication is used for them.

On-premise, we support multiple user authentication and SSO strategies. Customer’s can choose
those depending on their existing system landscape and infrastructure.

14.3 Authorizations
14.3.1 Authorizations for S/4HANA cloud

The S/4HANA authorization handling builds on the foundation of the ABAP authorization concept,
both for the cloud and the on-premise versions. With that, we ensure a common runtime and IAM
content model for the S/4HANA product family. To address the different requirements, we enable a
simplified approach for handling authorizations in the cloud, and evolve the existing approach on-
premise.

The simplified approach for handling authorizations in an S/4HANA cloud system is based on a new
design time for business roles that enables the key user to assign authorizations with the following
flow:

• The key user assigns a set of functionality (i.e. apps bundled in business catalogs) to a
business role.
• The key user optionally defines responsibilities as restrictions on business object instances.
• The key user assigns the business roles including restrictions to users.
• Based on these definitions the necessary authorizations are generated in the backend. The
customer key user does not directly deal with authorization objects anymore.

The approach relies on application-delivered (Fiori) IAM content, i.e.the properly maintained SU22
data for each OData service (or WebDynpro or HTMLGUI app), the business catalogs which
combine a set of apps needed by a user in a certain role as part of a business process, and an
authorization role per catalog. The catalogs represent tasks or sub-processes within a business
scenario - comparable to workcenter views in ByD. They are the most fine-grained unit regarding
structuring of work and authorization assignment and typically belong to an application area.

All business catalogs together build the “customer scope” in the S/4HANA cloud system and are
explicitly registered so that they show up in the new design time for defining business roles.

© Copyright SAP SE 2017 Internal/Confidential Page 79 of 100

Architecture Guideline S/4HANA

14.3.2 Authorizations for S/4HANA on-premise

For S/4HANA on-premise, we follow an evolutionary approach for handling authorizations as we

need a non-disruptive, fully flexible solution. While we start with today’s on-premise approach, we
simplify and improve in a phased approach addressing the most-relevant pain points customers are
facing today. The Fiori-PFCG integration is a first improvement, as it facilitates the Fiori-related
authorization handling. Further potential improvements include a move from a fully static definition
of roles which PFCG offers today, towards a more dynamic approach based on rules and a role
generation, resulting in less roles to be defined by the admin.

Fiori-PFCG integration allows adding catalogs to authorization roles in the backend. Authorization
relevant catalog content (i.e. OData services or WebDynpro apps) is determined per app and
automatically added to the role. The information which OData service is used by an app has to be
available in the frontend server assigned to the S/4HANA system. It’s planned to use the
AppDescriptor for storing this information in context of S/4HANA.

Like the cloud-approach, also the on-premise authorization handling relies on application-delivered
content. Properly maintained authorization content (SU22) is most important, all automation and
simplification tools rely on it.

14.3.3 Fiori impact on Authorizations

New functionality, both for cloud and on-premise versions of S/4HANA is built with Fiori UI and
along the Fiori paradigm. Certain Fiori characteristics impact the authorization handling 6:

• The role-based apps bundled in Fiori catalogs provide a targeted scope for a specific role.
With that it gets possible to derive the functional authorizations from the app assignment.
• The SOA-paradigm for building apps leads to the situation that the backend system does
not know the app, but only the OData service. Authorizing an app means authorizing the
OData Service.

As a consequence, suitable OData services that fit to the functional scope of the app and authorization
content (SU22 data) per service are key prerequisites for authorization handling. Wrong service cut
or wrong content result in wrong authorizations and by that in increased TCO, customer tickets and
even worse – hot-fixes in case of S/4HANA cloud scenarios.

What does suitable OData services mean? To illustrate this, let’s look at the business object
“Employee” and 2 hypothetical Fiori apps providing different views on it: The app “Employee address
book” provides the company-internal contact information. A second app “My Employees” enables the
manager to maintain sensitive data like salary or performance-related attributes for his or her
employees. Building both apps with the same service that includes both the contact data for the
address book and the sensitive data for managers would be technically possible, but violate the “least
privilege principle” or imply significant additional logic and configuration to strip down the
authorizations for the address book users of the service. Thus, these apps have to be built with 2
different services that only include the required data and functions.
A related aspect is the recommendation to design interfaces in a way that the minimum result set
according to the use case is returned without the need of comprehensive authorization configuration
(“paranoid interfaces”) . The above-mentioned “My Employees” apps could be realized with a service
“Access Employees” that controls access to the sensitive data of “arbitrary” managers and employees
based on authority checks (“Is the current user allowed to see this employee?”). With that, the admin
would have to maintain a specific role per manager, specifying the employees assigned to the

6 The White Paper „How Fiori impacts Authorization Handling” describes what Fiori means for
authorization handling, i.e. from the perspective of Fiori app developers

© Copyright SAP SE 2017 Internal/Confidential Page 80 of 100

Architecture Guideline S/4HANA

manager as authorization field values and keeping these values up-to-date. This administration
nightmare can be avoided with a service “Access My Employees” that internally determines the
current user (which is the user calling the service) and the employees assigned to him or her and
restricts access to these employees. With this service fitting exactly to the functional scope of the
app, the role admin only needs one single role for all managers and does not have to specify the
employees any more.

14.3.4 Data Control Language (DCL) for Core Data Service (CDS) for data
retrieval

While functional authorizations are covered via start authorizations for the app’s OData services, we
aim for pushing down instance-based authorizations for data retrieval to HANA via Data Control
Language (DCLs) for CDSs views. The DCLs provide a mapping to the PFCG authorizations, which
remain the single source of truth from authorization perspective. Unauthorized data is filtered on the
database already and doesn’t have to be loaded into the application server. Applications shall realize
their mass data retrievals via CDS with DCLs to realize performance benefits.

14.4 Rules
[C-IAM-1] Applications that require a SAP-owned user, e.g. a technical user for a certain process or
integration, shall contact the IAM workstream to define the required deliverables.

[OC-IAM-2] Applications shall support the Identity Model. Classical Suite applications with an own
definition of the relation between business partners and user need to be adapted in case they are
still relevant in context of S/4HANA.

[OC-IAM-3] Application development shall provide high-quality authorization content (SU22, …) for
each OData service or application – automation tools rely on it!

[OC-IAM-4] Application development shall provide the IAM content required for productive use in
S/4HANA, i.e. the business catalogs, authorization role per catalog, org-level fields for instance-
based restrictions. A detailed description is available on the Wiki:
https://wiki.wdf.sap.corp/wiki/display/appsec/S4+HANA+Fiori+Security+Guidelines#S4HANAFioriSe
curityGuidelines-Authorizations.

[C-IAM-5] Application development shall provide business roles and restriction values as SAP
proposal for a new system setup.

[OC-IAM-6] Application development shall use a dedicated, suitable OData service for each Fiori
app. Too broad or generic services lead to wrong authorizations. Avoid interfaces that rely on
authorization configuration, instead use “paranoid interfaces”.

[OC-IAM-7] Application development shall provide AppDescriptors per app (not possible yet, rollout
will follow).

[OC-IAM-8] Application development shall push down instance-based authorizations for data
retrieval to the database via DCLs for CDS views.

© Copyright SAP SE 2017 Internal/Confidential Page 81 of 100

Architecture Guideline S/4HANA

15 Generic Reuse Components

15.1 Business Process Management
Within S/4HANA workflow is the most relevant building block of BPM. Workflow in this context relates
to any process that is implemented using a central engine or a similar framework, that allows
configuration of the set and order of automated or human activities (or steps) that are executed as
part of the process.
The workflow engine has to run, control and monitor all workflow related activities in the system. The
engine operates on the principle of servicing events evoked by business processes and applications
from within or from outside the application platform. The process entities (workflow, work item/task)
are handled by the engine
The workflow infrastructure consists of the workflow engine (runtime), a workflow design time and
some related components. The workflow inbox is a separate component and key part of the overall
solution.

15.1.1 Workflow for ABAP-based applications

The approach to workflow in sSuite is the use of SAP Business Workflow (BWF) as the workflow
environment.
Existing BWF-based workflow solutions have to be changed: The use of static workflow templates
that are used rather than copied by the customer and adjusted is recommended; this will simplify the
lifecycle (no/less versions, no copies by customers). All configuration of the workflow that is required
should be taken out of the template and put into externally available configuration. Typically this
concerns processor determination and condition rules. The usage of BRFplus is strongly
recommended for these use cases.
[OC-WFC-1] If workflow capabilities are required, use SAP Business Workflow. Provide a generic
template that is controlled via external configuration that is evaluated during the
execution of the workflow.
Since the limitation Initially only a limited set of scenarios will be supported.

15.1.2 Business Events

Events on business level are required for multiple use cases, including prominently, but not only for
workflow, to trigger an asynchronous follow-up action. Other use cases for events are general publish-
subscribe patterns and process monitoring and analytics. Events should be business object centric.
Any time such an event mechanism is required, class-based shall be used to publish the event. The
consumption is handled by subscribing to the event using Event Type Linkages. This way all
applications have to provide only one instrumentation for event publication and there is one way of
event consumption. Alternatively, events can be published and send using Business Objects
Repository (BOR) events based on BOR objects, if BOR is already widely used or required for other
reasons.
[OC-WFE-1] If business events must be published by the application, use class-based events.
[OC-WFE-2] If business events are consumed by an application or framework, use the Event Type
Linkage.

15.1.3 Workflow Inbox

The My Inbox serves as a centralized generic inbox for all work items in S/4HANA. It can be
configured to supports application specific requirements.
The My Inbox follows the Fiori paradigm and is available in S/4HANA. It serves as a generic inbox for
work items. The inbox takes its data from the Task Consumption Model (TCM), which is part of NW
Gateway. TCM and thus the inbox are SAP Business Workflow enabled. Additional configuration here
supports custom attributes, i.e. any attribute that is not a standard attribute like user, title of work item
etc. A specific variant of the inbox can be configured to show specific attributes.

© Copyright SAP SE 2017 Internal/Confidential Page 82 of 100

Architecture Guideline S/4HANA

[OC-WFI-1] Use the My Inbox for processing of workflow items.

15.2 Search
Central Fiori Search is realized with NW Enterprise Search. Enterprise Search Models are required
for all relevant Business Objects and all relevant business data that should be found via the central
Fiori Search. The Fiori search UI offers features to search cross Business Objects with filtering, text
search and result highlighting (“Why Found”). Fiori search is the main entry point for fact sheets and
object pages.

[OC-SRCH-1] For S/4HANA only table-based models are allowed in order to improve TCO and
avoid data replication.

[OC-SRCH-2] Extractor based search models MUST NOT be used (as of today Sapscript long
texts require extraction – replacement under discussion).

[OC-SRCH-3] Fact Sheets and Object Pages shall be modeled via CDS and exposed via SADL.

FIORI UI Object
Search pages

R R

ABAP Server

Enterprise Search GW OData/SADL

R
R

HANA
Search CDS Views
Models

Suite Tables

Find more information and guidelines on Search and Object Pages development in this WIKI:
https://wiki.wdf.sap.corp/wiki//x/dAMyYg

15.3 Rules Engine

15.3.1 Business Rule Management Systems
A Business Rule Management System (BRMS) is a software system used to define, deploy, execute,
monitor, and maintain the variety and complexity of decision logic that is used by operational systems
within an organization or enterprise. This logic, also referred to as business rules, includes policies,
requirements, and conditional statements that are used to determine the tactical actions that take

© Copyright SAP SE 2017 Internal/Confidential Page 83 of 100

Architecture Guideline S/4HANA

place in applications and systems. A core element of the business rule approach is the execution
transparency for functional experts and the ability to implement changes to the business logic without
technical support.
A BRMS includes the following components:
• A repository allowing decision logic to be externalized from core application code
• Tools allowing both technical developers and business experts to define and manage
decision logic
• A runtime environment allowing applications to invoke decision logic managed within the
BRMS and execute it using a business rules engine

Benefits using a BRMS:

• Reduced or removed reliance on IT departments for changes in live systems; although QA
and Rules testing would still be needed in any enterprise system.
• Increased control over implemented decision logic for compliance and better business
management.
• The ability to express decision logic with increased precision, using a business vocabulary
syntax and graphical rule representations (decision tables, trees, scorecards and flows).
• Improved efficiency of processes through increased decision automation.

15.3.2 Business Rules in sSuite

In sSuite Business Rule Framework plus (BRFplus) is used for any business rule related use cases.
BRFplus is deeply rooted in the ABAP stack providing all sSuite related architectural qualities. While
currently a WebDynpro ABAP based UI is used for the future Fiori-based alternatives are planned.
SAP Decision Service Management (DSM) is an add-on product for BRFplus. A comprehensive list
of capabilities of DSM can be found here. DSM is part of the sSuite code line.
HANA Rule Framework (HRF) is a comparatively new technology to implement business rules on the
HANA stack. In contrast to BRFplus that generates and executes ABAP code the focus of HRF is the
execution of rules in the SQL/SQLScript layer. While the focus of BRFplus is transactional (process-
centric) the focus of HRF is analytical (data-centric) allowing usage of rules to analyze and evaluate
huge amounts of data in HANA.
To allow optional combination of the two approaches and to overcome architectural gaps in HRF (e.g.
dependency on HANA XS, no support of ABAP lifecycle management) HRF is integrated into BRFplus
so that HRF capabilities can be used in sSuite.
Any other business rule solutions (such as Derivation Tool, Formula Builder, VSR …) have to be
replaced with BRFplus.

[OC-BRMS-1] If business rule capabilities are required, use BRFplus. Do not use any other
comparable technology. Usages of other rule engines or similar tools need to be
migrated to BRFplus.

© Copyright SAP SE 2017 Internal/Confidential Page 84 of 100

Architecture Guideline S/4HANA

[C-BRMS-2] HRF must not be used directly but through the BRFplus encapsulation only.

15.3.3 Business Rules and Configuration/Extensibility

Business rules should be used when a table-based customization is not possible or too complex. This
is for example the case when relevant parameters are not known at the time of development or when
many optional configuration tables have to be provided for a configuration task. Business rules should
also be used to implement BAdIs for behavioral extensibility (see Error! Reference source not f
ound.).

15.4 Attachment Services

This chapter defines the target architecture for Document and Content Management covering S4 and
HCP.
[OC-ATTS-1] Fiori Applications shall use the Attachment UI ReUse Service to handle
attachments. This ReUse Components provides the end-2-end processing logic for
file handling, supports large file handling, cloud security and partner product
integration.
[OC-ATTS-2] Integration into external Content Management Solutions shall be based on open
interfaces. Communication shall be based on the two protocols “Archive Link” and
“SAP CMIS”. Partner products require a certification.
[OC-ATTS-3] Partner product specific integrations are strictly forbidden. The customer shall have
the choice to decide for one storage and content management solution for this S/4
installation consistant across applications.
[OC-ATTS-4] S/4 ABAP Applications shall use higher level services for document and attachment
handling. SAP DMS is recommended to be used as the central Document
Management solution, while GOS can serve for basic attachments. See chapter
15.4.2 for details.

15.4.1 S/4 Target Architecture for Content Storage Integration

Browser: Fiori URL Access with X-Token Browser: Fiori KPRO URL Access
Attachment-Reuse Attachment-Reuse

R R
OData OData

Gateway Gateway https:

Archive Link
R HCP Partner R
S/4 Document Center Document S/4 Content
https: Bridge Solutions Storage
Archive Link
& CMIS R
R

HCP Document CMIS (optional)

Services
(Default)

S/4 Cloud On-Premise

• Archive Link Interface (Ensure full Compatibility)

• CMIS Interface with SAP CMIS Profile Definition
Content Management Interoperability Services (CMIS) is an open standard that allows
different content management systems to inter-operate over the Internet. Specifically, CMIS defines
an abstraction layer for controlling diverse document management systems and
repositories using web protocols (REST).
The SAP CMIS Profile Definition (valid for S4 & HCP) allows to expose Documents with Folders and
their related Business Object relations in a standardized way for partner integrations.

© Copyright SAP SE 2017 Internal/Confidential Page 85 of 100

Architecture Guideline S/4HANA

15.4.2 S/4 ABAP Services for Document & Attachment Handling

SAP DMS and GOS are supported and shall be used in S/4. This includes the following capabilities:
• Fiori ReUse Component to handle Attachments
• Search Capability on File Content (requires integration into search models of BO)
• Integration to external Content Management Solutions via CMIS and Archive Link
• Cloud & On-Premise
• Access from HCP Applications, e.g. Mobile Documents / Document Center (including BO
authorization)
Other frameworks and direct access to lower level APIs are in compatibility mode:
• KPRO direct consumption from applications (e.g. BOPF attachments)
• Archive Link direct consumption from applications

15.5 Data Cleansing and Duplicate Checks

To be finalized…

15.6 Application Log

The Application Log Framework (Package SZAL in SAP_BASIS Software Component) is being used
in the ERP on Premise Deployment (central ERP EHP7 test system C7Z) by 1,227 purposes
containing 4,060 sub objects. Those ‘users’ of the Application Log Framework created in between in
this nonproductive environment close to 140,000 log entries. It is obvious that the meaningfulness of
those entries has to be challenged in a public cloud environment.
Example: In the current ER3 development system table BALOBJ contains 759 Application Log
Objects with another 2,596 Sub Objects in table BALSUB. Even if this figure is only 60% of the On
Premise deployment, we have already close to the same number of logs. 122,769 logs being created
following this top distribution:

Total of 122,000 logs (as of July 21st 2014)

/IWFND/ SAP NetWeaver
Gateway

BCSWNC CCMS Statistics

Collector

WF Business Workflow

/IWBEP/ SAP NetWeaver

Gateway Backend Enablement &
Event Publishing
ES
SDOK SAP Knowledge Provider

The usage of the application log will therefore be challenged defining the clear rule that…

[OC-AL-1] The central application log SZAL shall be used for storage of application based
message collection for legal, error and other relevant application events.

© Copyright SAP SE 2017 Internal/Confidential Page 86 of 100

Architecture Guideline S/4HANA

[OC-AL-2] Every application using the central application log shall ensure that every written log
has a dedicated ‘Receiver’ who shall take care of the log.
[OC-AL-3] The entity of the Sub object can be used to declare the role of the ‘Receiver’.
Following Roles may be recognized / differentiated up to now:
• Cloud User
• Cloud Key User
• Internal Cloud System Administrator
[OC-AL-4] Every application using the central application log shall ensure that an expiration
date is being set according to legal and/or application relevant conditions. The
respective field inside the Application Log Interface is ‘Expiration Date’
[ALDATE_DEL]. If this field is not being defined, a default value [31.12.9999] is
being set, which lead to unlimided application log growth for that Application Log
Objects. This is to be avoided.

To ensure a correct usage of the Central Application Log using 1st the ‘Expiration Date’ and 2nd
(when technical realized inside the data model) the ‘Receiver’ we will establish a governance
process to ensure that the SBAL-Interfaces are called in an appropriate way.
For Cloud Operations a periodic Cleansing Job will be set up to delete all log entries where
the ‘Expiration Date’ [ALDATE_DEL] is exceeded.

It is planned to develop role based central Fiori User Interfaces which shall be serve as a reuse
component.

15.7 Business Object Processing Framework (BOPF)

S/4HANA shall be fully cloud enabled and offer a Fiori UI experience. This implies a decoupling from
frontend and backend implementation and requires a stateless optimized backend implementation to
meet the performance requirements and keep the resource consumption as low as possible. BOPF
was optimized so far and supported best stateful applications, but is currently putting major invests
into stateless enablement and optimization. This approach is based on an architecture that provides
a direct read access to data (via CDS using SADL) for purely read-only access and modifying access
via the BOPF runtime invoking business logic. If it is detected that no business logic has to be invoked
for a modification this can be even further optimized to avoid building up a local buffer / cache.
The overall architecture where BOPF is embedded as transactional runtime depends on the various
consumption scenarios, i.e. an application-specific programmatic consumption where mainly
transactional access happens and analytical read-only access is the exception, a SADL-based
consumption (e.g. via Gateway/OData or other channels) or an Analytics Engine-based consumption
where mainly analytical access happens and BOPF is potentially used for analytical planning
scenarios with write-back and disaggregation etc.
The following diagrams depict these consumption scenarios focusing on BOPF and its usage. The
building blocks around on consumption side and the read-only access might not provide the exact
architecture, but are depicted in this way to foster the understanding of how BOPF is used in these
scenarios and to show the common and similar approach in all scenarios. Also whether the optimized
transactional read access is doen via CDS or the database table is not of importance here.

© Copyright SAP SE 2017 Internal/Confidential Page 87 of 100

Architecture Guideline S/4HANA

Application-specific Consumption

R
Analytical R Transactional
Access Access

Actions
OpenSQL

R
Side Effects
BOPF
(Determinations)
Runtime
optimized
direct transactional
read-only read and write R
access (bypassing Checks
BOPF buffer) (Validations)

CDS Views BOPF Buffer & Data Access

Application
Tables

Figure 1: Application-specific Consumtion of BOPF

© Copyright SAP SE 2017 Internal/Confidential Page 88 of 100

Architecture Guideline S/4HANA

Framework-based Consumption via SADL

Analytical R Transactional R
Access Access

SADL Query Actions

Runtime

R
Side Effects
BOPF
(Determinations)
Runtime
optimized
direct transactional
read-only read and write R
access (bypassing Checks
BOPF buffer) (Validations)

CDS Views BOPF Buffer & Data Access

Application
Tables

Figure 2: SADL-based Consumption

© Copyright SAP SE 2017 Internal/Confidential Page 89 of 100

Architecture Guideline S/4HANA

Framework-based Consumption via Analytical Engine

Analytical R Transactional R
Access Access

Analytical Engine Actions

Runtime

R
Side Effects
BOPF
(Determinations)
Runtime
optimized
direct transactional
read-only read and write R
access (bypassing Checks
BOPF buffer) (Validations)

CDS Views BOPF Buffer & Data Access

Application
Tables

Figure 3: Analytics Engine-based Consumption

Therefore the general rule (as also valid for the business suite) is to use BOPF for the implementation
of new or renewed applications and components. The current implementation of business logic is
very heterogeneous with high TCD and TCO. The implementation of new business logic should avoid
a further increase in heterogeneity, TCD and TCO. Therefore the Business Object Processing
Framework (BOPF) should be used as standardized business logic implementation framework.
Important aspect is that BOPF “only” adds the business logic whereas the model is always derived
from the VDM CDS model and the compositional hierarchy defined therein. Also further data model-
related information is derived from CDS and the annotations like static capabilities and field control
information.
Following this rule and noticing that the introduction of the draft concept introduces exactly new
objects and a renewed, stateless enabled and optimized application it is obvious that BOPF is a major
part of the draft enablement and has to be used according to the rule when supporting the draft
concept.
[OC-BOPF-1] New Business Objects shall be implemented with the Business Object Processing
Framework (BOPF).
[OC-BOPF-2] When creating and implementing new business object with BOPF the data model
shall be generated from CDS and only the business logic shall be added via BOPF.
[OC-BOPF-3] When adopting the draft concept the draft handling and business logic shall be
implemented with BOPF.

© Copyright SAP SE 2017 Internal/Confidential Page 90 of 100

Architecture Guideline S/4HANA

15.8 Statutory Reporting Framework – Advanced Compliance

Reporting
Statutory reporting (aka compliance reporting) means the legally required disclosure of financial and
non-financial information to a government agency according to a prescribed format (XML, XBRL,
JSON, flat-file, or PDF). Typically the report is to be submitted periodically, often electronically.
Optionally business partners can be notified of the data that was sent to the government agency.
Typical use cases are tax declarations, EC sales lists, or central bank reporting.
The statutory reporting framework is the tool to use for all such legally required reporting in S/4HANA.
Why do we have a new central framework in S/4HANA?
1. For the business user: One-stop shop for all compliance reporting with SAP Fiori
• One homogeneous UI with one common feature set
• Full transparency and audit trail with centralized storage of generated documents
• Embedded analytics based on line items as single source of truth
2. For the developer: Focus on the reporting needs
• Authoring environment for report definitions
• Out-of-the-box runtime environment
• Built-in extensibility for partners and customers
Adoption of the reporting framework can be done in two ways:
1. Model-based: A report definition consists of multiple documents. Per document, the developer
uploads a schema that describes the to be generated file. In a mapping screen, CDS view/BEx
query columns are assigned to schema fields. Embedded analytics is supported out of the box
whenever analytic queries are used. Extensibility is only supported for model-based report
definitions.
2. Compatibility mode: An already existing ABAP report is connected to the framework such that
monitoring and audit trail are enabled.
Besides report definitions, further development objects need to be created. They are transported with
workbench requests. UDO tool is supported. Best-practice content for business configuration
(customizing) shall be provided on top. Details can be found in the development guideline.
[OC-ACR-1] New statutory reports shall be built with the reporting framework by using CDS views
and modeled data mapping.
[OC-ACR-2] CDS views for statutory reporting shall be reused. New CDS views shall be included
in the VDM.
[OC-ACR-3] Existing statutory reports should be rebuilt by using CDS views and modeled data
mapping in order to push down calculation to the database and enable embedded
analytics based on a single source of truth.
[OC-ACR-4] If existing statutory reports cannot be rebuilt (e.g. due to missing development
capacity) they should be enabled for the statutory reporting framework by using the
compatibility mode.
The statutory reporting framework and all enabled reports are marketed under the name SAP
S/4HANA for advanced compliance reporting (ACR). For on premise, certain features for business
users are only available in a priced version. Furthermore reports can optionally be included in the
priced version. For S/4HANA cloud edition, all reports and all features are included under the standard
license.
The architecture is described in more detail in the architecture concept document.

© Copyright SAP SE 2017 Internal/Confidential Page 91 of 100

Architecture Guideline S/4HANA

Figure 4: Block Diagram Advanced Compliance Reporting

16 S/4HANA System Landscape

For all Information regarding the System Landscape for the S/4HANA please refer to the following
WIKI https://wiki.wdf.sap.corp/wiki/display/OPSuiteLS/Simplified+Suite.

© Copyright SAP SE 2017 Internal/Confidential Page 92 of 100

Architecture Guideline S/4HANA

17 Total Cost of Ownership TCO

17.1 General Assumption
The source of any TCO does have a clear correlation to the number of systems/components and
different technologies. This is the main multiplier of TCO drivers already understood in the different
Solution Landscapes of the Business Suite and can be expressed in an illustrative formula:
TCO is proportional to (TCO drivers) * (# of systems in landscape) * (# of technologies)
Here a TCO driver might be any administrative, operational or user specific action. Within each
technology (but also inside the same technology) there are different tools, UIs and system behaviors
which all add up to a higher effort to install, learn, run, maintain and test our software.

17.1.1 General Statement

The overall directive in the area of System Landscape Governance Board (SLGB) is to avoid any
uncontrolled increase in
• System landscape growth
• Non-interoperability between product releases
• Non-compatibility between software component versions
This is being guaranteed by full compliance to the defined Business Suite reference landscape in the
On Premise Deployment and its defined rules. As Hybrid Scenarios within a cloud based S/4HANA
solution is very likely and as this is also the aim to be offered from the beginning, the Version
Interoperability of SAP On Premise and in Cloud Products has to be guaranteed in a sustainable way.

17.1.2 Semantic Compatibility in Hybrid Scenarios and Data Migration

Hybrid scenarios with continuous integration and easy Data Migration with one time integration
from Business Suite on premise systems into the S/4HANA Cloud (Model S) are a key capability and
opportunity of S/4HANA. To ensure seamless integration with low implementation and operation
costs, a semantic compatibility has to be ensured.
Semantic compatibility means that only dedicated entities are in the focus of compatibility. In a first
approach those dedicated entities are all external interfaces (RFCs, BAPIs) and all transparent tables
for master data and applications data (delivery class A). The compatibility contract between S/4HANA
and Suite on Premise shall be tracked based on those selected entities. For entities which diverge
from their compatibility (e.g. change in data model, field extensions, interface adjustments),
mitigations shall be designed and developed (e.g. field length limitations in case of hybrid scenarios
with initial field input in S/4HANA).

[OC-TCO-1] The requested Version of the On Premise Business Suite Backend System shall not
be higher than Business Suite 7 – this corresponds to SAP ERP EhP4
[OC-TCO-2] Once a hybrid scenario is established, the connectivity and integration inside the
cloud application shall ensure version interoperability via downwards compatible
interfaces
[OC-TCO-3] Publically Released Interfaces (RFCs, BAPIs... ~1 200) and Database Tables with
the delivery class ‘A’ (Application table - master and transaction data ~ 8 700) shall
be kept compatible. A continuously cross system check from the S/4HANA
development system into the Suite on Premise Maintenance System will be
established. At a later point in time this check will be included into the general
Checkman Routines.
A positive Piece-Lists stored here ObjectsOfSematicCompatibiliy shall be kept
compatible.

© Copyright SAP SE 2017 Internal/Confidential Page 93 of 100

Architecture Guideline S/4HANA

17.2 Lifecycle Management

17.2.1 Zero Downtime
ZDM compliance basically depends on the changes being shipped via a support package or complete
product versions. Thus the following development guidelines have to be applied on any transports
containing any repository artifacts to achieve ZDM compliance.
Most actual guidelines can be seen here:
https://wiki.wdf.sap.corp/wiki/pages/editpage.action?pageId=1559350838

Nevertheless the major rules for S/4HANA are copied as follows:

So called After Import Methods (AIMs) and other application defined procedures (Switch-BAdIs,
switch-XPRAs) need a special ZDM enablement:

[OC-ZDM-1] Declare all tables read or written by the AIM or other procedure (in the AIM
repository). This includes all tables indirectly accessed via APIs that are called by
AIMs.

[OC-ZDM-2] Make sure that the production cannot change data read or written by an AIM or other
procedure.

Background:
• The upgrade has to clone all tables written by an AIM.
• The application must not overwrite any data written by an AIM (upgrade result would be
destroyed)
• The application must not overwrite any data read by an AIM (upgrade result would become
outdated)

Impact if you don’t comply with this guideline:

• The application system could become inconsistent.
• If you plan to create new AIMs, please contact LM for further guidance.

[OC-ZDM-3] For any changes to an After Import Method, the corresponding declarations in the
AIM repository must be updated accordingly.

Background:
For each AIM, the ZDM procedure compares the list of DB tables entered in the AIM repository by
the DB tables that are actually accessed by the AIM during its execution. In case an access to a DB
table is requested by an AIM which is not listed in the AIM repository, the ZDM procedures will abort
to protect the system from inconsistencies.

Impact if you don’t comply with this guideline:

• There will be inconsistencies between the AIM behavior and the AIM repository which will
lead the ZDM procedure to abort.
• If you plan to create new AIMs, please contact LM for further guidance.

© Copyright SAP SE 2017 Internal/Confidential Page 94 of 100

Architecture Guideline S/4HANA

[OC-ZDM-4] Support packages must not contain content of the HANA repository (R3TR NHDU)
like stored procedures, Calculation views etc. defined in the HANA repository. Do
not use native SQL. Use the DDIC-managed CDS views instead.

Background:
For any HANA managed content it is not possible to establish a second DB schema with aliases and
views, representing a different version of the DB table content. This however is needed for the ZDM
procedure and is the basic approach with ABAP managed content.
The ZDM procedure clones DB tables, renames them and accesses them through a different
database schema. Native SQL access might therefore be incompatible with ZDM.
Impact if you don’t comply with this guideline:
• Your support package cannot be deployed with ZDM.
• Your native SQL code might not work correctly during the ZDM procedure.

[OC-ZDM-5] No XPRAs must be applied in releases, product versions, support packages, other
deliveries.

Background:
• XPRAs would need ZDM enablement.
• XPRAs generally are not allowed in support packages and enhancement packages. No
exceptions have been approved for XPRAs in the past years.
Impact if you don’t comply with this guideline:
• ZDM cannot be applied for a support package or enhancement package containing XPRAs

[OC-ZDM-6] No database table conversion via a support package, other deliveries.

Background:
By “conversion”, we mean table conversion by the DDIC converter. The DDIC converter is an ABAP
program. For a DB table that is supposed to be converted, the DDIC converter creates a new DB
table for the target release. Subsequently the content is transferred from the old DB table to the new
one. Finally, the table name of the new table is replaced by that of the old table.
Impact if you don’t comply with this guideline:
Database tables affected by a conversion will be set to a strict read only mode for end users on the
start release. This may harm the availability of functions and applications. (I.e. application
transactions may then end with a short-dump).

[OC-ZDM-7] No structural changes (complex DDL) to very large or very frequently updated tables
except appending a new nullable non-key field (simple DDL).

Background:
ZDM will clone all structurally changed DB tables. This happens in up-time. Cloning such very large
DB tables however takes too much (up-) time. The cloned tables not need to be renamed while being
used by production. This requires an exclusive lock. An exclusive lock on a frequently updated table
can severely affect the productive use of a system.
Impact if you don’t comply with this guideline:
Cloning very large database tables may require all available hardware resources i.e. CPU and
memory. Also DB table locks may reach a critical number and eventually lead dead locks. This can
lead to an effective downtime experienced by the end users.

© Copyright SAP SE 2017 Internal/Confidential Page 95 of 100

Architecture Guideline S/4HANA

[OC-ZDM-8] Avoid import of data through the upgrade or customer transports into very large or
very frequently updated data base tables.

Background:
All DB tables to which data is imported during ZDM are cloned. his happens in up-time. Cloning such
very large DB tables however takes too much (up-) time. The cloned tables not need to be renamed
while being used by production. This requires an exclusive lock. An exclusive lock on a frequently
updated table can severely affect the productive use of a system.
Impact if you don’t comply with this guideline:
Cloning very large database tables may require all available hardware resources i.e. CPU and
memory. Also DB table locks may reach a critical number and eventually lead dead locks. This can
lead to an effective downtime experienced by the end users.

17.2.2 Zero-Downtime-Option of SUM

In order to provide a zero downtime upgrade procedure, in the following called “ZDO-procedure”
(Zero-Downtime-Option of SUM), a number of system architecture and development guidelines have
to be defined. Application development has to follow these guidelines in order to create products
which are upgradeable with zero downtime.

17.2.2.1 Database Schema Layout

On the database, an S/4HANA-ABAP-system consists of
• One database schema holding the database objects (tables, views, stored procedures,
etc.) created and controlled by the ABAP data dictionary and the ABAP workbench. In
the following, this schema is called the ABAP schema.
The physical name (name in the database catalogue) of the ABAP schema is not
defined before a system is installed. At runtime, the name of the ABAP schema can be
found out by calling an API. But at design time, the name is not defined. In particular,
the physical name of the ABAP schema cannot be used as a literal in any source code.
• An arbitrary number of database schemata controlled by HDI (HANA Deployment
Infrastructure), in the following called HDI runtime schemata.
The physical names (names in the database catalogue) of the HDI runtime schemata
are undefined at design time. Applications using an HDI schema define a logical
schema name. At runtime, the physical schema name can be determined by calling an
API (schema mapping).
• _SYS_BIC (XS Classic): There may be ABAP applications which access database
objects in the schema _SYS_BIC. Such applications can also deliver objects for
_SYS_BIC.
During a ZDO upgrade, any access of ABAP applications to database objects in
_SYS_BIC is blocked. I.e. such applications are not usable during a ZDO upgrade.
• A special HDI schema for exposing database objects of the ABAP schema to other
(XSA)-applications which are not part of the S/4HANA-ABAP-system. This schema
holds projection views or synonyms pointing to database objects in the ABAP schema.
The ABAP applications decide which of their database objects shall be exposed to
other applications through this schema.

© Copyright SAP SE 2017 Internal/Confidential Page 96 of 100

Architecture Guideline S/4HANA

ABAP Application Server

Public
ABAP API
ADBC
Program

HANA Database

ABAP Managed Schemata

ABAP Schema Public SQL API

(HDI Runtime
AMDP Schema)
Table
(Proxy)

Proxy for
published
Object
HDI Runtime Schema

Proxy for
CalcView
Table

_SYS_BIC
Legacy
CalcView

Fig. 1: Database layout of an S/4HANA-ABAP-system

There may be other database schemata in the same database instance which do not belong to the
S/4HANA-ABAP-system but e.g. to XSA applications.
Each database schema can either belong to and be managed by the S/4HANA-ABAP-system or can
belong to any other application. S/4HANA and the lifecycle management tools of S/4HANA do not
provide lifecycle procedures, e.g. upgrades, which can simultaneously upgrade S/4HANA-ABAP-
systems together with other XSA applications.

17.2.2.2 Creation of database schemata

• The ABAP schema is automatically created at installation time. Applications can take its
existence for granted.
• HDI runtime schemata: An application can create an HDI runtime schema at design
time. The schema is identified by a logical name which in general differs from the
physical schema name in the database catalogue.
The schema definition shall be transported/delivered as an ABAP transport object. The
installation-, upgrade- and transport tools create the HDI runtime schemata by calling
the appropriate HDI API. During this process, the mapping of logical to physical schema
name (i.e. the schema name in the database catalogue) is persisted in a schema
mapping table provided by the application server infrastructure.
If database objects in an HDI runtime schema A shall access database objects in an
HDI runtime schema B then this fact must be declared as part of the definition of
schema A. Mutual or cyclic access relations are not allowed. (Reason: The access
relations define the sequence for creating the schemata and the objects within the
schemata. Without a defined sequence, the deployment of database objects may fail if

© Copyright SAP SE 2017 Internal/Confidential Page 97 of 100

Architecture Guideline S/4HANA

referenced database objects are not yet deployed.)

17.2.2.3 Allowed database object types

• The ABAP schema may hold all kinds of database objects which can be created and
managed by the ABAP data dictionary and the ABAP development workbench. Other
object types are not allowed. In case of an upgrade, such other object will no longer
work correctly and they may also be deleted during an upgrade.
• The HDI runtime schemata may hold all kinds of non-data-storing database objects
(views, procedures, functions, etc.) which can be deployed and managed with HDI.
Data storing objects like tables are not allowed.
HDI schemata belonging to an S/4HANA system which hold data storing objects cannot
be accessed during a ZDO upgrade. Applications using such HDI schemata will be at
least partially unavailable during a ZDO upgrade.

17.2.2.4 Creating and changing database objects

• ABAP schema: There are the following ways to create and change database objects in
the ABAP schema:
i. Creation of objects at design time: Objects are created at design dime in the
ABAP DDIC or Workbench development system and delivered with the usual
ABAP transport mechanisms.
ii. Creation of objects during an upgrade: Objects can be created by application
defined procedures which are plugged into the upgrade procedures (After-
import-methods, XPRA programs, Switch BADI implementations). In order to
create such objects, applications must use the standard APIs of DDIC and
Workbench.
Executing DDL (data definition language) statements through EXEC SQL or
ADBC (ABAP database connectivity) is not allowed in application code.
iii. Creation of objects at runtime: Database objects can be created at runtime.
Also here, the standard APIs of DDIC and Workbench must be used.
Applications must be prepared that during upgrades no DDIC objects can be
created. (This fact must not restrict the functionality of continuously used
application transactions. Only customizing or development activities may be
restricted during an upgrade.)

• HDI runtime schemata:

i. Creation of objects at design time: Applications can create objects in the HDI
runtime schemata at design time and transport/deliver them with HTA.
ii. Creation of objects during an upgrade: Applications can create or change
objects in the HDI runtime schemata with application defined procedures
plugged into the upgrade. Such procedures must use the HDI API. Executing
DDL statements with EXEC SQL or ADBC is not allowed.
iii. Creation of objects at runtime: Applications can create or change database
objects at runtime by calling the appropriate HDI API. If applications create
database objects at runtime during an upgrade, then they have to be able to re-
create such objects at any time since objects created during an upgrade may
get deleted without warning.

17.2.2.5 Accessing database objects

• ABAP Schema: The ABAP application server is always connected to the ABAP
schema. Therefore, ABAP application code does not need to specify a schema name
when accessing tables in the ABAP schema. The same is true for other database
objects in the ABAP schema (views, SQL procedures, SQL functions, etc.).
• Cross schema access from ABAP to HDI schemata:
Cross schema, only read access is allowed.

© Copyright SAP SE 2017 Internal/Confidential Page 98 of 100

Architecture Guideline S/4HANA

Since the physical schema names are undefined at design time and since the physical
schema names can be subject to change during the lifecycle of an S/4HANA system,
applications must use the schema mapping when accessing database objects in one of
the HDI schemata.
There are two ways of doing this:
i. AMDP as a proxy: In the source code of an AMDP, logical schema names can
be used to access database objects in other schemata. (The application server
replaces the logical with the physical schema name at compile time and makes
sure that AMDPs are re-compiled whenever the schema mapping is changed).
I.e. the recommendation is to create AMDPs as proxy objects for database
objects in other schemata. This avoids the necessity for applications to
explicitly deal with the schema mapping API.
ii. Schema Mapping: Applications can call the schema mapping API at runtime
and find out the physical schema names belonging to their logical schema
names. With the physical schema names, applications can define DML (data
manipulation language) statements and execute them with ADBC.
• Cross schema access from an HDI schema to ABAP or other HDI runtime schemata:
Cross schema, only read access is allowed.
For each database object in a schema B to be referenced from HDI schema A, a
projection synonym or view must be created in schema A that points to the object in
schema B. When developing the synonym or view, the developer specifies the logical
name of schema B.
When deploying the projection view or synonym, HDI shall translate the logical name of
schema A to the physical name of schema A and create the projection views or
synonym with the correct physical name of schema B.
Similarly, in upgrade scenarios, HDI together with the upgrade tools will take care of
correctly modifying the projection views if schemata are cloned.
Cross schema references between two HDI runtime schemata are unidirectional. I.e.
either objects in schema A can access refer to objects in schema B or the other way
around. The fact that there are cross-schema references between two HDI runtime
schemata must be declared in the definition of the referencing schema (see 2b).

17.2.2.6 Non-ABAP XSA-applications

S/4HANA-ABAP-systems may communicate with other (XSA)-applications. There will, however, be
no simultaneous upgrade for S/4HANA-ABAP-systems and non-ABAP (XSA)-applications. I.e. the
interfaces used for communication must be kept compatible between the different releases and
support package levels.
Non-ABAP (XSA)-applications can access (read-only) database objects in the ABAP schema if these
objects are exposed through projection views or synonyms in the special SQL_API-schema defined
in 1.d. Exposed database objects must not be incompatibly changed. During a ZDO upgrade, access
to this special schema can be blocked for a small amount of time.
Non-ABAP (XSA)-application are not allowed to access database objects in the other ABAP-managed
HDI schemata.

© Copyright SAP SE 2017 Internal/Confidential Page 99 of 100

Architecture Guideline S/4HANA

ABAP Application Server XSA Application

Public
ABAP API
ADBC
Program

HANA Database

ABAP Managed Schemata Non-ABAP Managed Schemata

ABAP Schema Public SQL API HDI Runtime Schema

(HDI Runtime
AMDP Schema)
Table Proxy for
(Proxy) View / Proxy for
cross-schema
Procedure table access
access
Proxy for
published
Object
HDI Runtime Schema HDI Data Schema

Proxy for
CalcView Table
Table

_SYS_BIC
Legacy
CalcView

Fig. 2: Database layout of an S/4HANA-ABAP-system together with a connected XSA

application.

© Copyright SAP SE 2017 Internal/Confidential Page 100 of 100