BTP Integration Architecture: Connectivity Patterns Between Core and Side-by-Side Extensions
Explains how BTP side-by-side extensions and core S/4HANA or ECC systems actually connect at runtime, covering Cloud Connector, destinations, and integration middleware choices.
Explanation
Once an architect decides that an extension belongs on BTP rather than inside the core (per Clean Core principles), the next hard question is how that extension talks to the core system reliably, securely, and without becoming a hidden point-to-point dependency. This lesson focuses on the runtime connectivity layer, which is often underestimated during design workshops but causes most production incidents later. For on-premise or private cloud S/4HANA (and ECC) systems, the most common pattern is SAP Cloud Connector, which establishes a reverse-invoke tunnel from the customer network to BTP without opening inbound firewall ports on the corporate side. The Cloud Connector exposes specific back-end system resources (paths, not the whole network) as virtual systems, and BTP applications reference them through Destination service entries. Architecturally this matters because the destination becomes the single place where authentication method, URL, and routing are defined — changing back-end credentials or endpoints should not require redeploying application code if destinations are used correctly. For S/4HANA Cloud Public Edition, direct Cloud Connector tunnels into the customer's own on-premise landscape are not the typical model; public cloud extensibility instead favors released APIs (OData, SOAP already being phased down, event-based notifications) reachable over the internet with OAuth2 client credentials or similar, often orchestrated through SAP Integration Suite. Architects must not assume the private cloud on-premise connectivity model transfers unchanged to public cloud — the two differ in network topology, credential lifecycle, and available protocols, and misapplying one pattern to the other is a common design mistake. Middleware placement is the second major decision. Simple, low-volume, synchronous calls from a side-by-side app may go directly through Destination service to the back end. Higher-volume, multi-system, or asynchronous scenarios usually benefit from routing through SAP Integration Suite (or an existing enterprise integration platform if the organization already runs one), which centralizes mapping, retry logic, monitoring, and message transformation. Placing integration logic inside the extension application itself instead of a dedicated integration layer creates hidden coupling that is hard to govern later — every extension ends up re-implementing retry and error-handling logic differently. Runtime flow to understand: a user or event triggers the BTP application; the application resolves a destination (which may itself call a Connectivity service that negotiates the Cloud Connector tunnel); the request traverses the tunnel to an on-premise reverse proxy location mapped to a specific back-end host and path; the back-end system authenticates the inbound call (technical user, principal propagation, or OAuth depending on configuration) and returns a response along the same path. Principal propagation, where the end user's identity is passed through rather than a generic technical user, is important for authorization-sensitive scenarios but requires additional trust configuration between BTP identity provider and the back-end system's trust store — architects should decide early whether business scenarios require this, since retrofitting it later touches both landscapes. Troubleshooting connectivity issues typically starts by isolating the layer: is the destination configuration correct, is the Cloud Connector tunnel active and the mapped resource reachable, is the back-end authentication rejecting the call, or is a corporate firewall/proxy blocking outbound traffic from the Cloud Connector host. Because multiple teams (network, Basis, BTP administrators) often each own part of this chain, unclear connectivity ownership is a frequent operational pain point that should be resolved during the strategy phase, not discovered during an incident.
Real project scenario
A retail customer built a BTP side-by-side pricing simulation app that needed live pricing conditions from S/4HANA private cloud. The initial pilot called the back end directly from application code using hardcoded URLs, which worked in development but failed in production because outbound internet access was blocked and no Cloud Connector was provisioned. The architect redesigned the integration to use Cloud Connector plus Destination service, and additionally introduced Integration Suite for retry handling once volume increased beyond a few requests per minute, avoiding timeouts during batch pricing runs.
Common mistakes
• Hardcoding back-end URLs or credentials in application code instead of using Destination service, breaking whenever landscape details change • Assuming the same connectivity pattern works identically for private cloud on-premise systems and S/4HANA Cloud Public Edition • Exposing more back-end resources through Cloud Connector than the extension actually needs, widening the attack surface • Embedding integration logic and retry handling inside every individual extension instead of centralizing it in an integration layer • Leaving connectivity ownership (network, Basis, BTP team) undefined, causing slow incident resolution • Deciding on principal propagation after go-live instead of during design, requiring rework across both landscapes
Best practices
• Use Destination service as the single configuration point for back-end connectivity details • Expose only the specific resources required through Cloud Connector, not entire back-end systems • Route higher-volume or multi-system integrations through a dedicated integration layer rather than embedding logic in each app • Decide on principal propagation requirements during design, not after go-live • Clearly assign ownership of each layer (network, Cloud Connector, destinations, back-end auth) before production cutover • Document the full runtime path for each integration so incident response does not require rediscovering it under pressure
Interview angle
Interviewers often probe whether a candidate can explain, step by step, how a BTP application actually reaches an on-premise system, and whether they understand the difference between direct destination calls and routing through an integration platform. Being able to name the failure points in the chain (destination, tunnel, back-end auth) signals real hands-on architecture experience rather than slide-level familiarity.