Written by Minami — Paddy & Water Inc. / Technology & Platform

SAP Business Technology Platform: Full Picture, Technical Specifications, Constraints, and Implementation Design

June 2026

Introduction: Why BTP Was Born

Since the 2000s, SAP has rolled out cloud applications such as S/4HANA, Ariba, SuccessFactors, and Concur as independent SaaS offerings. However, this architecture of “independent clouds per product” brought serious problems for enterprises. Data between applications became siloed, integration became costly, and the foundations for AI and data analytics were fragmented. In addition, ABAP customizations that modified core systems such as S/4HANA became an “upgrade barrier,” preventing companies from enjoying the benefits of SaaS (automatic upgrades and cloud scale).

SAP BTP (Business Technology Platform) is the “technology integration foundation” born to solve this challenge. It consolidates four capabilities—application development, integration, data analytics, and AI—into a single platform, and is positioned as the “digital core” connecting SAP’s product portfolio with a company’s own systems.

This article goes in depth into the “architecture, technical specifications of each service, constraints, cost structure, and implementation patterns” needed to deeply understand BTP. Its purpose is to provide practical decision criteria for questions such as “what can and cannot be done with BTP” and “which service should be used, and when.”

1. The Structure of SAP BTP: Account Hierarchy and Billing Model

The Three-Tier Structure of Global Account, Directory, and Subaccount

BTP’s management unit is composed of a three-tier hierarchy: “Global Account → Directory → Subaccount.” Understanding this hierarchy is the starting point for BTP governance design.

• Global Account: The contractual unit with SAP. Entitlements (usage rights/licenses) are assigned here. The Global Account Administrator holds administrative rights over all subaccounts. It is rare for a single company to hold multiple global accounts, but this can become an issue during the integration of subsidiaries or M&A targets.

• Directory: An intermediate management layer (optional) that groups subaccounts. Directories are designed according to management units such as “by business division,” “by environment (development/testing/production),” or “by region.” Entitlements can also be assigned to a directory (evenly distributed to child subaccounts).

• Subaccount: The actual unit of use and deployment for BTP services. Each subaccount has its own independent region (data center location), environment (Cloud Foundry / Kyma / ABAP), and security settings. It is standard practice to create separate subaccounts for development, testing, and production.

How Entitlements and Service Plans Work

To use a BTP service, an “Entitlement” must be granted to the global account and then assigned to a subaccount. An entitlement is a definition of “the services available and their quantity/plan” as determined by the contract with SAP.

Each BTP service has multiple “Service Plans,” and the scope of functionality, resource limits, and billing method differ by plan.

• Free plan: A free tier for development and PoC purposes. Not for production use, with performance limitations and no SLA. A common pattern is to move to a paid plan after a PoC on the free plan.

• Standard plan: A paid plan for production use. Full feature set with SLA guarantees (e.g., availability of 99.9% or higher).

• Premium plan: High performance, large capacity, and additional features (only for some services).

Consumption-Based Billing Model (CPEA / BTPEA)

BTP’s billing models fall broadly into two types: “Consumption-Based” and “Subscription-Based.”

• CPEA (Cloud Platform Enterprise Agreement): The former name for the consumption-based contract. A credit pool is purchased for the global account, and the usage-based amount of BTP services actually consumed is deducted from the credits. While this offers the flexibility of not incurring costs for unused services, it can be difficult to predict the rate of credit consumption, creating a risk of unplanned cost increases.

• BTPEA (BTP Enterprise Agreement): The successor model to CPEA from 2023 onward. The basic structure remains consumption-based like CPEA, but the scope of covered services has been expanded and the validity period settings for purchased credits have been improved.

• Subscription: A method of contracting for a specific service at a fixed price and fixed volume on an annual basis. When volume is predictable—such as the number of messages in Integration Suite or the number of workflow instances in Build Process Automation—a subscription is easier to manage from a cost perspective.

An important point for cost management is that real-time monitoring of consumption by service, via the “Cost & Usage” screen in the BTP Cockpit, is essential to operations. In particular, if developers are free to enable services on their own, unexpected credit consumption can occur. Cost control through setting upper limits (Quotas) on entitlement volumes at the subaccount level is recommended.

2. Runtime Environments: A Technical Comparison of Cloud Foundry, ABAP, and Kyma

The Roles and Selection Criteria of the Three Runtime Environments

BTP has three runtime environments, and they are used differently depending on the nature of the extension application being developed, the skills of the development team, and future maintainability. It is also common to use multiple of the three simultaneously within a single architecture.

Cloud Foundry Environment (CF)

Cloud Foundry (CF) provides application deployment, scaling, and lifecycle management as a PaaS (Platform as a Service). It has the longest history within BTP, and the largest number of BTP services (Integration Suite, certain components of SAP Work Zone, etc.) run on CF.

• Supported languages/frameworks: Java (Spring Boot, TomEE), Node.js, Python, Go, Ruby. Each language environment is automatically configured via a middleware configuration template called a “Buildpack.”

• Memory/CPU management: Memory allocation (e.g., 512MB, 1GB) is configured per application. Scale-out is achieved by the number of “Application Instances” (horizontal scaling). Vertical scaling (changing instance size) requires an application restart.

• CF constraints: There are execution time limits on containers (not suited to disk I/O or long-running batch processing), the file system is ephemeral (reset on restart), and inter-container communication is HTTP/HTTPS only (socket communication is generally not possible).

• Service binding: BTP services such as databases, message queues, and authentication are connected to an application via “Service Binding.” Connection information (connection strings, credentials) is automatically injected into the CF environment variable “VCAP_SERVICES.”

ABAP Environment (the ABAP Cloud Environment)

ABAP Environment is an environment for executing ABAP code on BTP. Unlike on-premise S/4HANA ABAP, only a restricted ABAP subset called “ABAP Cloud (Steampunk)” can be used.

