SAP BTP Connectivity: Destination Service & Cloud Connector

How cloud applications on BTP securely reach both cloud and on-premise backend systems using the Destination and Connectivity services.

Connectivity is one of the most practically essential BTP topics because literally every BTP application that talks to anything else - S/4HANA, SuccessFactors, a third-party API - needs it configured correctly, and interviewers ask about it to check whether a candidate has actually deployed and connected a real application rather than only built one in isolation.

The Destination service is like a company's centrally-maintained address book that employees (application code) look up by contact name rather than memorizing addresses directly, so when someone moves offices (environment change) only the address book needs updating; Cloud Connector is a pre-arranged, one-way secure courier route the building itself sets up to receive deliveries from BTP without ever leaving its own front door unlocked to the public street.

Key Concepts

The Destination service stores connection configuration (target URL, authentication type - Basic, OAuth2 client credentials, certificate-based, and principal propagation among others - and various connection properties) as a named destination, decoupling an application's code from environment-specific connection details entirely: application code simply asks for "the destination named S4_BACKEND" rather than hardcoding a URL and credentials, meaning the exact same application code can point to a dev, QA, or production backend purely through destination configuration changes, without any code or redeployment change at all - a clean separation of concerns that also keeps credentials out of application code and version control.

S4_BACKEND

When the target system is on-premise (not reachable directly from the internet, which describes most real customer S/4HANA/ECC landscapes), Cloud Connector bridges the gap: an on-premise-installed component that establishes a secure, outbound-initiated tunnel from the customer's network to their specific BTP subaccount, exposing only explicitly whitelisted on-premise system/path combinations rather than opening the on-premise network broadly - meaning the customer's firewall never needs an inbound hole opened, since the connection is always initiated from inside the customer's own network outward to BTP. A destination configured with ProxyType: OnPremise routes through this tunnel automatically once Cloud Connector is set up and the specific backend/path is whitelisted on the Cloud Connector side.

ProxyType: OnPremise

A senior-level answer covers principal propagation specifically (forwarding the actual logged-in BTP user's identity through to the on-premise backend system via a short-lived certificate, so the on-premise system can apply its own user-specific authorization rather than the BTP app connecting as one generic technical/service user for everyone) as a meaningfully more secure and auditable pattern than a single shared technical user, and the Connectivity service's lower-level role (providing the actual secure tunnel/proxy mechanics that Cloud Connector and destination configuration build upon) as distinct from but complementary to the higher-level Destination service that most application code directly interacts with.