Connectivity and Destinations: Connecting BTP Subaccounts to On-Premise and Cloud Systems

Explanation

Once a subaccount and its runtime (Cloud Foundry space or Kyma namespace) exist, the next practical question every consultant faces is: how does an application or integration flow deployed on BTP actually talk to a backend system? This is where destinations, the Connectivity service, and the Cloud Connector become central. A destination is a named configuration object stored at subaccount or subscription level that tells a consuming application or service (for example, an Integration Suite flow, a CAP application, or an SAPUI5 app) how to reach a target system: the URL, authentication type, and proxy type. Proxy type is the critical field. 'Internet' means the target is directly reachable over the public internet (for example, a SuccessFactors or Ariba cloud tenant, or another BTP service). 'OnPremise' means the target sits inside a customer network that is not directly exposed to the internet, and traffic must be tunneled through the Cloud Connector. There is also 'PrivateLink', used in some BTP environments to reach services over a private network connection without traversing the public internet, though availability and setup depend on the specific hyperscaler and region and should not be assumed universally available. The Cloud Connector is a separate on-premise agent (installed in the customer's own landscape, not inside BTP) that establishes a secure, outbound-initiated tunnel to a specific subaccount. Because the connection is initiated from inside the customer network outward, there is no need to open inbound firewall ports into the on-premise landscape, which is a key security selling point. Within the Cloud Connector, administrators explicitly define which backend systems, hosts, ports, and resource paths (URL path whitelisting) are exposed through the tunnel. This is a deliberate allow-list model: nothing is reachable unless explicitly exposed, which limits blast radius if the BTP side is ever compromised. The Connectivity service is the BTP-side counterpart that applications and platform services use to route calls through the correct tunnel to the correct on-premise system, resolving which Cloud Connector instance and backend to use based on the destination configuration and subaccount-to-connector mapping. Authentication on the destination can vary: NoAuthentication, BasicAuthentication, ClientCertificateAuthentication, OAuth2SAMLBearerAssertion, OAuth2ClientCredentials, and others depending on the target system and scenario. For SAP-to-SAP scenarios (for example, calling an S/4HANA on-premise OData service from a BTP extension app), principal propagation using OAuth2SAMLBearerAssertion is common because it preserves the end user's identity across the hop rather than using a generic technical user, which matters for authorization and audit trails. In Integration Suite specifically, integration flows use these same destinations (or equivalent connection configurations depending on the adapter) to reach sender and receiver systems, so a solid understanding of proxy type, authentication type, and Cloud Connector mapping is a prerequisite for building working integration content, not just an infrastructure detail to delegate to Basis. Troubleshooting connectivity issues typically starts by isolating where the failure occurs: is the destination reachable at all (check destination configuration and 'Check Connection' where available), is the Cloud Connector tunnel up and the specific backend/path whitelisted, is the authentication method correctly configured on both ends, and are certificates or credentials expired. Consultants should get comfortable reading Cloud Connector logs and destination check results rather than escalating every connectivity failure directly to network teams.

Code example

// Example: Destination configuration for an on-premise S/4HANA system via Cloud Connector// (conceptual key-value representation as seen in BTP cockpit / destination editor) Name=S4HANA_ONPREM_ERPType=HTTPURL=https://virtualhost.onprem.internal:443ProxyType=OnPremiseAuthentication=OAuth2SAMLBearerAssertionAudience=https://virtualhost.onprem.internaltokenServiceURL=https://<subaccount>.authentication.<region>.hana.ondemand.com/oauth/tokenclientId=<oauth-client-id>clientSecret=<oauth-client-secret>sap-client=100 // Notes:// - 'virtualhost.onprem.internal' is the *virtual* host defined in Cloud Connector,//   not necessarily the backend's real hostname; Cloud Connector maps it internally.// - ProxyType=OnPremise forces routing through the Connectivity service + Cloud Connector tunnel.// - The Cloud Connector admin console must whitelist this virtual host, port, and required URL paths//   (e.g. /sap/opu/odata/sap/*) before any call will succeed, regardless of destination correctness.

Real project scenario

A project team builds a BTP-based approval extension app that needs to read purchase order data from an on-premise S/4HANA system. The app works fine in a demo using a hardcoded test endpoint but fails with connection timeouts after deployment to the customer's actual subaccount. Investigation reveals the Cloud Connector was installed and connected to the correct subaccount, but the specific backend system and URL path used by the app's OData calls had not been added to the resource access whitelist. The fix involved adding the exact virtual host and path pattern to the Cloud Connector configuration, after which the destination check succeeded and the app started returning data, illustrating that destination configuration alone is necessary but not sufficient without matching Cloud Connector whitelisting.

Common mistakes

• Assuming a destination with ProxyType=Internet can reach an on-premise system without a Cloud Connector, leading to persistent connection failures. • Whitelisting only a broad host in Cloud Connector without the specific URL path patterns the application actually calls, causing 403 or connection-refused errors even though the tunnel is up. • Using generic BasicAuthentication technical users for all backend calls when principal propagation is required for correct authorization and audit logging in SAP-to-SAP scenarios. • Hardcoding backend URLs inside application or integration flow code instead of referencing a destination, making environment promotion (dev to test to production) error-prone and hard to reconfigure. • Forgetting that destination credentials and certificates have expiry dates, causing scenarios that worked for months to suddenly fail in production.

Best practices

• Always model backend connections as named destinations rather than hardcoded URLs, so environments can be repointed without code changes. • Use the most specific URL path whitelisting in Cloud Connector that the scenario requires, avoiding overly broad host-level exposure. • Prefer principal propagation (OAuth2SAMLBearerAssertion or equivalent) for SAP-to-SAP scenarios where end-user identity and authorization matter. • Document which Cloud Connector instance maps to which subaccount and backend, since multiple connectors across landscapes can otherwise cause confusion during incidents. • Build a habit of using the destination 'Check Connection' feature and Cloud Connector logs as the first troubleshooting step before escalating to network or Basis teams.

Interview angle

Interviewers commonly probe whether a candidate understands the difference between proxy type Internet and OnPremise, why the Cloud Connector tunnel is outbound-initiated from the customer side, and how principal propagation differs from a generic technical user in terms of security and auditability. Being able to describe a real troubleshooting sequence (destination check, Cloud Connector log review, whitelist verification, authentication validation) signals hands-on experience rather than textbook knowledge.