• Restrictions of ABAP Cloud: Much of what was usable in traditional ABAP—such as Function Modules, BAPIs, direct DDIC access to internal tables, and direct access to the transport layer—is unavailable or deprecated in ABAP Cloud. Instead, development using the RESTful ABAP Programming Model (RAP), CDS (Core Data Services), and Business Services (OData V4) is the standard.

• The RAP model: The Restful ABAP Programming Model is the core framework for ABAP application development on BTP. A data model is defined via a CDS View, business logic (CRUD, actions, validation) is implemented via a Behavior Definition, and an OData V4 API is automatically exposed via a Service Definition. It has strong affinity with the Fiori Elements UI, and its productivity—where list, detail, and edit screens are automatically generated just from the data model definition—is a key characteristic.

• Code sharing with on-premise S/4HANA: To port on-premise S/4HANA ABAP code to ABAP Cloud, an “ABAP Test Cockpit (ATC)” compatibility check for ABAP Cloud must be performed, and incompatible APIs must be replaced. A constraint here is that porting large existing ABAP codebases often requires considerable effort.

Kyma Environment (Kubernetes)

Kyma is a “Kubernetes (k8s)-based container runtime environment.” Among BTP’s runtimes, it offers the greatest infrastructure-level flexibility, allowing containerized microservices to be deployed in any language or framework.

• Architecture: An SAP-managed Kyma Kubernetes Cluster is provided. Users deploy applications via Helm Charts and Kubernetes Manifests (YAML). An Istio service mesh (traffic management, mTLS communication encryption, observability) is included by default.

• Eventing: Kyma applications can receive events from S/4HANA or BTP services via SAP Event Mesh (described later) or Kyma’s native Eventing (based on the NATS/CloudEvents standard). This enables an event-driven architecture where, for example, “a Kyma application is triggered in real time when a Business Partner (BP) is created in S/4HANA.”

• Scaling: Autoscaling via Kubernetes HPA (Horizontal Pod Autoscaler) and scale-to-zero (reducing pods to zero when idle to cut costs) are available. However, a cold start from a scaled-to-zero state incurs a delay of several seconds to tens of seconds.

• The difficulty of Kyma: Among the three runtime environments, Kyma demands the most infrastructure knowledge (Kubernetes, Docker, Helm). If SAP BTP developers lack Kubernetes skills, either Cloud Foundry should be chosen preferentially, or the learning cost of Kyma must be built into the implementation plan.

Guidelines for Selecting a Runtime Environment

The selection criteria for the three environments can be summarized as follows.

• Cloud Foundry: Standard web API/UI application development in Java or Node.js. Situations requiring support for BTP services (such as Integration Suite). Cases where the development team lacks Kubernetes knowledge.

• ABAP Environment: Cloud porting of existing logic developed in standard SAP ABAP. Cases where custom OData APIs of S/4HANA are exposed. Cases where the development team is primarily composed of developers with ABAP skills.

• Kyma: Cases requiring a microservices architecture, container-first design, event-driven real-time processing, or development in any language (Python/Go/Rust, etc.). Workloads unsuited to CF, such as long-running batch jobs or GPU computing.

3. SAP Integration Suite: Details of the Integration Middleware

Overview of Integration Suite Components

SAP Integration Suite (IS) is a service set that serves as the core of BTP’s integration capabilities. It provides integration between enterprises and SAP, non-SAP, on-premise, and cloud systems regardless of type. It is positioned as an integration platform (iPaaS) delivered as a service.

Cloud Integration (iFlow): Details of Integration Flows

Cloud Integration (formerly known as HCI / SAP Cloud Platform Integration) is an engine for graphically designing and executing integration processing flows called “iFlows (Integration Flows).” An iFlow is a BPMN 2.0-like design tool with a structure of “inbound adapter → processing steps → outbound adapter.”

Adapter Types and Constraints

There are more than 70 types of adapters (connectors) that an iFlow can connect to. The major adapters and their technical characteristics are shown below.

• HTTPS/REST: The most general-purpose. Supports data retrieval via REST APIs, webhooks, and polling. Supports OAuth 2.0, API keys, and Basic authentication.

• SFTP/FTP: File-based integration with legacy systems. Configures “polling interval, file pattern (*.csv), and deletion/archiving after processing.” SFTP private key authentication is also supported.

• IDoc (SAP): An adapter specialized for sending and receiving IDocs to/from S/4HANA. An IDoc type is specified and connected to an S/4HANA RFC destination. IDoc parsing, transformation, and error handling can be controlled within the iFlow.

• OData: CRUD operations via OData V2/V4. Used to connect to SAP and non-SAP OData APIs. OData features such as batch requests and $expand can also be used.

• AS2 (EDI): An encrypted, signed communication protocol used for B2B electronic commerce (EDI). Automatic exchange of e-commerce documents (purchase orders, invoices) with trading partners.

• AMQP/Kafka: Asynchronous integration with message queue brokers (Azure Service Bus, AWS SQS, Apache Kafka, etc.). Used for high-throughput, highly available event integration.

As a constraint on adapters, it should be noted that “not all adapters are available on all service plans.” Some adapters available in the Enterprise edition may be blocked on the Standard plan or in a Trial. It is necessary to confirm before project kickoff that the adapters planned for use are included in the entitlement.

iFlow Processing Steps: Transformation, Routing, and Error Handling

The major types of processing steps available within an iFlow are shown below.

• Message Transformation: XML⇔JSON conversion, message mapping (Graphical Mapping, XSLT, Groovy Script), Content Modifier (adding/modifying headers and properties), and Filter (extracting only elements that match a condition).

• Routing: “Content-Based Router (switches the destination based on message content),” “Splitter (splits a large message into multiple smaller messages),” “Aggregator (combines multiple messages into one),” and “Multicast (sends the same message to multiple destinations in parallel).”

