Community
SAP CAP Blog Posts
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
Read only

Integrating SAP S/4HANA Cloud Public APIs into SAP Business Application Studio via BTP Destination

Apurva_Pandey
Discoverer
a week ago
635
  • SAP Managed Tags
  • API

Introduction

Connecting SAP Business Application Studio (BAS) to SAP S/4HANA Cloud Public Edition APIs is a fundamental requirement for modern cloud-native development on SAP Business Technology Platform (BTP). However, the integration path involves multiple layers of configuration that span API finalization, Communication Management in S/4HANA Cloud, destination configuration in BTP, and service consumption in CAP-based applications running in BAS.

This comprehensive blog post walks through the complete architecture, prerequisites, and step-by-step implementation of consuming S/4HANA Cloud Public APIs from SAP BAS using BTP Destination Service with Basic Authentication. Whether you're building full-stack applications, integrating business data, or extending SAP S/4HANA Cloud functionality, this guide provides the knowledge and practical patterns you need.



Chapter-1 [Current Blog]

Introduction
Part 1: Understanding API Finalization and Released APIs
Part 2: SAP S/4HANA Cloud Communication Management Setup
Part 3: SAP Business Technology Platform (BTP) Destination

Chapter-2
Part 4: Building CAP Services in SAP Business Application Studio
Part 5: Deployment and Runtime Configuration
Part 6: Security, Authentication, and Authorization

Chapter-3
Part 7: Troubleshooting and Common Errors
Part 8: Advanced Patterns and Best Practices

Part 1: Understanding API Finalization and Released APIs

The Clean Core Philosophy and Released APIs

Before consuming any API from SAP S/4HANA Cloud Public Edition, it is critical to understand the Released API concept and the Clean Core approach that underlies all public cloud deployment strategies.

SAP S/4HANA Cloud Public Edition is "clean per definition," meaning that all extensions, integrations, and custom developments must adhere to released, stable APIs. These released APIs form the foundation of upgrade-stable integrations and support the long-term innovation roadmap without technical debt accumulation.

Released APIs are formally sanctioned interfaces published by SAP with explicit stability contracts. They guarantee backward compatibility across quarterly releases and are the only interfaces available for consumption in Tier 1 (cloud-ready) extension scenarios. Unlike classic SAP objects such as function modules, BAPIs, or internal tables, released APIs are versioned, documented, and managed under a formal lifecycle.

 

Types of Released APIs in SAP S/4HANA Cloud Public Edition

SAP S/4HANA Cloud Public Edition exposes two primary API types:

  1. OData APIs (Recommended): Open Data Protocol (OData) is the standardized protocol for creating and consuming REST-based data APIs. OData v4 (latest) and OData v2 (legacy, supported) are available. OData APIs enable simple HTTP-based data manipulation (Create, Read, Update, Delete) and are ideal for integration scenarios. They comply with REST architecture principles and support query operations like filtering, sorting, pagination, and batch operations.
  2. SOAP APIs: SOAP (Simple Object Access Protocol) APIs provide XML-based web services for complex synchronous operations and legacy system integrations. While less common in modern cloud scenarios, they remain supported for specific business processes.

API Finalization: The Path to Released Status

Not every API is immediately released. SAP follows a structured finalization and release process to ensure APIs meet quality, stability, and documentation standards before general availability.

