Configuring Destinations: Proxy Types, Authentication Methods and Cloud Connector Integration

Explanation

Configuring a destination correctly requires matching three interdependent choices to the target system's actual capabilities: Proxy Type, Authentication type, and any target-system-specific additional properties. Getting this combination wrong is the most common source of connectivity failures in BTP projects, so understanding the decision logic is essential at the intermediate level. Proxy Type has two primary values. Internet means the target system is directly reachable from BTP over the public internet (or a private link where configured) - typical for SaaS APIs like SuccessFactors, Ariba, or third-party REST services. OnPremise means the target system sits inside a customer's internal network and is not directly reachable; instead, the request is tunneled through the SAP Cloud Connector, which maintains a secure reverse-invoke connection from the customer's network back out to the BTP subaccount's Connectivity service. When you configure an OnPremise destination, the URL you specify is a virtual host and port that must match an exposed system mapping configured in the Cloud Connector, not the real internal hostname of the backend - this indirection is a frequent point of confusion for beginners moving to intermediate work. Authentication type must match what the target system actually expects and supports. NoAuthentication is rare in production and mainly used for public unauthenticated endpoints or early prototyping. BasicAuthentication sends a username and password and is simple but weaker operationally since password rotation and storage become concerns; it is still common for legacy on-premise systems accessed via Cloud Connector. OAuth2ClientCredentials is typical for machine-to-machine calls to cloud services that support OAuth, using a client ID and secret to obtain a token that the Destination service caches and refreshes automatically. OAuth2SAMLBearerAssertion is used when an identity needs to be asserted from BTP to a backend system (such as S/4HANA) supporting SAML Bearer flows, useful for maintaining user context in downstream calls. PrincipalPropagation is used specifically with OnPremise destinations via Cloud Connector to forward the logged-in BTP user's identity to an on-premise ABAP system, relying on a configured trust relationship (client certificate-based) between Cloud Connector and the backend, so the backend can perform its own authorization based on the propagated user. ClientCertificateAuthentication is used when mutual TLS is required by the target. Beyond proxy type and auth, additional properties matter: for OData-consuming SAPUI5 apps, properties like WebIDIUsage or sap-client can be required; for HTML5 apps behind an approuter, destinations may need HTML5.DynamicDestination=true to allow certain runtime behaviors. Testing a destination directly from the BTP cockpit's 'Check Connection' feature validates basic reachability and authentication but does not always validate deeper protocol-specific behavior (like OData metadata parsing), so a successful check does not guarantee the consuming application will work end-to-end. For Cloud Connector-routed destinations, troubleshooting requires checking both sides: the destination configuration in BTP cockpit, and the corresponding system mapping and access control list in Cloud Connector's administration UI, which explicitly whitelists which internal resource paths are exposed. A very common failure is a destination pointing to a virtual host/port that exists in BTP configuration but has no matching, or an incorrectly scoped, mapping in Cloud Connector, resulting in connection refused or 403 errors that are easy to misdiagnose as an authentication problem when they are actually a routing/whitelisting problem.

Code example

# Example destination configuration properties (as key-value pairs, e.g., in BTP cockpit or destination file) Name=S4_ONPREM_PO_APIType=HTTPProxyType=OnPremiseURL=https://myvirtualhost:8443# myvirtualhost:8443 must match an exposed system mapping in Cloud Connector,# NOT the real internal hostname of the S/4HANA systemAuthentication=PrincipalPropagationsap-client=100WebIDIUsage=odata_genHTML5.DynamicDestination=true # Companion Cloud Connector configuration (conceptual, not code):# Virtual Host: myvirtualhost   Virtual Port: 8443# Internal Host: s4hana-prod.internal.corp   Internal Port: 443# Resource path whitelist: /sap/opu/odata/sap/API_PURCHASEORDER_PROCESS_SRV/*# Principal Propagation: enabled, with trust configured between Cloud Connector and backend

Real project scenario

During a go-live for an approval workflow that calls an on-premise purchase order API with the logged-in user's identity preserved for authorization checks in S/4HANA, the integration team initially configures BasicAuthentication with a technical user. Business stakeholders later require that approvals be logged and authorized per actual user, not a shared technical account. The team switches the destination's authentication to PrincipalPropagation, sets up the corresponding trust configuration in Cloud Connector, and validates that the backend now sees the propagated user in its authorization checks - without any change to the application code, only the destination and Cloud Connector configuration.

Common mistakes

• Setting ProxyType=Internet for a system that is actually only reachable inside the customer network, causing connection timeouts. • Entering the real internal backend hostname in an OnPremise destination's URL instead of the Cloud Connector virtual host/port. • Choosing BasicAuthentication out of convenience when PrincipalPropagation or OAuth2SAMLBearerAssertion is required for proper user-level authorization traceability. • Assuming a green 'Check Connection' result in the cockpit guarantees the consuming application will succeed, ignoring protocol-specific issues like OData metadata or CSRF token handling. • Forgetting to update or verify the Cloud Connector system mapping and resource whitelist when a new destination or endpoint path is introduced, leading to 403 or connection-refused errors misdiagnosed as authentication failures. • Leaving PrincipalPropagation trust certificates to expire without a renewal process, causing sudden authentication failures in production.

Best practices

• Always confirm with the backend team which authentication types are actually supported and required before configuring the destination. • For OnPremise destinations, always use Cloud Connector virtual host/port values, never real internal hostnames, in the destination URL. • Prefer PrincipalPropagation or OAuth2SAMLBearerAssertion over BasicAuthentication whenever user-level traceability or authorization is required by the business process. • Validate connectivity end-to-end from the actual consuming application, not just via the cockpit's basic connection check. • Maintain a documented mapping between each OnPremise destination and its corresponding Cloud Connector system mapping and access control entries. • Set calendar reminders or automated monitoring for certificate and trust expiration when using PrincipalPropagation or client certificate authentication.

Interview angle

Interview questions at this level often probe whether a candidate can correctly map a business scenario to the right ProxyType and Authentication combination, and whether they understand that OnPremise destinations route through Cloud Connector using virtual host mapping rather than direct hostnames. Being able to explain why PrincipalPropagation requires trust configuration on both Cloud Connector and the backend, and articulating a realistic troubleshooting sequence (destination config, Cloud Connector mapping, backend trust/authorization) demonstrates hands-on depth beyond textbook knowledge.