• Persistence: “Persist (intermediate storage of a message),” “Data Store (temporary key-value storage),” and “Local Variable (variable management during iFlow execution).” Data Store is used to implement throughput aggregation, deduplication, and idempotency processing.

• Error handling: An iFlow defines its behavior on error via an “Exception Subprocess.” Retry settings (maximum retry count, retry interval), a dead-letter queue (quarantine after the retry limit is reached), and alert notifications (email, SAP Alert Notification) can be configured.

A Hands-On View: Designing and Operating an iFlow

The basic flow for designing and deploying an iFlow within Integration Suite is shown below.

• Creating a Package: An “Integration Package” is created to group integration scenarios. Artifacts such as iFlows, Message Mappings, and Value Mappings are stored within the package.

• Designing an iFlow: An iFlow is added via “Add” → “Integration Flow” and designed in a web-browser-based UI editor. Adapters and processing steps are placed via drag-and-drop from the palette, and detailed settings for each step (endpoint URL, authentication method, transformation logic, etc.) are entered in the properties panel.

• Simulation: Before deployment, the processing of an iFlow can be simulated with test messages. Debugging is made more efficient by visualizing the input/output messages of each step.

• Deployment: The “Deploy” button deploys the iFlow to BTP. Deployment is executed as a container (OSGi bundle) on CF. Once deployment is complete, an endpoint URL is issued, enabling calls from external systems and periodic triggering via a scheduler.

• Monitoring: “Monitor > Integrations” allows real-time confirmation of the status of running, completed, and errored message processing. Detailed error logs (received data, transformed data, error stack traces) can be checked for debugging.

API Management: Details of the API Gateway

API Management (APIM) is an API gateway for “managing, protecting, publishing, and monetizing” an enterprise’s APIs. By exposing OData APIs from S/4HANA and BTP services externally via API Management, authentication, rate limiting, analytics, and version management can be managed centrally.

• API Proxy: A proxy is placed in front of the backend API, and policies are applied. Policies are classified into four categories: “Security (OAuth authentication, API key verification, IP restriction),” “Traffic Management (rate limiting, quotas, spike arrest),” “Mediation (request/response transformation, header manipulation),” and “Extension (Groovy/JavaScript execution).”

• Developer Portal (API catalog): A self-service portal for API consumers (internal developers, external partners). It allows for viewing API specifications (OpenAPI/Swagger), running tests, and applying for API key issuance. It is used to build an API ecosystem (publishing partner APIs, promoting internal API adoption).

• API Analytics: A dashboard for analyzing API usage, including the number of API calls, response times, error rates, and traffic by consumer. SLA monitoring and anomaly-detection alert settings can be configured.

• Constraints: The rate-limit and quota settings in API Management are configured at the API Proxy level. A global rate limit spanning multiple API proxies (a total cap on API calls across all users) cannot be configured. Additionally, management of GraphQL APIs is only supported to a limited extent.

Event Mesh: Technical Details of Event-Driven Integration

SAP Event Mesh is BTP’s message broker. It provides publishing, subscribing, and persistence of events compliant with the CloudEvents standard.

• Message queues and topics: Event Mesh supports two messaging models: “Queue” (point-to-point delivery) and “Topic” (Pub/Sub delivery). With a Queue, a sent message is delivered to a single recipient. With a Topic, multiple subscribers can receive the same message (fan-out).

• Integration with S/4HANA: From S/4HANA 2020 onward, the “Business Events” feature automatically publishes business events—such as the creation or modification of a Business Partner, or the confirmation of an order—to an Event Mesh Topic. Kyma or Cloud Foundry applications can receive these events in real time and execute reactive processing.

• Message persistence: Event Mesh persists messages for a configurable period. Messages published while a subscriber was temporarily down can be received later. This “At-Least-Once” delivery guarantee increases the reliability of asynchronous processing.

• Constraints: The maximum message size (1MB by default), queue depth (the maximum number of retained messages), and throughput limits for Event Mesh vary by service plan. Event Mesh is not suited for transferring large files, and a combination with SFTP/Object Storage is required for that purpose.

Open Connectors: Connecting to Non-SAP Systems

SAP Open Connectors provides standard connectors for more than 170 SaaS products, including Salesforce, ServiceNow, Slack, Box, Google Drive, and HubSpot.

The distinguishing feature of Open Connectors is that it “normalizes each SaaS’s API and exposes it as a unified API.” For example, Salesforce and HubSpot each have different API designs, but by going through Open Connectors, either CRM can be accessed using the same API design. Combined with integration via iFlow, an integration flow that “synchronizes data from an external SaaS to S/4HANA” can be built using standard connectors.

As a constraint, the connectors provided by Open Connectors are centered on “read and basic CRUD” operations, and advanced features of the connected SaaS (batch APIs, webhooks, etc.) require individual confirmation of support status. Additionally, the timing of updates to keep pace with connector specification changes is a constraint, as it depends on SAP’s response speed.

4. SAP Build: Details of the Low-Code Development Platform

Technical Details of SAP Build Apps

SAP Build Apps (formerly AppGyver) is a visual development tool for building web and mobile applications with no-code to low-code development.

• UI components: More than 200 UI components (buttons, tables, forms, charts, maps, etc.) that can be placed via drag-and-drop are provided. Custom CSS and custom JavaScript (Formula functions) can also be injected, enabling customization beyond the limits of no-code.

• Data connections: Data from S/4HANA or external systems can be retrieved and updated in real time via OData V2/V4, REST APIs, GraphQL, and BTP Destinations (connection settings). Integration with CAP applications (SAP Cloud Application Programming Model) on BTP offers the highest degree of integration and is recommended.

• Business logic: “Flow Functions” (processing flows) are defined visually. IF/Else branching, loops, variable manipulation, API calls, and error handling are described using a visual flowchart. JavaScript Formula functions are used for more complex logic.

• Mobile output: In addition to web browsers, apps can be built and distributed as iOS and Android apps. OTA (Over-The-Air) updates allow app content to be updated without resubmitting to app stores.

