BTP Connectivity
Secure, reliable connectivity between SAP BTP cloud applications and on-premise systems. The Connectivity service provides the infrastructure layer for Cloud Connector tunnels, Destination configurations, and Private Link channels.
Executive Summary
The BTP Connectivity service manages the communication layer between BTP applications and non-BTP systems. It provides three connectivity patterns: Cloud Connector (reverse proxy tunnel for on-premise), Destination Service (centralised connection configuration), and Private Link (private network connectivity for PCE/hyperscaler-hosted systems). Every hybrid BTP scenario requires the Connectivity service.
Detailed Architecture
The Connectivity service is a BTP managed service (plan: lite) that must be bound to CAP apps. Three distinct patterns exist for different network topologies:
- Connectivity Service: BTP managed service (plan: lite) — must be bound to every CAP app that calls external systems
- Pattern 1 — Cloud Connector: for on-premise S/4HANA OP — outbound-only tunnel, no inbound firewall rules required
- Pattern 2 — Destination Service: central repository for HTTP/RFC/LDAP/mail connection configurations
- Pattern 3 — Private Link: direct private network peering for PCE, RISE, or hyperscaler-hosted systems
- HTTP connectivity: configured as Destinations of type HTTP, consumed by CAP via @sap/cloud-sdk automatically
- RFC connectivity: Destinations of type RFC — connects directly to ABAP function modules
- Principal propagation: user identity flows from BTP JWT → Cloud Connector → S/4HANA (SSO)
- Network flow: BTP app → Connectivity service → Cloud Connector (in DMZ) → S/4HANA
- Port mapping: Cloud Connector defines which on-premise hosts/ports are accessible (explicit allowlist)
CAP Service Example
A CAP service handler that consumes S/4HANA OData APIs via the Connectivity service and a configured Destination. CAP resolves the Destination binding automatically at runtime.
1// CAP service handler consuming S/4HANA via Destination
2// srv/sales-service.ts
3import cds from '@sap/cds'
4
5export class SalesService extends cds.ApplicationService {
6 async init() {
7 const s4 = await cds.connect.to('API_SALES_ORDER_SRV')
8
9 this.on('READ', 'SalesOrders', async (req) => {
10 // CAP automatically uses Destination binding + Cloud Connector
11 return await s4.run(req.query)
12 })
13
14 this.on('getTopOrders', async (req) => {
15 const { top = 10, currency = 'AED' } = req.data
16 return s4.run(
17 SELECT.from('A_SalesOrder')
18 .where({ TransactionCurrency: currency })
19 .orderBy({ TotalNetAmount: 'desc' })
20 .limit(top)
21 )
22 })
23
24 await super.init()
25 }
26}Enterprise Example (DEWA)
DEWA's CAP extension platform connects to on-premise S/4HANA 2023 in DEWA's corporate Abu Dhabi data center. Cloud Connector 2.17 is installed in DEWA's DMZ. The Connectivity service is bound to all 3 CAP applications. Principal propagation is configured — the end user's Azure AD identity flows through to S/4HANA for a complete audit trail. 15 Destinations are configured (6 HTTP OData, 3 RFC, 6 internal APIs).
Security Considerations
Best Practices
Bind Connectivity service to all CAP apps at deploy time — even if not immediately used. Zero cost and avoids runtime errors later.
For user-facing applications, configure principal propagation so the end user identity flows to S/4HANA for a complete audit trail.
Define one Destination per logical S/4 system (not per API endpoint). Multiple paths can share the same destination with different path prefixes.
Monitor tunnel health in the Cloud Connector admin console. Set up BTP alert notifications for tunnel disconnects.
Use X.509 certificate-based authentication for RFC destinations — more secure than username/password credentials.