1. Executive Summary |
Back in 2020 and 2021, the use of SAP’s Business Technology Platform (BTP) (Now Business AI Platform, BAIP) was gaining use very rapidly. This caused many growing pains operating the cloud platform. Since then, BTP has undergone significant evolution as SAP's unified Platform-as-a-Service (PaaS) offering, designed to support business-critical workloads with enterprise-grade resilience. SAP takes the enterprise readiness of BTP seriously, investing substantial effort to ensure the platform remains stable, available, and scalable.
Starting in 2021, the Cloud Scale Readiness (CSR) program represents a structured, strategic initiative within SAP's broader enterprise readiness framework, focused on systematically improving platform reliability, scalability, and operational continuity.
One of the pain points during this period was service degradations and outages caused by customers running load tests in the BTP environment. This pointed out some additional areas like monitoring and scalability of the BTP services that needed attention. As a stop gap measure, SAP implemented a required notification of SAP of any upcoming system testing.
Due to the improvements made in BTP over the last number of years from the CSR program and other platform initiatives, the notification step is no longer needed. The remainder of this document provides a summary of the changes the CSR program has implemented as well as some overview information of the testing process for BTP and links to reference documentation.
2. Key improvements in BTP |
Area | Initiatives | Impact |
Reliability | Multi-Availability Zone (multi-AZ) deployments in Cloud Foundry; In-Metro Disaster Recovery (In-Metro DR) with synchronous data replication; SAP Enterprise Readiness program covering HADR, chaos day simulations, and clear outage communication via SAP Trust Center | Fault-tolerance improved by distributing services across multiple AZs; if one AZ fails, unaffected AZs continue handling requests normally; BTP achieves a baseline availability SLA of 99.9% |
Scalability | Automatic runtime scaling introduced in BTP ABAP Environment (release 2402), dynamically adjusting ABAP Compute Units based on actual usage; Application Autoscaler service for Cloud Foundry reacting dynamically to load; horizontal scaling recommended over vertical scaling; microservices architecture enabling independent service scaling | SAP BTP can scale from individual applications to over 500 applications while keeping costs, resources, and maintenance to a minimum; scaling policies configurable by CPU, memory, throughput, and response time metrics |
Downtime Reduction | Zero Downtime Maintenance (ZDM) program actively pursued across BTP services; rolling and blue-green deployment strategies; reduction and harmonization of major upgrade windows; CI/CD pipelines for faster, more reliable deployments | Zero downtime maintenance already achieved for a "very large chunk" of BTP services; ongoing work continues to extend ZDM coverage and harmonize remaining maintenance windows |
3. Cloud Scale Readiness Contributions |
Enterprise Readiness Program Established: SAP created a formal enterprise readiness program encompassing High Availability and Disaster Recovery (HADR), quality and operations testing, and a structured communication strategy for outages via the SAP Trust Center and SAP for Me alerts.
Chaos Day Simulations: SAP introduced "chaos days" - deliberate simulation of failures and issues — to validate that all high-availability mechanisms function as expected under real failure conditions, ensuring platform resilience is not just theoretical.
Zero Downtime Maintenance Program: A dedicated ZDM program was launched to progressively eliminate maintenance-related downtime across BTP services, with ongoing efforts to reduce and harmonize major upgrade windows across the platform.
In-Metro Disaster Recovery (In-Metro DR): A disaster recovery solution leveraging synchronous data replication across multiple availability zones within a single region was introduced, protecting customers from the impact of localized disasters affecting a single AZ. This is offered as a contractual obligation with defined SLA targets.
Centralized Expert Governance Model: SAP established a central team of experts responsible for driving platform governance, compliance, and scalability — identified as the most critical organizational factor learned from over 10 years of running BTP. This model enables multipliers across different areas and provides automation to support true scale.
Application Lifecycle Management (ALM) Harmonization: SAP BTP's ALM capabilities were unified to harmonize CI/CD processes, transport governance, logging, feature rollout, and automated job scheduling — reducing operational risk and accelerating delivery of high-quality updates.
4. Outcomes and Metrics |
99.9% Availability SLA: SAP BTP carries a baseline availability SLA of 99.9% — higher than the 99.7% standard applied to other SAP cloud services — reflecting BTP's critical role as the connective tissue of the SAP ecosystem. Recovery Point Objective (RPO) of ≤ 5 minutes: In-Metro DR guarantees a maximum data loss of no more than 5 minutes in the event of a disaster.
Recovery Time Objective (RTO) of ≤ 2 hours: Full-service restoration is targeted within 2 hours under the In-Metro DR contractual SLA.
Zero Downtime Maintenance Achieved for a Large Portion of Services: The ZDM program has successfully eliminated maintenance downtime for a significant and growing share of BTP services, with harmonization of remaining upgrade windows ongoing.
Automatic Runtime Scaling (from Release 2402): The BTP ABAP Environment now dynamically adjusts compute resources based on actual usage, reducing both over-provisioning costs and under-provisioning risks.
Scale to 500+ Applications: SAP BTP's centralized governance and automation model supports scaling from individual applications to over 500 applications while minimizing cost, resource consumption, and maintenance overhead.
5. Global Infrastructure Expansion — Scalability at the Infrastructure Layer |
Scalability is not only about vertical scaling within a region — it also requires geographic distribution that reduces latency, enables data residency compliance, and provides disaster-recovery options. SAP has had an extensive BTP data-center expansion program across SAP's own infrastructure and all four major hyperscalers (AWS, Azure, Google Cloud, SAP Cloud Infrastructure) in the last 5 years. Below is the current number of data centers by provider.
Provider | Number of Datacenter Locations |
SAP (owned infrastructure) | 16 |
Amazon Web Services (AWS) | 14 |
Microsoft Azure | 14 |
Google Cloud Platform (GCP) | 11 |
Alibaba Cloud | 1 |
Beyond availability, multi-region expansion improves scalability by routing tenant workloads to the geographically nearest data center, reducing inter-region latency and enabling active geographic load distribution.
6. Overview - Load Testing SAP BTP / ABAP Environment |
Load testing SAP BTP and the ABAP Environment is a structured, non-functional testing discipline that measures and validates how BTP-hosted applications and services behave under expected and peak load conditions. The primary goals are to identify performance bottlenecks, validate scalability assumptions, confirm hardware and resource sizing, and ensure that business-critical workloads — such as CAP APIs, Cloud Integration (CPI) iFlows, and ABAP-based services — meet defined response time, throughput, and availability targets before go-live. Because SAP BTP is a managed cloud platform, load testing requires advance coordination with SAP and must follow a controlled, structured process to avoid impacting shared infrastructure and other tenants
Key Steps
Plan and Define Your Test Scope
Begin by identifying the business scenarios and transactions that are critical to your operations — for example, order-to-cash flows, payroll processing, or high-frequency API calls. Define your performance goals clearly, including target response times, acceptable error rates, expected concurrent user counts, and throughput requirements. Document and agree on KPIs and success criteria before any test execution begins. For SAP BTP ABAP Environment sizing, the recommended minimum starting configuration is 1 ABAP Compute Unit (ACU / 16 GB) and 2 HANA Compute Units (HCU / 16 GB each), which can be scaled up or down manually or automatically.
Design and Create Test Scripts
Convert your planned business scenarios into executable test scripts that replicate realistic SAP user behavior. Capture critical transactions (e.g., VA01, ME21N for S/4HANA; API endpoints for CAP applications) and incorporate think time, pacing, and dynamic data handling such as order IDs, timestamps, and search queries. For SAP GUI-based scripts using HP LoadRunner, ensure SAP scripting is activated on all ABAP systems. Use the Init block for one-time login steps, the Action block for the repeating transaction body, and the End block for session close steps. For web-based scripts (SAP Portal, Web Dynpro ABAP), expect significantly more effort due to session management complexity — recording one complex web script can take up to several days due to the need to identify and parameterize unique session IDs. [7]
Validate Data Conditions and Prepare the Test Environment
Before execution, verify that your test environment contains the right type and volume of master and transaction data — customers, materials, orders — in sufficient quantity and realistic distribution. Avoid duplicate data and ensure data dependencies are intact; reset or refresh datasets as needed, since outdated data can produce misleading results. Configure the test environment to match production as closely as possible in terms of system architecture, database size, external integrations, network conditions, and SAP instance versions, modules, and patches. For CAP API load testing, run an initial single-instance test with different memory assignments to establish a baseline of how much traffic one instance can handle before scaling out.
Execute the Test and Monitor in Real Time
Schedule test execution during off-peak hours and announce system unavailability to lock out real users before starting, to avoid interference with results and user experience. During execution, monitor all layers simultaneously — application servers, HANA database, network, and central BTP services. Track key metrics including response time, throughput, CPU utilization, memory consumption, and error rates. For ABAP Environment monitoring, use transaction /OSTATS_FE to identify expensive frontend requests and their server-side KPIs. Leverage SAP Cloud ALM for health monitoring and alerting, Cloud Logging and Application Logging for centralized observability, and the Alert Notification Service for real-time critical event notifications. Dynatrace can also be integrated with BTP (Cloud Foundry / Kyma) for deep application performance monitoring.
Analyze Results, Fix Bottlenecks, and Retest
After execution, correlate metrics across applications, infrastructure, and network layers to pinpoint exactly where issues occur. Identify whether your application is CPU-bound or memory-bound — if neither CPU nor memory is the limiting resource, investigate I/O bottlenecks or wait situations and resolve them before continuing. Prioritize issues by business impact, then tune queries, adjust system parameters, or scale infrastructure as needed. Verify sizing by scaling out: instantiate a second instance of the same size and confirm that approximately twice the throughput is achievable with acceptable response times. If linearity is confirmed, your capacity model is validated. If not, resolve the issue and retest. This is typically an iterative process — fixing one bottleneck may expose another downstream.
7. Additional Best Practices |
Use Persistent Connections (HTTP Keep-Alive): The SAP BTP Cloud Foundry ingress layer includes a defensive connection-rate limiting mechanism that protects platform stability during rare, abnormal load (for example, connection-flood scenarios). It restricts new TCP connections over a short sliding window, and relaxes automatically once the situation normalizes. More details can be found in SAP Note 3801623.
Load tests that open a new TCP (and TLS) connection for every request, or that open too many connections, can trigger this protection, resulting in connections getting dropped, observed as connection-reset errors (ECONNRESET / TCP RST).
To avoid interference with your test results, configure your load tests to use HTTP keep-alive / persistent connections, so that many requests are sent over a small number of long-lived connections rather than one connection per request. This also reduces handshake overhead and generally improves measured throughput.
For CAP APIs: Run single-instance load tests first with varying memory configurations to establish a throughput baseline, then validate scale-out linearity by adding instances.
For Integration Suite / Event Mesh: If performance bottlenecks are encountered, raise a support ticket with SAP to request additional resourcing. For very steep scaling demands, consider running multiple tenants in parallel.
For S/4HANA Cloud (SaaS): Customers are not required to perform infrastructure-level stress or load tests — SAP manages the underlying infrastructure. Only functional tests (unit, string, business process, UAT, data migration) are in scope for customer-side testing.
Continuous Performance Monitoring: Establish automated, repeatable test suites to measure the impact of change releases and major patching on workload performance over time.
Security During Testing: Ensure all load test connections follow corporate security guidelines and that live data access is configured as read-only where applicable
8. Additional Resources |
Building Scalable and Secure Applications with SAP BTP: Best Practices and Tools
Sizing / Capacity Modeling for applications on the SAP Business Technology Platform
Is Your Self-Service Tough Enough? How to beat up on your system and find out.
End-to-End Performance Testing of SAP BTP Cloud Foundry, Kyma and ABAP Environment based Application
How to test the performance of BTP services(EventMesh,CloudIntegration)
SAP S/4HANA Cloud – Achieving faster time to value by reducing non-functional testing efforts
Best Practice 16.6 – Develop mechanisms for simulating production load for analysis purposes
Connection Rate Limiting in the SAP BTP, Cloud Foundry Runtime
Bluesky
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.