• Constraints: Build Apps supports offline capabilities (offline data caching, queued storage of offline operations), but designing complex offline scenarios (differential synchronization of large record volumes, conflict resolution) presents many challenges. It also does not support highly advanced 3D visualization or real-time AR features.

Technical Details of SAP Build Process Automation (SBPA)

SAP Build Process Automation (SBPA) is a service that integrates workflow automation with RPA (Robotic Process Automation). Business process approval flows, task management, and bot automation can all be designed and operated on a single platform.

How Workflow Management Works

• Process design: Workflows are designed with a BPMN-like visual editor. This combines “user tasks (approval, input),” “automated steps (API calls, conditional branching),” “parallel branches (simultaneous assignment to multiple approvers),” and “timers (due-date alerts, escalation).”

• Form designer: The “input form” displayed for a user task within a workflow is designed with no code. Field types (text, number, date, choice, attachment), validation, and conditional display (showing a field only under certain conditions) can be configured.

• My Inbox (task portal): Approvers process pending approval tasks from the My Inbox of SAP Build Work Zone or from a mobile app. A simple UI provides a task list, task details, and approve/reject/forward operations.

• Process Visibility: The status of currently running workflow instances (at which step they are stalled), history of past executions, average processing time, and bottleneck analysis can all be checked on a dashboard.

Technical Details of RPA (Desktop Automation)

• SAP’s RPA is composed of two components: “Cloud Studio” (bot design) and “Desktop Agent” (bot execution). Desktop Agent is agent software installed on the PC that executes the bot.

• Automation targets: Automation scenarios are created by recording screen operations (Record & Play). Web browsers (Chrome/Edge), Windows desktop applications, SAP GUI, Excel, and PDF operations can be automated.

• SAP GUI automation: Automated operation of SAP GUI (transaction screens such as BEx, SE11, ME21N, etc.) is specifically supported by the “SAP GUI Automation” component. Because on-screen elements (fields, buttons, table rows) are identified by their Technical Name (ID), robustness against screen layout changes is high.

• Constraints: RPA bots run only on a PC where the Desktop Agent is running. If the PC is shut down or locked, the bot stops. Always-on server-side execution requires running the Agent on a VM (Virtual Machine). In addition, automating screens that require CAPTCHA or multi-factor authentication (MFA) is difficult.

SAP Build Work Zone: Details of the Digital Workplace

SAP Build Work Zone (formerly SAP Launchpad Service) is a “digital workplace” that consolidates SAP Fiori apps, BTP apps, external web apps, and content (news, knowledge articles) into a single portal screen.

• Site Designer: The portal UI (Site) of Work Zone is designed with no code. Pages, sections, cards, and widgets are placed via drag-and-drop, and page personalization according to role is configured.

• Business content integration: Links to Fiori apps in S/4HANA, custom apps on BTP, analytics dashboards in SAP Analytics Cloud, and the respective portals of Ariba and SuccessFactors are consolidated. By logging into Work Zone, users gain a single access point to multiple systems.

• My Inbox integration: SBPA workflow approval tasks and S/4HANA workflows (equivalent to SWDD/SWI5) can be displayed together in Work Zone’s My Inbox, achieving one-stop consolidation of approval work.

• Constraints: Functionality differs greatly between the “Standard” and “Advanced” editions of Work Zone. Many features are available only in the Advanced edition (custom content via Page Builder, HR integration, Microsoft 365 integration, AI-recommended content). Care is needed when selecting a licensing plan.

5. SAP HANA Cloud: Details of the Cloud Data Platform

The Architecture and Characteristics of HANA Cloud

SAP HANA Cloud (HC) is a cloud-native DBaaS centered on an in-memory, column-oriented database. It is positioned as the cloud version of on-premise SAP HANA (the database underlying S/4HANA), but its architecture differs substantially.

• Separation of compute and storage: HANA Cloud adopts an architecture in which compute (CPU/in-memory) and storage (disk) are separated. Data is automatically tiered into three layers—hot data (in-memory), warm data (disk), and cold data (object storage)—via “Native Storage Extension (NSE).” This maintains high-speed querying while keeping down the cost of loading all data into memory.

• Multi-model: Multiple data models—relational (SQL), graph (Cypher/SPARQL), spatial (Spatial/GIS), and document (JSON)—are handled by a single database engine. Graph analysis and spatial analysis can be executed in a single query combined with SQL.

• HANA Cloud Data Lake (QRC): An architecture in which cold data is stored in SAP HANA Data Lake (HDL) and linked via SQL through HANA Cloud. This retains large volumes of historical data at low cost while still allowing JOIN queries to be executed on HANA Cloud as needed.

• Extension model: Connections from BTP applications (such as CAP applications) to HANA Cloud go through an HDB (HANA Database) driver. Drivers are provided for Node.js (@sap/hana-client), Java (NGDBC), and Python (hdbcli).

Integration of CAP Applications on BTP with HANA Cloud

The “SAP Cloud Application Programming Model (CAP)” is an application development framework for BTP. CAP is written in Node.js (the cds npm package) or Java (a Spring Boot extension) and deployed to CF/Kyma on BTP.

CAP is designed to use HANA Cloud as its native database. When a data model is defined using CDS (Core Data Services), the table DDL for HANA Cloud is automatically generated, and an OData V4 API is automatically exposed. A key characteristic is the RAD (Rapid Application Development)-style development efficiency of “define the data model → the API is generated automatically.”

• Multi-tenancy: CAP is also used as the development framework for BTP’s multi-tenant SaaS extension applications. Tenant isolation is achieved through schema separation in HANA Cloud (an independent schema per tenant). It is the standard framework used by SAP’s ISV partners when building SaaS products on BTP.

• Constraints: While CAP’s productivity is high, directly leveraging HANA Cloud-specific advanced features (such as Advanced Analytics views and Calculation Views) from CAP’s CDS requires a mixed design involving HDB artifacts (.hdbtable, .hdbcalculationview, etc.), which increases design complexity.

