Here's the classic hybrid-landscape problem: your integration flows run in the cloud, but the S/4HANA system they need sits behind a corporate firewall that (quite rightly) accepts no inbound connections from the internet. How does a cloud iFlow reach an on-premise system that won't let the outside world in?
The answer is the SAP Cloud Connector — and the trick is that the connection is established outbound, from inside your network.
The reverse-invoke trick
The Cloud Connector is a small on-premise agent you install inside your corporate network. On startup, it opens an outbound TLS tunnel to your SAP BTP subaccount. Firewalls love outbound connections — they're the same kind your browser makes all day — so no inbound firewall rules, no DMZ, no exposed ports.
Once the tunnel is up, cloud applications can "reverse-invoke" through it: a request from Cloud Integration travels down the already-open tunnel to the Connector, which forwards it to the internal system (S/4HANA, a database, a file share) and returns the response. From the iFlow's perspective, it's just calling a URL. The firewall never sees an inbound connection, because technically there isn't one.
Key takeaway: Cloud Connector opens an outbound TLS tunnel from your network to BTP, letting cloud apps reach on-premise systems without any inbound firewall holes.
What it fronts
The Connector doesn't just tunnel HTTP. It fronts the protocols your on-premise systems actually speak:
HTTP/HTTPS — OData services, REST APIs, SAP GUI for HTML, web services. The bread and butter.
RFC — classic ABAP remote function calls, still everywhere in SAP landscapes.
Databases — JDBC access to on-premise databases for direct reads.
File shares — SFTP/ SMB-mounted directories for file-based scenarios.
Each backend system is registered as a "virtual" mapping in the Connector: internal host s4prod.corp:8000 becomes reachable from the cloud as something like s4prod:443 on the Connector's cloud-facing side. Access control lists define exactly which cloud subaccounts and applications may use which mappings — least privilege, enforced at the tunnel.
High availability and operations
One Connector is a single point of failure, so production setups run shadow instances: a primary and a standby that take over automatically. The tunnel is persistent with keep-alives and automatic reconnect — brief network blips don't break everything, though in-flight requests during a failover may need retry logic in the calling flow.
Operationally, the Connector is refreshingly low-drama: it's a lightweight Java process with a web admin UI, certificate-based trust to the BTP subaccount, and audit logging of every tunneled connection. The main things to watch are certificate expiry (the tunnel's TLS certs, like all certs, expire) and making sure the host it runs on gets patched like any other infrastructure.
Where it sits in the architecture
Typical flow, end to end: a Cloud Integration iFlow needs customer master from on-premise S/4HANA. The iFlow's receiver channel points at the Cloud Connector's virtual host. The request rides the TLS tunnel down, the Connector forwards it to the real S/4HANA host inside the firewall, the response comes back up the same tunnel. Total firewall configuration required: zero inbound rules.
When someone asks "how does a cloud iFlow reach an on-premise S/4HANA behind a firewall" — this is the answer. Not VPNs, not firewall exceptions, not exposing the ERP to the internet. An outbound tunnel, reverse-invoked, with per-mapping access control.
Setting one up: the short version
Installation is deliberately unglamorous. Download the Connector for your platform, install it on a host inside the network (not on the S/4HANA box itself — a dedicated VM is cleaner), and run the initial setup: point it at your BTP region's connectivity endpoint, generate the system certificate, and upload it to the subaccount's trust store. Then add a backend mapping: internal host, port, protocol, virtual host name, and which subaccounts may use it. First end-to-end test: an iFlow calling the virtual host should reach the internal service. Total time for a straightforward HTTP mapping is well under an hour — the RFC and database mappings take a little longer.
Certificate lifecycle
The tunnel's trust rests on certificates in both directions, and they expire. The Connector's system certificate (typically 2-year validity) authenticates it to BTP; the backend system's TLS certificates secure the last hop inside your network. Put both expiry dates in your monitoring — a lapsed Connector certificate severs all tunneled connectivity at once, which is a spectacular way to learn about certificate management. Rotate proactively: generate the new cert, upload to BTP, switch over, verify, then retire the old one.
Troubleshooting connectivity
When a flow can't reach the backend, diagnose in layers. 1. Is the tunnel up? Check the Connector admin UI — connected subaccounts and tunnel status are right there. 2. Is the mapping reachable? Use the Connector's built-in connectivity check for the virtual host. 3. Is it the backend? Try the internal host directly from the Connector machine to rule out backend issues. 4. Is it authorization? Verify the subaccount is in the mapping's access control list — a working tunnel with a missing ACL entry produces confusing "not found" style errors. Nine times out of ten, the answer is in one of these four layers.
Key takeaway: SAP Cloud Connector is the standard answer for cloud-to-on-premise connectivity — outbound TLS tunnel, no inbound firewall rules, protocol support for HTTP/RFC/JDBC/files, and shadow instances for HA. If your iFlow needs on-premise data, it goes through here.