Introduction

Purpose

The purpose of the document is to outline the application architecture of S/4HANA instance deployed in Europe region. 

Scope & Objectives

This document describes the high-level architecture design for S/4HANA and the supporting systems that are deployed together in the RISE environment. It will cover the following topics:

• Landscape overview
• Application and components
• Application security and access
• Operational architecture

Out of scope:

• Detailed architecture designs that are managed by SAP RISE.
• RISE operating model.
• Information related to product documentation and can be found online will not be documented here. 

Key Decisions and Requirement

Terminology

• Client: A self-contained unit in an SAP system (technical instance based on ABAP Application Server) with separate master data, transactional data and configurations that are client specific. E.g., Client 100.
• Component: Software modules or add-on that are installed in the instance and enables a specific function. E.g., Fiori, GTS.
• Instance: An entity refers to the entire system including the software and all technical components (DB, application server etc.). E.g., S/4HANA Production.
• SID: Unique identifier for an SAP instance that consists of three characters.
• Environment/Tier: Refers to systems that are used for the different stages of the project lifecycle. Each environment serves a distinct purpose and has a dedicated instance to ensure stability and integrity. E.g., Development, QAS. 
• Landscape: Refers to all the environment for an application or entire project. E.g., S/4HANA landscape, SyWay landscape.

Application Architecture

Overview

SAP RISE application architecture is represented in the diagram below. It will be hosted in Azure and the cloud infrastructure will be managed by SAP.

SAP RISE Details

The table below summaries SAP RISE details. 

Application Components

S/4HANA

S/4HANA is an Enterprise resource planning solution based on SAP HANA database and SAP ABAP platform. It is a core component in SyWay landscape. SAP Fiori and GTS components will be co-deployed with S/4HANA. A two tier deployment approach will be adopted for S/4HANA systems: Application and DB. 

• For Sandbox, Development, Integration testing and Training S/4HANA systems, 1 application and 1 DB server will be deployed.

• For QAS and Parallel Testing S/4HANA systems, multiple application servers will be deployed with 1 DB server.

• For Production, high availability is in scope and S/4HANA components (like message server, app and DB) are deployed across 2 availability zones with pacemaker clusters to ensure no single point of failure. 

CI - Central Instance, SCS - SAP Central Services, PAS - Primary Application Server, AAS - Additional Application Server

Add-ons

The following SAP add-ons are installed in S/4HANA.

SAP Web Dispatcher

SAP Web dispatcher acts as a web proxy for S/4HANA systems. It facilitates and load balances incoming HTTP traffic. 

• For all non-PRD environment, one web dispatcher for each tier will be deployed 
• For PRD, two web dispatchers will be deployed for HA purposes and Azure load balancer will used to load balance HTTP traffic to the 2 PRD web dispatchers.

SAP Cloud Connector

The SAP Cloud connector acts as a reverse invocation proxy to establish network connection between SAP RISE systems and SAP BTP services (Integration suite, API management, SAP Analytics Cloud etc.) and Ariba Cloud Integration Gateway (CIG). Due to its reverse invoke capabilities, the network traffic originates from SAP Cloud connector to SAP BTP and once the link as been established, data can be exchanged between SAP RISE systems and BTP. HTTPS or RFC protocols are used between SAP Cloud Connector and S/4HANA, and HTTPS protocol is used between Cloud Connector and SAP BTP.

To enable outbound internet traffic from SAP RISE, SAP has provisioned a customer gateway server (CGS) with a forward internet proxy installed on it.

A 2 tier landscape will be adopted for SAP cloud connector: non-PRD and PRD. The non-PRD cloud connector will be shared across all non-PRD landscape. 

Data Provisioning Agent

Data Provisioning Agent (DPA) is used for real-time and  batch data replication from S/4HANA to SAP Datasphere. The network connection to SAP Datasphere is initiated by DPA and CGS is used to facilitate the internet connection to SAP Datasphere. 

DPA uses the HTTPS or RFC protocols to communicate with S/4HANA and uses the HTTPS protocol to communicate with SAP Datasphere.   

A 2 tier landscape will be adopted for DPA: non-PRD and PRD. The non-PRD instance will be shared across all non-PRD landscape. 

SAP Analytic Cloud (SAC) Agent

SAC Agent facilitates secure data connectivity and data transfer from S/4HANA to the SAP Analytics Cloud. It leverages SAP Cloud connector connection to BTP to transmit data from S/4HANA to SAC. The HTTPS protocol is used for communication S/4HANA, SAC agent and SAC. 

A 2 tier landscape will be adopted for SAC agent: non-PRD and PRD. The non-PRD SAC agent will be shared across all non-PRD landscape. 

OpenText Connector

OpenText connector facilitates the connection between S/4HANA and the OpenText cloud. The connection is initiated from S/4HANA to the OpenText connector and to OpenText cloud via CGS. The HTTPS protocol is used for communication between all components. 

A 2 tier landscape will be adopted for OpenText Connector: non-PRD and PRD. The non-PRD instance will be shared across all non-PRD landscape. 

Supporting Components (SAP Router and DNS)

These are components deployed to SAP RISE landscape and are managed by SAP. Syensqo users will not have access to these applications and can raise requests to SAP to manage any changes. 

• SAP Router: Single instance deployed in SAP RISE to manage SAP support's connection to Syensqo RISE systems.
• DNS: Three instances deployed in SAP RISE to manage SAP RISE domain and will be integrated with Syensqo DNS using Conditional DNS Forwarding.

System Landscape