SAP Datasphere: Details of the Data Fabric

SAP Datasphere (formerly SAP Data Warehouse Cloud) is a data fabric platform that centrally manages data integration, data modeling, data virtualization, and data sharing.

• Business Data Fabric: Datasphere integrates multiple data sources—such as SAP HANA Cloud, S/4HANA, Azure Synapse, Snowflake, and Databricks—as “virtual tables (Remote Tables).” SQL/Analytics Views spanning multiple databases can be created without actually moving the data (data virtualization).

• Migration support via SAP BW Bridge: A “BW Bridge” feature is provided to support migration from SAP BW to Datasphere. Tools are available to convert BW InfoObjects and BW Queries (BEx) into Datasphere entities, allowing existing BW investments to be migrated to the cloud in stages.

• Knowledge graph (Business Layer): Datasphere’s Business Layer automatically imports the semantics (business meaning) of SAP applications (S/4HANA, Ariba, SuccessFactors). Business concepts such as “supplier,” “sales order,” and “profit and loss” are automatically reflected in the data model, allowing business analysts to understand and use data without knowing technical table names.

• Integration with SAC (SAP Analytics Cloud): When Datasphere is configured as a live connection target for SAC, Datasphere’s models can be referenced in real time from SAC Stories/Planning. Data access controls on the Datasphere side (row-level security) are also applied transparently on the SAC side.

• Constraints: Datasphere’s data virtualization (Remote Table) delegates a query to the remote data source every time it is executed. The performance of the remote database constrains query performance. For ad-hoc analysis of large data volumes, a design that ingests data into Datasphere’s local storage via data replication (Replication Flow) is more suitable.

6. Details of BTP’s Security and Identity Management

Details of SAP Identity Authentication Service (IAS)

SAP IAS (Identity Authentication Service) is BTP’s identity provider (IdP). It provides single sign-on (SSO) to SAP cloud products such as BTP, S/4HANA Cloud, Ariba, and SuccessFactors.

• SAML and OpenID Connect: IAS supports both the SAML 2.0 and OpenID Connect (OIDC) protocols. OIDC (Authorization Code Flow) is the predominant method for SSO to BTP applications. SAML is also used in some cases for SSO to the SAP Fiori Launchpad or BTP services.

• Integration with corporate IdPs (Proxy): An internal Active Directory (Microsoft Entra ID, formerly Azure AD), Okta, or other corporate IdP can be used via IAS’s proxy configuration. Users authenticate with the corporate IdP and are then routed through IAS for SSO to BTP services. This configuration achieves a separation of responsibilities in which “user identity management is left to the existing corporate IdP, and SSO to the SAP cloud is handled by IAS.”

• MFA (multi-factor authentication): IAS supports MFA via TOTP (such as Google Authenticator), SMS OTP, and biometrics (FIDO2/WebAuthn). Policies can be configured to enforce MFA for access outside of specific applications, specific user groups, or specific IP ranges.

• Risk-based authentication: “Risk-based authentication,” which automatically raises the level of authentication required according to the risk level of the access (access from an unknown IP, access from overseas, access outside working hours, etc.), is supported.

SAP Authorization and Trust Management (XSUAA)

SAP XSUAA (Extended Services User Account and Authentication) is BTP’s OAuth 2.0 authorization server. It manages the verification of access tokens (JWTs) issued by BTP applications, scope management, and the binding of users to Role Collections.

• Role, Role Collection, and Scope: Access control for BTP applications is structured in four layers: “Scope (the smallest unit of permission) → Role (a collection of Scopes) → Role Collection (a collection of Roles) → User/Group (assignment of Role Collections).” Application developers define Scopes, and administrators assign Role Collections to users.

• Authorization between applications (OAuth Client Credentials): M2M (Machine-to-Machine) authentication between BTP applications, or from a BTP application to an S/4HANA API, uses the “OAuth 2.0 Client Credentials Flow.” XSUAA issues an access token for a client ID/client secret, and the API gateway verifies the token.

• Principal Propagation: For API calls from BTP to S/4HANA, a Principal Propagation setting can be configured to “propagate the ID of the user logged into the BTP application through to the S/4HANA side.” This ensures audit traceability, so that a record of an operation performed on S/4HANA from a BTP application is left in the S/4HANA change documents under the actual user’s ID.

Destination Service: Details of Connection Management

Destination Service is “a service that centrally manages connection settings (credentials, endpoint URLs) for applications on BTP to connect to external systems (S/4HANA, Ariba, external REST APIs, etc.).”

Connection settings (Destinations) are managed at the subaccount or instance (application instance) level, eliminating the need to hard-code connection URLs or credentials within application code. By defining different connection targets under the same Destination name for each environment (development, testing, production), environments can be switched without changing code.

• Authentication types: Basic authentication, OAuth 2.0 (Client Credentials, Authorization Code, SAML Bearer Assertion), Certificate (client certificate), and Principal Propagation are supported.

• On-premise connections (SAP Connectivity Service + Cloud Connector): When a Destination is of the “On-Premise” type, connections from BTP to an on-premise system (on-premise S/4HANA, an internal REST API, etc.) go through a “Cloud Connector (SCC).” SCC is proxy software installed on the internal network that establishes an encrypted tunnel between BTP and the on-premise system. Because it uses a “reverse tunnel” method that does not require opening ports toward the internet, it is a connection method with fewer network security concerns.

• Constraints: Destination Service manages the list of Destinations at the subaccount level. In large-scale environments with many connection targets, management becomes cumbersome unless naming conventions, version control, and change tracking for Destinations are designed in advance. Using the BTP CLI / BTP Terraform Provider to manage Destinations as IaC (Infrastructure as Code) in a source code repository is recommended.

7. Clean Core Strategy: Design Principles for Extension with BTP

