Configuring Subaccount Pairing, Access Control, and System Mapping

Explanation

Configuring Cloud Connector for real integration scenarios involves three interconnected steps: subaccount pairing (establishing trust with BTP), access control configuration (defining which internal resources are exposed and how), and destination configuration on the BTP side that references the virtual host names created in Cloud Connector. Subaccount pairing begins in the Cloud Connector administration UI. An administrator adds a new subaccount by supplying the BTP region host, subaccount ID (or subdomain), and credentials for a user with the Cloud Connector Administrator role in that subaccount, or by using a client certificate if the landscape is configured for certificate-based pairing. Once paired, Cloud Connector displays connection status (Connected/Disconnected) and the tunnel is established automatically; if the tunnel drops (network issue, credential expiry, certificate expiry), the subaccount shows as disconnected and BTP-side calls using OnPremise proxy type destinations targeting that subaccount will fail. After pairing, the next step is defining Cloud To On-Premise mappings, commonly called access control. For HTTP/HTTPS-based scenarios, the administrator creates a mapping that specifies: a virtual host and virtual port (an alias name/port that BTP-side destinations will reference, not the real internal hostname), the actual internal host and port of the backend system, and the protocol (HTTP or HTTPS, with an option to enable principal propagation via client certificates for HTTPS). This virtual host indirection is deliberate: it decouples the BTP destination configuration from internal DNS/network topology, so internal hostnames are never exposed directly to the cloud side, and internal systems can be renamed or moved without breaking BTP-side destination definitions, as long as the mapping is updated. Within a given virtual-to-internal host mapping, the administrator then adds specific resource entries: URL paths (with options for exact path, path and subpaths, or path and all subpaths) and an access policy (Path Only or Path and All Sub-Paths) that governs which paths are actually forwarded. Anything not explicitly listed is rejected by Cloud Connector before it ever reaches the internal network, which is the enforcement point for the allow-list security model discussed conceptually in the previous lesson. This is especially important for OData or REST services, where administrators should map only the specific service root or endpoint sets required, not a broad wildcard across an entire backend. For RFC-based access (relevant for classic ABAP RFC-enabled function modules or BAPI calls from BTP-side ABAP environments or middleware), Cloud Connector configuration uses a different mapping type specifying the SAP system's connection parameters (application server or message server details, system number/ID) rather than an HTTP host/port pair, and access control here is defined at the function module or function group level rather than URL path level. On the BTP side, once the virtual host mapping exists in Cloud Connector, an administrator creates or edits a destination (in BTP cockpit's Destinations area, or in Integration Suite's destination-like configuration) with Proxy Type set to OnPremise, and the destination's URL uses the virtual host and port defined in Cloud Connector rather than the real internal address. The BTP runtime resolves this destination, recognizes the OnPremise proxy type, and routes the call through the Connectivity service to the paired Cloud Connector, which matches the virtual host against its access control table and forwards to the mapped internal system if the path is allowed. Common operational tasks at this stage include verifying connectivity using Cloud Connector's built-in connection test feature (which checks reachability to the mapped internal host/port), checking the access control log for rejected requests (useful when a BTP-side call fails with a 403-style error even though the tunnel itself is healthy), and validating certificate expiry dates for both the subaccount pairing trust and any principal propagation certificates. Security-conscious configuration also involves deciding whether to enable principal propagation, which forwards the identity of the BTP-authenticated user to the backend system as an X.509 certificate rather than using a fixed technical/service user, and this requires additional trust configuration between Cloud Connector, the backend system's trust store, and often an identity provisioning or identity authentication service setup on the BTP side—this is typically layered on in later, more advanced configuration passes rather than done in an initial connectivity setup.

Code example

REM Example: Cloud Connector access control mapping (conceptual, as configured via Admin UI, not a CLI script)Virtual Host: s4-po-api.internal.localVirtual Port: 443Internal Host: s4hana-prod-app01.corp.internalInternal Port: 443Protocol: HTTPSPrincipal Propagation: Disabled (technical user via Basic Auth at destination level) Resource path mappings under this virtual host:/sap/opu/odata/sap/API_PURCHASEORDER_PROCESS_SRV  -> Access Policy: Path and All Sub-Paths/sap/opu/odata/sap/API_SALESORDER_SRV              -> Access Policy: Path Only (no subpaths exposed) Corresponding BTP destination (illustrative fields):Name: S4_PO_API_ONPREMURL: https://s4-po-api.internal.local:443ProxyType: OnPremiseAuthentication: BasicAuthenticationCloudConnectorLocationId: (blank or named location if multiple connectors serve this subaccount)

Real project scenario

A logistics company's integration team needed BTP-based Integration Suite iFlows to call two separate on-premise S/4HANA OData APIs (purchase orders and sales orders) while a different backend system (a legacy shipment tracking system on a separate internal host) needed RFC access from an ABAP-based side-by-side extension. The team configured two HTTP mappings in Cloud Connector for the S/4HANA APIs with narrowly scoped resource paths, and a separate RFC mapping for the legacy system limited to a specific function group. During go-live testing, one iFlow call failed with an access-denied response; the access control log in Cloud Connector revealed the iFlow was calling a slightly different OData path than what was mapped, which was corrected by widening the resource entry to 'Path and All Sub-Paths' rather than exact path only.

Common mistakes

• Mapping an internal host with an overly broad path (root '/' with all subpaths) instead of scoping to the specific service endpoints actually needed. • Forgetting that the BTP-side destination URL must use the Cloud Connector virtual host/port, not the real internal hostname, causing connection failures. • Not checking the Cloud Connector access control log when a call fails with an access-denied style error, and instead assuming the tunnel itself is broken. • Pairing credentials or certificates that later expire without a renewal process, causing an unexpected subaccount disconnect in production. • Mixing up RFC-type mappings (system-based) with HTTP-type mappings (host/port-based) when planning connectivity for mixed ABAP and REST/OData scenarios.

Best practices

• Scope access control resource paths as narrowly as possible; avoid wildcard root mappings unless truly necessary. • Use meaningful, consistent virtual host naming conventions that indicate the backend system and purpose, not arbitrary aliases. • Track certificate and credential expiry for subaccount pairing and principal propagation setups with a renewal calendar or monitoring alert. • Use the Cloud Connector connection test and access control log as the first two troubleshooting steps before escalating to network teams. • Keep RFC-based mappings separate and clearly documented from HTTP-based mappings, since their configuration models and access control granularity differ.

Interview angle

Expect scenario-based questions such as 'a BTP application gets a connection error calling an on-premise OData service, walk me through how you'd troubleshoot it using Cloud Connector.' A strong answer moves methodically: check subaccount pairing/tunnel status, check access control mapping and resource path scope, check the destination's proxy type and URL against the virtual host, then check the access control log for rejections. Interviewers also probe understanding of why virtual host indirection exists rather than exposing real internal hostnames directly.