SAP BTP Cloud Connector: On-Premise Connectivity and Virtual Mapping

Cloud Connector runs in the customer-controlled network and connects to one or more BTP subaccounts. Administrators map an internal host/port to a virtual host/port and explicitly expose URL paths/resources or RFC access. BTP's Connectivity service routes destination traffic through that mapping. The connector can participate in principal propagation by validating/transforming identity tokens/certificates according to the configured trust. Because the tunnel is initiated outward, firewall design differs from exposing an inbound internet endpoint directly.

Use Cloud Connector when BTP workloads must reach on-premise/private-network SAP or non-SAP systems without publicly exposing those systems. Configure the narrowest resources required and separate connectivity from authentication/authorization design. For cloud-to-cloud targets reachable securely over internet/private connectivity, Cloud Connector may not be necessary. For S/4HANA Cloud public APIs, communication arrangements/destinations normally use direct cloud connectivity rather than an on-premise connector.

A BTP Destination names the target and authentication method; Connectivity routes OnPremise proxy traffic; Cloud Connector maps virtual to internal endpoints and enforces resource access. Principal propagation adds identity forwarding; OAuth/client credentials may instead use technical identity. Backend SICF/ICF/RFC services and authorizations still decide whether the called user can execute the requested operation. A green connector status only proves one network/trust layer.

A CAP app on BTP must call an on-premise S/4HANA OData service. The destination URL uses the Cloud Connector virtual host with ProxyType OnPremise. Connector mapping exposes only `/sap/opu/odata/sap/Z_ORDER_SRV`, not the entire ABAP host. The tunnel is healthy but the call returns 403; backend authorization—not Cloud Connector—blocks the user. This layered diagnosis prevents administrators from broadening network exposure to solve an application permission problem.

Cloud Connector is central to BTP side-by-side connectivity with S/4HANA on-premise/private cloud. Current BTP Connectivity also supports principal propagation and technical-user propagation scenarios. Clean-core architectures frequently use this route to consume released backend APIs without modifying the core.

BTP/Basis/network teams own connector installation, subaccount mapping, HA and certificates; integration/app teams own destinations and API calls; Security owns propagated/technical identity and backend authorization.

BTP Destinations define how applications address/authenticate the target. Principal propagation and API Management are separate concerns. SICF/Gateway activation still matters on the ABAP backend.

Production verification: Capture tenant/subaccount, artifact or API-proxy name/version, message/correlation ID, source and target endpoints, authentication flow, HTTP/status or broker outcome, retry count, and target business document ID. Use MPL/trace only for the shortest necessary diagnostic window and avoid logging secrets or sensitive payload fields.

Operational readiness: For production readiness of SAP BTP Cloud Connector: On-Premise Connectivity and Virtual Mapping, add an operational runbook that names the source owner, integration/platform owner and target application owner; defines correlation, retry/replay and duplicate handling; and states where a support engineer can prove the last successful handoff. Test authentication expiry, receiver outage, malformed/business-invalid payloads and ambiguous timeouts—not only the happy path. If the interface is asynchronous, document queue/retention/order behavior and how a corrected message is reprocessed without duplicating a business transaction.

Review checkpoint: Review checkpoint for SAP BTP Cloud Connector: On-Premise Connectivity and Virtual Mapping: document one successful message and one intentionally failed message from source to target, including the correlation key visible in every participating monitor. Record whether the operation is synchronous, queued, retried or event-driven and what constitutes final business success. Verify secret and certificate ownership, expiry monitoring, destination or endpoint promotion between environments, timeout behavior, and the exact manual replay procedure. A support engineer should be able to determine within minutes whether the failure belongs to source data, BTP connectivity or security, middleware processing, target API validation, or downstream business posting.