What Is Clean Core: SAP’s Technology Strategy

“Clean Core” is a design principle for extension architecture promoted by SAP, aimed at not “contaminating” the standard code of S/4HANA. In traditional SAP implementations, “modifications” that patched or added ABAP code to fit business requirements had become the norm, with large volumes of overwrites to SAP standard code (via exits, BAdIs, enhancement spots) being made.

The accumulation of such modifications has become the greatest barrier to migrating to S/4HANA and to regular upgrades (SAP S/4HANA has one major update per year). The Clean Core strategy is a policy of “keeping the core code of S/4HANA standard, and performing all extensions outside of it, on BTP.”

Extension Patterns and Technology Selection in Detail

Three patterns are defined for Clean Core-compliant extensions.

• In-App Extension: An extension within S/4HANA that uses only ABAP Cloud APIs (Released APIs, Business Object Interfaces). Custom objects are added to S/4HANA using the RAP model of ABAP Cloud. Because it does not modify S/4HANA standard code and stays within the scope of Released APIs, it is unaffected by upgrades. However, it carries the constraint that “access to business logic that is not exposed as a Released API is not possible.”

• Side-by-Side Extension: A method in which an application on BTP (such as a CAP application or Build Apps application) extends functionality by calling S/4HANA’s public OData/RFC APIs. It is managed as code completely independent of S/4HANA and is unaffected by S/4HANA upgrades. It is suited to adding complex UIs, external system integration, and AI features. This is the extension method most aligned with the Clean Core principle.

• Developer Extension (ISV/partner extension): A format in which SAP partners and ISVs build SaaS extension products on BTP and offer them via the SAP App Center. Customers can add a partner’s value-added features via subscription while maintaining the standard.

Managing Released APIs and Unreleased APIs

The greatest challenge in a Clean Core-compliant implementation is confirming the scope of “S/4HANA’s Released APIs (the official list of supported APIs).”

The list of S/4HANA’s Released OData APIs, BAPIs, and CDS Views can be checked on the SAP API Business Hub (api.sap.com). However, cases where “a function required by a business requirement is not included in the Released APIs” occur frequently in actual implementations. In such cases, the options are: (1) extend the standard functionality’s configuration and expose it as an API using S/4HANA’s extensibility features (Key User Extensibility); (2) check whether a solution exists in SAP Support Notes; or (3) temporarily compromise on the Clean Core principle and cover the gap with an In-App extension (planning a future refactoring).

SAP expands the scope of Released APIs every year, and there are increasing cases where business requirements that could not be met in the past are now exposed as APIs. Rather than aiming for a “perfect zero modifications,” the important thing regarding the degree of Clean Core compliance is to set a realistic goal that combines “an S/4HANA core free of modifications (quantitative management of a modification score)” with “a plan to replace functionality on the BTP side.”

8. SAP AI Services and GenAI Hub

Overview of AI Services on BTP

SAP provides AI-related services on BTP as “SAP AI Core, SAP AI Launchpad, SAP Generative AI Hub, and individual AI services (Document Information Extraction, Business Entity Recognition, etc.).” BTP functions as the AI infrastructure for the entire SAP application portfolio.

SAP AI Core: Details of the Machine Learning Foundation

SAP AI Core is an MLOps platform that executes the training, deployment, and inference of machine learning models. It runs on the Kyma (Kubernetes) foundation on BTP.

• Workflow: An ML pipeline (data preprocessing → model training → model evaluation → model registration) is defined using the Kubernetes-native “Argo Workflows.” Training on GPU-enabled Kubernetes nodes is possible.

• Deployment: A trained model is exposed as a REST API endpoint. A/B testing of models, canary releases, and scaling (automatic scaling according to request volume) can be managed.

• Model registry: Version management and metadata (accuracy metrics, training dataset, hyperparameters) of trained models are recorded. Evaluation comparison and promotion of models (from dev to prod) can be operated from the SAP AI Launchpad UI.

• Constraints: Because SAP AI Core is built on a Kubernetes foundation, MLOps experience and Kubernetes knowledge are required. Use of GPU-equipped instances requires a separate cost and quota application. The availability of GPU nodes in the Japan region (jp10) should be confirmed in advance.

SAP Generative AI Hub: A Multi-LLM Platform

SAP Generative AI Hub is a service that centrally manages access to multiple LLM (Large Language Model) providers. It supports providers such as OpenAI (GPT-4o, etc.), Anthropic (Claude, etc.), Google (Gemini, etc.), Meta (Llama, etc.), and MistralAI, allowing models to be switched between using a single API (the GenAI Hub API).

• Governance of LLM access: GenAI Hub is not merely an LLM proxy—it centrally manages “access control per model, cost tracking (token consumption by model), prompt filtering (removal of harmful content), and content logging (auditing).” In accordance with SAP’s data privacy policy, controls are in place to ensure that input data is not used to train LLM providers’ models.

• Orchestration Service: The “Orchestration Service” within GenAI Hub provides LLM application-building patterns such as RAG (Retrieval-Augmented Generation), prompt templates, and Chain-of-Thought as an orchestration framework. Calling the Orchestration API from a BTP application enables a RAG system to be built in a short period of time.

• Relationship with SAP Joule: SAP Joule operates using LLMs from GenAI Hub. The backend for the natural language (NL) interface provided by Joule is GenAI Hub. When enterprises build their own custom AI assistants, they likewise use the GenAI Hub API as their foundation.

Details of Individual AI Services

The individual AI services (AI Services) provided by BTP expose trained models specialized for particular business tasks as APIs.

• Document Information Extraction (DIE): A service that automatically extracts key fields (issue date, amount, supplier name, line items, etc.) from unstructured documents (PDFs, images) such as invoices, purchase orders, and delivery notes. It operates using a combination of OCR and NLP. It is used to automate payment matching in SAP Cash Application.

