BTP destinations and the Cloud Connector

Destinations

A destination is a named record in a BTP subaccount (or a service instance) that holds:

• URL;
• ProxyType: Internet (the default), OnPremise (through the Cloud Connector) or PrivateLink;
• Authentication and its properties.

Code asks for a destination by name, so URLs and secrets stay out of the code.

SAP's destination guide lists 17 authentication types in all, plus client assertions instead of secrets. The hub's reading: start with BasicAuthentication or OAuth2ClientCredentials for a technical integration user, and move to principal propagation when the SAP-side audit must show the real user.

Custom headers and query parameters:

• Add destination properties URL.headers.<Name> and URL.queries.<Name>, for example URL.headers.APIKey for the sandbox key, or URL.queries.language = EN. They're sent on every call.
• A sap-client property is sent as the sap-client header by the SAP Cloud SDK.
• Not every client supports these properties. SAP notes it depends on the consumption method.

Creating destinations:

• in the BTP cockpit (from scratch or from a template);
• on service-instance creation;
• in an MTA descriptor;
• with the Destination service REST API.

How code finds a destination (SAP Cloud SDK)

executeHttpRequest({ destinationName: "S4", jwt }, …):

1. looks in the destinations environment variable, which is handy locally and in tests;
2. otherwise asks the Destination service of the bound BTP subaccount, using the caller's JWT.

For ProxyType: OnPremise:

• the app needs a connectivity service binding;
• the SDK uses that binding's client credentials to get a token, gets the connectivity proxy's host and authorization, and sends the request through the proxy to the Cloud Connector.

The Cloud Connector

• Runs inside the customer's network as a "reverse invoke proxy". It opens an outbound tunnel to BTP, so no inbound firewall ports open.
• Exposes only allowlisted back-end systems, under a virtual host and port, and only the paths and resources the administrator allows. Access control is configured per protocol: HTTP, RFC, TCP, LDAP.
• Can propagate the cloud user's identity (principal propagation). Variants use the IAS token, OIDC token, corporate IdP or user exchange token, and RFC.
• Recovers connections automatically, audit-logs inbound traffic and configuration changes, and supports high availability.
• One subaccount can connect several Cloud Connectors. They're told apart by location ID (CloudConnectorLocationId on the destination).

Where calls fail