SAP BTP Destinations: Configuration for Different Service Types

[[{“value”:”

Overview:

In the previous blog (SAP BTP Destinations: Understanding the Basics), we covered the basics of SAP BTP Destinations and why they are essential for connecting BTP applications with external systems.

Now, let’s get into the scenarios you’ll actually encounter in real projects.

Not all destinations are configured the same way. The setup depends on where you’re connecting, how the system is exposed, and what authentication it requires.

For example, connecting to S/4HANA Cloud is different from connecting to an on-premise S/4HANA system. And when you’re working with an external REST API, you may need a completely different authentication setup.

So, in this blog, we’ll break down the most common SAP BTP destination scenarios, what makes each one different, and the key configurations you need to get them working.

Let’s have a quick look on the streamlining BTP Connectivity with Destinations before deep diving it individually:

  Picture 1: BTP Connectivity with Destination

Different Types of Services:

1. S/4HANA Cloud

When a BTP application needs to consume APIs from S/4HANA Cloud, we generally create an HTTP destination pointing to the S/4HANA API endpoint.

A typical OAuth 2.0 client credentials configuration looks like:

// Client credentials configuration
Name: S4HANA_CLOUD
Type: HTTP
URL: <S/4HANA API URL>
Proxy Type: Internet
Authentication: OAuth2ClientCredentials

as next,

Client ID: <client-id>
Client Secret: <client-secret>
Token Service URL: <token-endpoint>

The exact endpoint and authentication details depend on the API and the configuration on the S/4HANA Cloud side.

The important thing is to make sure that the OAuth client configured in S/4HANA Cloud has the required permissions to access the API.

So the overall flow becomes:

BTP Application ->  Destination -> S/4HANA Cloud API

2. S/4HANA On-Premise

The configuration changes when our S/4HANA system is running inside the corporate network.

In this case, SAP Cloud Connector is commonly used to establish secure connectivity between SAP BTP and the on-premise system.

// The destination may look like as follows:
Name: S4HANA_ONPREM
Type: HTTP
URL: http://<virtual-host>:<port>
Proxy Type: OnPremise
Authentication: <authentication-method>

Here, the URL configured in the destination is typically based on the virtual host and port defined in Cloud Connector.

The connectivity flow is:

BTP Application -> Destination -> Connectivity Service -> Cloud Connector -> S/4HANA On-Premise

This means there are actually two configurations to consider:

• Destination configuration in BTP
• Cloud Connector configuration for the backend system

If either one is incorrect, the application will not be able to reach the backend.

3. SAP Integration Suite / Cloud Integration

Another common scenario is calling an integration flow deployed in SAP Integration Suite.

For example, an iFlow may expose an HTTPS endpoint that needs to be consumed by a BTP application.

// A typical destination looks like as follows:
Name: CPI_IFLOW
Type: HTTP
URL: <iFlow endpoint>
Proxy Type: Internet
Authentication: OAuth2ClientCredentials

as next,

Client ID: <client-id>
Client Secret: <client-secret>
Token Service URL: <token-endpoint>

The authentication configured in the destination must match what is configured for the integration endpoint.

The advantage here is that the BTP application does not need to manage the iFlow URL and authentication details directly.

4. SAP SaaS Services

The same destination concept can be used when connecting BTP applications to SAP cloud services such as SuccessFactors, Ariba, Concur, and other SaaS solutions.

For example:

Name: SAP_SAAS_API
Type: HTTP
URL: <API endpoint>
Proxy Type: Internet
Authentication: <supported authentication>

The authentication mechanism depends on the individual service.

Some services may use OAuth 2.0, while others may support Basic Authentication, certificates, or other mechanisms.

This is why it is important to first understand the authentication model supported by the target service before creating the destination.

5. External REST API (Most common way)

Destinations are also commonly used for non-SAP systems.

Let’s say our BTP application needs to consume an external REST API.

For an API using OAuth 2.0 Client Credentials:

// Client Credentials as follows:
Name: EXTERNAL_REST_API
Type: HTTP
URL: https://api.example.com
Proxy Type: Internet
Authentication: OAuth2ClientCredentials

as next,

Client ID: <client-id>
Client Secret: <client-secret>
Token Service URL: <token-endpoint>

For an API using Basic Authentication, the configuration would instead use the authentication method supported by that API.

The important point is that the destination configuration should always follow the authentication requirements of the external service. Best Example: Northwind OData Services

6. Principal Propagation

In some enterprise scenarios, simply using a technical user or client credentials is not enough.

We may need to forward the identity of the logged-in BTP user to the backend system. This is where Principal Propagation becomes relevant.

A simplified flow looks like:

BTP User -> BTP Application -> Destination -> Cloud Connector -> Backend System

This scenario requires additional identity and trust configuration across the BTP environment, Cloud Connector, and backend system.

Therefore, Principal Propagation should be treated as an end-to-end configuration rather than just a destination property.

 Picture 2: Quick Overview of different services types

Choosing the Right Authentication

One of the most important decisions while creating a destination is selecting the correct authentication mechanism.

A simple way to think about it is:

These are common patterns, not fixed rules. The target service documentation and security configuration should always be the final reference.

Common Issues During Testing

Destination-related issues are often not caused by the destination itself.

For example, if an on-premise API is not reachable, we should check the complete connectivity chain instead of immediately changing destination properties.

 Picture 3: Issues Impact API Connectivity

Some common areas to check are:

• Incorrect URL or endpoint
• Incorrect Proxy Type
• Invalid credentials
• Incorrect OAuth token endpoint
• Missing scopes or authorizations
• Cloud Connector configuration
• Backend host or port configuration
• Certificate or trust configuration
• API permissions on the target system

A good troubleshooting approach is to identify where the request is failing:

Application -> Destination -> Connectivity -> Authentication -> Target System

This makes troubleshooting much more systematic.

Recommended Approach

When creating a destination for a new service, I normally follow a simple sequence as shown in the following picture:

 Picture 4: SAP BTP Configuration and Connectivity Patterns

Conclusion

Destination configurations may vary from service to service, but the thinking behind them stays the same:

We need to understand: Target system → Endpoint → Connectivity → Authentication → Authorization

Once these pieces are clear, configuring a destination becomes much more straightforward.

Quick Recap

• S/4HANA Cloud: Focus on OAuth, API access, and required permissions.
• On-Premise Systems: Cloud Connector and network connectivity are key.
• External APIs: The authentication approach depends on the API provider.

So rather than memorizing destination properties, it is better to understand the connectivity pattern behind each scenario.

Once we understand that connectivity pattern, you can configure destinations with confidence and troubleshoot them much faster when something goes wrong.

Thank you for taking the time to read this blog! If you found this helpful, i would love to hear your thoughts, feedback or questions in the comments. Let’s keep learning and growing together!

I’m still new to blogging, so if you notice anything that could be improved or corrected, please don’t hesitate to let me know!!

“}]] 

  Read More Technology Blog Posts by Members articles 

#abap