• Business Entity Recognition (BER): Recognizes and extracts business entities (company names, product names, trading-partner contact names, etc.) from text such as emails, contracts, and reports.

• Translation Hub: SAP’s official machine translation service. It provides translation quality specialized for multilingual support of SAP product UIs and document translation.

• Intelligent Situation Automation (ISA): An AI feature that detects business exceptions in S/4HANA (a “Situation,” such as insufficient stock or a delayed payment) and triggers automatic remedial actions. It automatically executes detection of the situation → impact analysis → a recommended action (notifying the responsible party, automatic posting, etc.).

9. BTP Regions, Availability, and SLA

Global Regions and Data Residency

SAP BTP is offered globally in more than 35 regions (data center locations). Regions are classified as follows according to the underlying hyperscaler (infrastructure provider).

• SAP’s own data centers (CF only): Data centers operated by SAP itself (e.g., EU10/eu1: Frankfurt). These have the longest history of availability, but there are cases where new features are delivered later than in other hyperscaler regions.

• Microsoft Azure regions (e.g., ap21): BTP regions running on Azure’s global infrastructure. Combining Azure-native services with BTP services is straightforward.

• Amazon Web Services (AWS regions): BTP regions running on AWS infrastructure (e.g., ap10: Sydney, us10: Virginia).

• Google Cloud Platform (GCP regions): BTP regions running on GCP infrastructure (e.g., us30).

• Japan region (jp10): A BTP region using AWS’s Tokyo region as its infrastructure. Data residency is limited to within Japan. It addresses data-residency requirements such as Japan’s Act on the Protection of Personal Information, and financial and medical regulations.

Multi-Region and Disaster Recovery Design

In designing for availability on BTP, it is necessary to understand the concepts of multi-region configurations and disaster recovery (DR).

BTP production environments, in principle, run in a single region (a single subaccount). SAP BTP’s SLA (Service Level Agreement) is standardly “monthly availability of 99.9% or higher (99.5% for some services).” However, the SLA is strictly a guarantee against “failures caused by SAP,” and does not cover failures caused by the user’s own application code or planned maintenance.

An active-active multi-region configuration (load balancing across multiple regions) is not provided as a standard BTP feature. Systems requiring high availability must design an “active-passive DR configuration (manual failover to a separate region in the event of a primary-region failure),” which requires additional design work for application deployment and data replication (such as HANA System Replication).

Planned Maintenance and Upgrade Management

As a SaaS platform, BTP undergoes regular planned maintenance (Platform Upgrades). Planned maintenance is announced in advance via the SAP Cloud Availability Center (SAP for Me).

In particular, runtime updates to the Cloud Foundry environment and maintenance windows for HANA Cloud require a management process to evaluate their impact on production operations in advance. An operational design in which “SAP’s maintenance notifications feed into the change management process” is important.

10. Design and Governance of a BTP Implementation Project

Designing a BTP Center of Excellence (CoE)

Because BTP is a platform where application development, integration, data, AI, and low-code all coexist, governance design—”who uses what, and how”—determines the success or failure of an implementation. An increasing number of companies are establishing a BTP CoE (Center of Excellence) as a cross-organizational team.

• Global account design: It is standard for administrative authority over the global account (Global Account Administrator) to be held by the organization’s central IT department, which then issues subaccounts to individual business divisions and projects. If business divisions create their own global accounts independently, management of licenses, security, and costs becomes decentralized, increasing management overhead.

• Cost allocation model: Because BTP’s consumption-based billing means that “costs are incurred based on actual usage,” a mechanism for allocating costs across subaccounts (who used how much) is necessary. It is important to practice FinOps (cloud cost optimization) by combining cost visualization via BTP’s Cost Reporting API with budget allocation and alert settings per subaccount.

• Separation of development, testing, and production: In BTP projects, independent subaccounts are created for Development (Dev), Quality Assurance (QA), and Production (Prod), and automated promotion is built via a deployment pipeline (CI/CD). Manual BTP configuration changes and manual deployments should be prohibited in the production environment, with a system in which all changes can be traced through the CI/CD pipeline recommended.

BTP CLI and Infrastructure as Code

Manual configuration through the BTP Cockpit (web UI) has limitations in terms of visibility, reproducibility, and change management. Tools that can be used for BTP’s CI/CD and IaC adoption are shown below.

• BTP CLI (btp cli): A command-line tool for managing global accounts, subaccounts, entitlements, and service instances. Automation of subaccount creation and service activation is possible through scripting.

• Terraform Provider for SAP BTP: A provider for managing BTP resources (subaccounts, entitlements, service instances, Destinations of the Destination service, etc.) as code with HashiCorp Terraform. Adopting IaC improves change management, version control, and reproducibility of BTP infrastructure.

• SAP Cloud MTA Build Tool (MBT): An MTA (Multi-Target Application) build tool used for deployment to Cloud Foundry. It packages Java/Node.js applications, iFlows, and the like into a single MTA archive (.mtar) for deployment.

• GitHub Actions / Azure DevOps integration: BTP’s CI/CD is realized either through SAP’s standard Piper (the SAP pipeline framework) or through integration with external CI/CD tools such as GitHub Actions and Azure DevOps. A pipeline of code push → automated build → automated testing → automated deployment to BTP is the standard configuration.

Skill Requirements: Technical Skills Needed for a BTP Implementation

The skill set required for a BTP project is wide-ranging. The assumption that “a single SAP engineer can do it all” is risky, and it is important to clearly define a skills matrix by role.

• BTP architect: Account design, security design, integration architecture, and cost estimation. The SAP certification “SAP Certified Associate – SAP BTP Solution Architect” serves as a reference standard.

• Cloud Foundry/CAP application developer: Node.js, Java, the CAP framework, OData APIs, HANA Cloud.

• ABAP Cloud developer: ABAP Cloud, the RAP model, CDS Views, Released APIs. Even developers with experience in S/4HANA ABAP need to make a learning transition to ABAP Cloud, since the usable APIs and frameworks differ substantially.