The table below describes the environment and the corresponding application & SID deployed. 

The following sections describes the system details for each tier. Please note the following:

• Each VM as a physical hostname (starting with hec*) and 1 or more virtual hostname (starting with vhysq*). 
• The main hostname should be used to connect to the respective systems. 

Sandbox

Development 

Integration Testing

<Place holder>

QAS

<Place holder>

Training

<Place holder>

Parallel Run

<Place holder>

Production

<Place holder>

S/4HANA Client and Transport Strategy

Please see S/4HANA Client and Transport Strategy for client details in S/4HANA.

SAP Best Practices

As discussed in KDD071 - Development System Approach, Best Practices client will be setup using alternative 1 method.

Below are the high level steps on how to setup client 050 and 100 in Sandbox and Development S/4HANA.

1. Configure /FTI/T_NOCLN000 with client 050.
2. Copy client 000 to 050 using copy profile SAP_U000. 
3. Copy client 050 to 100 using copy profile SAP_ALL.

For more details, please refer to SAP help documentation and BP Activation Questionnaire for the list of business function and BP objects that will be activated. 

Application Security

User Access

Default SAP roles will be used for Web dispatcher and connectors. 

Authentication

Single Sign-on (SSO) will be enabled for S/4HANA system. Since other systems in SAP RISE landscape are supporting systems that will not be accessed directly by business users, authentication will be based on user ID and Password. 

SAML SSO - Fiori 

Identity Authentication Services (IAS) within SAP Cloud Identity Services will be configured to act as a Identity provider proxy as shown below.

Following describes the authentication flow.

1. When users access Fiori launchpad, they are redirected to the Entra ID which has been configured as the identity provider in IAS.
2. IAS delegates the authentication to Entra ID.
3. Users will need to sign in to Entra ID using their windows credentials and following the Entra ID authentication process.
4. Using the SAML assertion issued from Entra ID, the user is propagated to IAS.
5. IAS validates the SAML assertions and modifies assertion attributes (if required) before issuing the final SAML assertion.
6. Users are redirected to S/4HANA and will sign in using the issued SAML assertion.

SAPGUI SSO

Single sign-on based on Kerberos

Following describes the authentication flow.

1. User authenticates to Windows domain
2. Entra ID provides Kerberos security token to user
3. User opens a system connection using an SAP GUI desktop client
4. Kerberos token is forwarded to ABAP system using SNC. The Kerberos token is validated offline on the server, no connection to Entra ID required.

OR

Single sign-on based on X.509 certificates

Following describes the authentication flow.

1. User opens an SAP GUI connection.
2. Secure Login Client (SLC) redirects user to the identity provider logon page.
3. Identity Authentication Service delegates authentication to Microsoft Entra ID.
4. Users authenticates to Microsoft Entra ID.
5. After successful authentication, Cloud CA issues an X.509 certificate
6. SAP Secure Login Service returns the X.509 certificate, valid for one day, to SLC
7. X.509 certificate token is used for authenticating the SAP GUI user to the ABAP system

Communication Security

All data in transit will be encrypted.

• SSL is used for all web traffic (Systems are configured to reject HTTP access or redirect to HTTPS). 
• SNC is used for all RFC and SAPGUI communications. 

See DD-TEC-070 Network and Infrastructure Architecture for details on network security and internet connectivity.

Data Security

Data encryption is enable for SAP HANA DB as part of the system provisioning.

NextLabs Data Access Enforcer (DAE) is used to enable field level encryption in S/4HANA. This will encrypt export control relevant data elements and the encrypted values will be stored in HANA DB. Data will be unencrypted on the fly when it is access by an authorized user. For more details please refer to DD-SOL-090 Application Architecture NextLabs.

Other Controls

<Place holder for SEIM integration>

Operation Architecture

Under the shared responsibility model, SAP is responsible for the infrastructure layer to the technical basis layer as shown below. The following section will cover the operational architecture that falls under customer's responsibility.

For the breakdown of detailed tasks and the respective roles and responsibilities, see SAP S/4HANA Cloud, extended edition Roles and Responsibilities for Production.

Change and Configuration Management

Change and configuration management in S/4HANA will be managed through SAP transports. See the following to documents.

• S/4HANA Client and Transport Strategy
• DD-TEC-170 Transport Management

For non-S/4HANA systems, there will be no transport mechanism and changes will be managed manually.

Monitoring

The following can be obtained from SAP for me portal.

• SAP RISE system availability (https://me.sap.com/systemsprovisioning/availability)
• Early watch reports (https://me.sap.com/ewa/workspace)

SAP will be monitoring from the infrastructure layer to the technical basis layer. In the event of an issue, users under Private Cloud Contacts will be notified. 

Sizing

S/4HANA sizing is based on FUE licenses as shown below. For more details, please refer to RISE with SAP S/4HANA Cloud, private edition Service Description Guide in SAP Agreements.

During the course of SyWay project, FUE license will be ramped up from 60 to 1,001 and 4,001 when the project goes lives. Additional infrastructure upgrades are provisioned in the BOM to ensure the following sizing and landscape is maintained at Go-Live.

 All other systems will be provisioned with 8GB VMs.

High Availability & Disaster Recovery

See DD-TEC-140 HA/DR Architecture Design for more details.

Backup/Restore

See DD-TEC-160 Back up and Restore Design for more details. 

Maintenance Plan

The following downtime window is planned for SAP to perform maintenance work that require system downtime. 

Exceptions

See also

• Lean IX for SAP S/4HANA - [ERP] (Rest of World instance)

Change log

Workflow history