Introduction

SAP Datasphere (DSP), is used by Syensqo to extract data from SAP systems. The data is consolidated for SAP reporting and distribution to MS Fabric for Non-SAP reporting.

Reporting in DSP is performed using the tightly integrated Application Architecture SAP Analytics Cloud.

Both DSP and SAC are now recently incorporated as part of the larger SAP Business Data Cloud offering. SAP will probably try and migrate us to the new product when they are ready.

Purpose

Scope & Objectives

The SAP Analytics and Reporting Approach explains what will be implemented and the SAP Analytics and Reporting Standards details how it will be implemented.

This document explains the landscape and integration of the solution

Requirements

Terminology

• Client: A self-contained, logically-separated 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

Architectural Decisions

Below Table provides the details of the architectural decisions made based on the rationale.

Application Architecture Design

DSP Details

Application Architecture Components

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, DSP etc). 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. CGS will be configured with a public IP which will be used for SAP Cloud Connector connection to SAP BTP and this public IP will be whitelisted in SAP BTP. 

For the proposed landscape see Application Architecture SAP RISE (Rest of the World) and China/US instances

A Replication Flow uses Cloud Connector.

𝗥𝗲𝗽𝗹𝗶𝗰𝗮𝘁𝗶𝗼𝗻 𝗢𝗯𝗷𝗲𝗰𝘁 – The dataset you want to replicate (e.g. CDS View). One object = one flow. Max 500 objects per replication flow

𝗥𝗲𝗽𝗹𝗶𝗰𝗮𝘁𝗶𝗼𝗻 𝗙𝗹𝗼𝘄 𝗝𝗼𝗯𝘀 – These are background workers (also known as worker graphs) that handle the actual data movement. Each job uses 5 replication threads by default.

𝗥𝗲𝗽𝗹𝗶𝗰𝗮𝘁𝗶𝗼𝗻 𝗧𝗵𝗿𝗲𝗮𝗱𝘀 – Distributed working. Think of these as the engines moving your data. Max 50 threads per tenant

𝗗𝗲𝗹𝘁𝗮 𝗟𝗼𝗮𝗱 𝗜𝗻𝘁𝗲𝗿𝘃𝗮𝗹 – How often changes are sent from source to target (0-24hrs and 0-59 mins). Set it to 0h 0m for near real-time.

You must install the SAP Analytics Cloud agent for some import data connections to work

PaPM

SAP PaPM Cloud can integrate with SAP Datasphere by sharing an SAP HANA Cloud runtime database (BYOD), exposing artefacts via DPA

Smart Data Access (SDA) and Smart Data Integration (SDI) enable DSP to consume PaPM Cloud database objects as remote sources. You can expose tables, views, or calculation scenarios within DSP without duplicating data, maintaining real-time consistency across both environments

SAC

DSP can only connect to a single SAC tenant at a time. There is an option to switch tenants

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 DPA agent is required per environment. There is only one active line for the target HANA server name in dpagentconfig.ini.

For the proposed landscape see Application Architecture SAP RISE (Rest of the World) and China/US instances

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. 

Authentication

Authorisation

These values will be leveraged from S/4

Database only users

• Users can also be created for ‘database’ only access
• Such users can read and/or write based on database-level privileges
• Each database user has an Open SQL schema automatically created for them
• Ideal for 3rd party tools that require only view-level access
• Such users can not enjoy Business Layer objects such as Analytical Models
• SAP Analytics Cloud users must connect to SAP Datasphere as regular Application users (i.e. not database-only users)

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

Other Controls

System Landscape

Development Environment

Project Test Environment

Quality Environment

Production Environment

Operation Architecture

Change and Configuration Management

Transport Management

Release Management

Monitoring

Application Monitoring

Data loads will be triggered using Task Chains in DSP and tasks in SAC. Hopefully these SAC tasks will become integrated with the Task Chains in DSP fairly soon as promised in the roadmap.

We will need to ensure that the scheduling of jobs does not overload the system. The closer we get to real-time data, the more frequently jobs are scheduled.

As a replication flow works with a pull mechanism, it is working hard constantly to find and new data, like a continuously executed batch dataflow. In contrast, a push mechanism, only interact when there is new data, would be more efficient. With this is mind, we will only request frequent data updates where really required. 

There are SAP Datasphere monitoring views which help you monitor data integration tasks in a more flexible way. They are built on the V_EXT views, and are enriched with further information as preparation for consumption in an SAP Analytics Cloud story.

Cloud Connector:

There are two main jobs responsible for moving data from the source system to Datasphere:

• Observer job (/1DH/OBSERVE_LOGTAB) When new data is posted in the base table, the Observer job pushes it from the master logging table to the subscriber logging table.
• Transfer job (/1DH/PUSH_CDS_DELTA) The Transfer job then moves this data into the buffer table, from there the replication flow picks it up and pushes it to the target system.

Buffer table

 • It splits large datasets into smaller, manageable data packages.
 • If a package fails, it can be resent, making replication more resilient and reliable.
 • Once a package is successfully written to the target, it’s committed and deleted from the buffer to free up space.
 • It also helps in analysing performance throughput and identifying potential bottlenecks.

Transactions used

• DHCDCMON → Monitor delta capture process
• DHRDBMON → View buffer tables properties and operations
  • Maximum buffer records
  • Current number of records
  • Package size
  • Packages ready for transfer

Replication metadata:

From $TEC schema, import the REPLICATIONFLOW_RUN_DETAILS

Get all TASK Related Data from DWC_GLOBAL schema and view TASK_LOCKS_V_EXT

By building a model on top of these two tables, you can view all the metadata related to your Replication Flows. This helps you track key details like execution time, status, and any errors. So if something goes wrong, you'll be able to quickly identify and understand the issue.

System Monitoring

Sizing

The estimates in the original CD - SOL - 020 Reporting Approach , chapter 8, still hold water

In summary, it was suggested

90GB of data a year was suggested

High Availability

Disaster Recovery

Backup/Restore

Maintenance Plan

Service Introduction

Application Category

Support Team

Skill required

Checklist

Exceptions

See also

Change log

Workflow history