API Finalization Process:

  1. Development Phase: The API is created within SAP development systems, typically to expose a specific business service or transaction. During this phase, the API undergoes internal testing and validation against functional requirements.
  2. Quality Assurance: The API is thoroughly tested for performance, security, error handling, and backward compatibility. SAP engineers verify that the API meets the stability criteria required for production consumption.
  3. Documentation and Review: Comprehensive technical documentation is prepared, including entity definitions, available operations, authentication requirements, and sample payloads. Product teams review the API for consistency with the SAP API design guidelines.
  4. Release Status Assignment: Once approved, the API receives a formal release status:
    • Released: Fully stable, documented, and available for production use. Backward compatibility is guaranteed.
    • Deprecated: The API still functions but is being phased out. A successor API is typically identified.
    • Beta: The API is available for testing but may change before final release.
    • Internal: The API is used only within SAP systems and is not available for external consumption.
  5. Publication on SAP Business Accelerator Hub: Released APIs are published on SAP Business Accelerator Hub (https://api.sap.com/), the central repository for discovering and testing all public SAP APIs. The hub provides metadata, EDMX (Entity Data Model XML) files, sandbox environments, and usage examples.

Discovering Released APIs

To find and evaluate released APIs for your integration scenario:

  1. Navigate to SAP Business Accelerator Hub at https://api.sap.com/
  2. Filter by Product: Select "SAP S/4HANA Cloud Public Edition"
  3. Filter by API Type: Choose between OData and SOAP
  4. Search by Business Area: Use keywords related to your business process (e.g., "Business Partner," "Sales Order," "Purchase Requisition")
  5. Review API Details: For each API, examine:
    • Entity structure and available fields
    • Supported operations (Create, Read, Update, Delete)
    • Authentication requirements
    • Service URL and path
    • Communication Scenario (the binding mechanism in S/4HANA Cloud)
    • Scope items and business authorization objects
    • Deprecation status and recommended successors

API Examples: Common Released APIs for S/4HANA Cloud Public

  • API_BUSINESS_PARTNER (OData v2): Exposes master data for business partners (customers and suppliers)
  • API_SALES_ORDER_SRV (OData v2): Provides sales order creation, modification, and retrieval
  • API_PURCHASE_REQUISITION (OData v2): Enables purchase requisition management
  • A_BusinessPartner (OData v4): The modern successor to API_BUSINESS_PARTNER, offering improved performance

 

Part 2: SAP S/4HANA Cloud Communication Management Setup

Communication Management Architecture

SAP S/4HANA Cloud Communication Management is the inbound and outbound integration gateway that exposes APIs securely with centralized credential and authorization management. Before any external system (including BAS applications on BTP) can consume an S/4HANA Cloud API, a Communication Arrangement must be created in the source S/4HANA Cloud tenant.

The Communication Management architecture comprises four components:

  1. Communication Scenario: A predefined or custom integration pattern that specifies which inbound and outbound services are exposed. SAP provides hundreds of prebuilt scenarios (e.g., SAP_COM_0008 for Business Partner creation and read).
  2. Communication System: A representation of the external system (in this case, the SAP BTP subaccount) that will call the API. It acts as a trusted endpoint and stores authentication metadata.
  3. Communication User: A technical user created specifically for API access. The communication user holds credentials (username and password) and authorization roles for executing specific API operations. Unlike business users, communication users are designed for machine-to-machine (M2M) integration.
  4. Communication Arrangement: The runtime binding between a Communication Scenario, Communication System, and Communication Users. It activates the API, assigns authentication rules, and enables audit logging.

 Step 1: Create a Communication User in S/4HANA Cloud

Comm User.png

A Communication User is a special technical user created exclusively for API access and integration scenarios. It operates independently of business users and is not licensed as a named user.

To create a Communication User:

  1. Log in to your SAP S/4HANA Cloud tenant with administrative credentials
  2. Open Launchpad and search for "Maintain Communication Users" app
  3. Click "New" to create a new communication user
  4. Fill in Required Fields:
    • User Name: A unique identifier, e.g., INT_BTP_USER
    • Description: E.g., "Communication User for BTP Integration"
    • Password: A strong, randomly generated password
    • Confirm Password: Retype for verification
    • Allowed System Access Range: Typically leave empty for standard scenarios
  5. Save the communication user

Step 2: Create a Communication System

A Communication System is a logical representation of the calling system (SAP BTP in this scenario). It establishes trust between S/4HANA Cloud and the external system and specifies the authentication method.

To create a Communication System:

  1. Open Launchpad and search for "Communication Systems" app
  2. Click "New" to create a new systemcomm sys 1.png
  3. Fill in Details:
    • System ID: A unique identifier, e.g., BTP_SUBACCOUNT_01
    • System Name: A descriptive name, e.g., "SAP BTP Integration"
    • System Type: Leave as default or specify HTTP-based integration
  4. In the "General" section:
    • Inbound Only: Set to ON (since BTP will call S/4HANA Cloud inbound APIs)
    • Technical Data: Note the System ID for later referencecomm sys 2.png
  5. In "Inbound Communication" section:
    • Inbound User: Select the communication user created in Step 1
    • Authentication: Choose Basic Authentication for direct credential-based access
  6. Save the communication system

 

Step 3: Create a Communication Arrangement

A Communication Arrangement activates the integration by binding a Communication Scenario, Communication System, and Communication User together. It's the final step that "switches on" API access.

comm arrang.png

To create a Communication Arrangement:

  1. Open Launchpad and search for "Communication Arrangements" app
  2. Click "New" to create a new arrangement
  3. Select Communication Scenario: Browse and select the scenario matching your API. For example:
    • SAP_COM_0008: Business Partner – Read & Create
    • SAP_COM_0148: Sales Order – Read
    • For custom scenarios, search for your business process name
  4. Configure Communication System:
    • Select the communication system created in Step 2
    • Inbound User: Should auto-populate with the communication user assigned to the system
  5. Review Scope and Authorization:
    • The Communication Arrangement displays which inbound and outbound services are available
    • Some scenarios include data replication services (outbound) which you can disable if not needed
    • Verify that the required business processes are included
  6. Save and Activate the arrangement

Verifying the Communication Arrangement:

After saving, the arrangement is active. To verify successful creation:

Capturing Connection Details:

Note the following for use in BTP Destination configuration:

  • Service Root URL: https://<your-tenant-id>-api.s4hana.ondemand.com (e.g., https://my12345-api.s4hana.cloud.sap)
  • API Path: /sap/opu/odata/sap/<API_NAME> (e.g., /sap/opu/odata/sap/API_BUSINESS_PARTNER)
  • Communication User: The username created in Step 1
  • Communication User Password: The password set in Step 1
  • Client: Typically 100 (default client in S/4HANA Cloud)

 

Part 3: SAP Business Technology Platform (BTP) Destination Configuration

BTP Architecture: Destinations as Connectivity Bridges

SAP BTP Destination Service is the centralized credential and endpoint registry that sits between your CAP application running in BAS and remote systems like S/4HANA Cloud. Destinations abstract the complexity of authentication, URL management, and security policies, enabling developers to reference a destination by name without managing credentials directly in code.

Key Architecture Principles:

  1. Credential Management: Credentials are stored encrypted within the Destination Service, not in application code or configuration files
  2. Audit Trails: All destination access is logged, providing compliance and security visibility
  3. Dynamic Configuration: Destinations can be updated centrally without redeploying applications
  4. Proxy Layer: The Destination Service acts as a proxy, handling authentication header injection, token generation, and request forwarding
  5. Scope: Destinations are defined at the BTP Subaccount Level, ensuring centralized governance

Creating a Destination for S/4HANA Cloud with Basic Authentication

Prerequisites:

  • Access to BTP Cockpit with Connectivity → Destinations permissions
  • Communication User credentials from S/4HANA Cloud
  • Service URL and API path from the Communication Arrangement

 Step-by-Step Configuration:

  1. Open BTP Cockpit and navigate to your Subaccount
  2. In the left navigation, under Connectivity, click Destinations
  3. Click "New Destination" (or "Create → From Scratch")
  4. Configure Main Properties:

destination create.png

Field

Value

Name

S4_BusinessPartner (or any descriptive name)

Type

HTTP

Description

Destination to S/4HANA Cloud Business Partner API

URL

https://<your-tenant-id>-api.s4hana.ondemand.com/sap/opu/odata/sap/API_BUSINESS_PARTNER

Proxy Type

Internet

Authentication

BasicAuthentication

User

Communication user (e.g., INT_BTP_USER)

Password

Communication user password

 destination.png

Table 1: BTP Destination Configuration - Main Properties

  1. Add Additional Properties (click Add Property multiple times):

Key

Value

Purpose

sap-client

100

Specifies the SAP client (default for S/4HANA Cloud)

WebIDEEnabled

true

Makes destination visible in BAS OData tools

WebIDEUsage

odata_gen,odata_abap

Enables OData metadata generation

HTML5.DynamicDestination

true

Allows runtime destination resolution

HTML5.Timeout

60000

Timeout in milliseconds (60 seconds)

 

Table 2: BTP Destination Configuration - Additional Properties

  1. Configure Client Trust Store (Security Tab):
    • Ensure "Use default client trust store" is checked
    • This allows the destination to verify S/4HANA Cloud's SSL certificate
  2. Save the destination

Verification:

After saving:

Test Destination connection.png

  1. The destination appears in the Destinations list with a green checkmark (✓)
  2. Click the destination name to view its configuration
  3. Click "Test Connection" to verify connectivity:
    • A successful test returns HTTP 200 with OData metadata
    • If the test fails, verify credentials, URL, and network connectivity