• Integration developer (iFlow): Integration Suite, iFlow design, adapter configuration, Groovy Script, XML mapping. Experience with EDI and messaging is a strong affinity.

• Infrastructure/DevOps engineer: Kubernetes (Kyma), Docker, Terraform, CI/CD pipeline design.

11. Case Studies from Other Companies

Case 1: Global Manufacturer Company A — Full-Suite Integration of S/4HANA with Ariba and SuccessFactors

Background and Challenges

Company A, a globally operating manufacturer, had implemented SAP S/4HANA, Ariba, SuccessFactors, and Concur each as independent SaaS solutions. However, data integration between these products had accumulated as a patchwork of “point-to-point integrations,” making it difficult to manage the integrations, trace issues during failures, and control changes to the integrations. In addition, modifications (ABAP changes) to S/4HANA had accumulated, generating costs on the order of millions of yen each year to address modified code with every annual upgrade.

The BTP Implementation and Its Results

Company A adopted BTP’s Integration Suite (Cloud Integration) as its integration hub, consolidating integration among all SAP products into iFlows on Cloud Integration. By making maximum use of SAP’s standard integration scenarios (Integration Packages), the company significantly reduced iFlow development effort compared to the previous point-to-point integrations. It also carried out a refactoring project to gradually migrate S/4HANA’s modified code to CAP/side-by-side extensions on BTP, improving the modification score that had been hindering S/4HANA upgrades. Monitoring in Integration Suite made it possible to detect and address integration errors early, and it is reported that response time for integration failures was significantly reduced.

Case 2: Retailer Company B — Automating Order Processing with Build Process Automation

Background and Challenges

Company B, a retailer of consumer goods, still had an analog process in which orders from small trading partners arrived by fax, email, and phone, and order clerks manually entered them into SAP GUI. During busy periods, the effort required for order entry surged, and erroneous orders due to input mistakes occurred frequently. The company considered introducing EDI to automate order entry, but the effort and cost required for EDI compliance on the part of small trading partners became a barrier and prevented the initiative from moving forward.

The BTP (SBPA + DIE) Implementation and Its Results

Company B built an AI processing flow that uses BTP’s Document Information Extraction (DIE) to automatically extract key information (trading partner name, item codes, quantity, delivery date) from PDF purchase orders attached to order emails. Using the extracted data, the company realized a workflow in Build Process Automation in which “low-risk orders (from existing trading partners, within a normal amount range) are automatically approved → automatically entered into SAP GUI (via Desktop Automation RPA) → an order confirmation email is sent automatically.” Only “high-risk orders (from new trading partners, or large orders)” go through a confirmation flow with a staff member. It is reported that the manual data-entry effort for order clerks was significantly reduced, while erroneous orders due to input mistakes decreased.

Case 3: Financial Services Company C — Real-Time Risk Monitoring with Kyma

Background and Challenges

Company C, a financial services company primarily engaged in securities and asset management, had its risk-monitoring systems split between S/4HANA and an external market-data provider, and was unable to achieve integrated, real-time risk visualization. The company also considered integrating the two via custom modifications to S/4HANA, but maintaining S/4HANA’s standard code was required due to audit and compliance requirements.

The BTP (Kyma + Event Mesh + HANA Cloud) Implementation and Its Results

Company C built an architecture that delivers S/4HANA’s Business Events in real time, via Event Mesh, to a risk-aggregation microservice on Kyma. The Kyma application combines real-time data from the external market-data provider’s streaming API with S/4HANA’s event data, and writes risk summaries to HANA Cloud. The company built a dashboard, serving as a digital boardroom, that visualizes the risk summaries in HANA Cloud in real time via SAC’s (SAP Analytics Cloud’s) Live Connection. It achieved integrated, real-time analysis with external data without modifying S/4HANA’s standard code at all, and it is reported that the audit-related challenges were resolved.

12. A Summary of Constraints and Implementation Risks

What BTP Can and Cannot Do

BTP covers a vast range of functionality, but there are specific situations that require designing around constraints or alternative approaches.

• ◎ Can do: API-based integration across the SAP product portfolio (Cloud Integration), custom application development (CAP/Build Apps), workflow automation (SBPA), API gateway (API Management), cloud database (HANA Cloud), and leveraging LLMs (GenAI Hub).

• △ Depends on the conditions: Real-time synchronization with on-premise systems (requires Cloud Connector and has latency challenges); complex offline mobile apps (basic support is possible with Build Apps, but advanced differential synchronization is difficult); mission-critical real-time ERP transactions (BTP applications play a complementary role, with core transactions fundamentally executed on S/4HANA).

• ✕ Cannot do: Direct execution of on-premise S/4HANA ABAP code (ABAP Environment supports only ABAP Cloud); network paths not compatible with the cloud (direct connections to databases on a closed network); use of BTP services in an environment without internet connectivity (BTP assumes a public cloud).

Key Items to Confirm Before Implementation

To make a BTP implementation successful, the key items that should be confirmed and designed before project kickoff are shown below.

• Confirming entitlements: Are the services and features planned for use included in the contract with SAP? Is the remaining credit balance for consumption-based billing sufficient? Are there any functional restrictions due to the service plan (Free/Standard/Premium)?

• Confirming region selection: Is a region available that meets the data-residency requirements? Are the necessary services available in the Japan region (jp10)? (Some new services are first released in the Europe/US regions.)

• Skills procurement planning: An assessment of the team’s BTP skills at project kickoff, along with a plan for the necessary training, hiring, or external support. BTP is not an area where “an experienced SAP professional will learn it and immediately become effective”—many areas require additional skills in cloud-native development, integration, and MLOps.

• Designing governance first: Designing and operationalizing account hierarchy, cost management, security policy, and the development process (CI/CD) from Day 1 of the project is the single most important requirement for maintaining the long-term health of a BTP investment.

End of document.