In nahezu jedem SAP-Analytics-Cloud-Projekt mit on-premise BW kommt früh dieselbe Architekturfrage: Direct Connection oder Tunnel Connection? Die Antwort wird oft als reine Infrastrukturentscheidung behandelt – „der Tunnel ist halt sicherer, kommt aber später“ – und genau das rächt sich später.
Denn die Verbindungsart entscheidet darüber, welche SAC-Features eure Endnutzer überhaupt nutzen können. Und sie bringt eine Skalierungsfalle mit, die in Großkundenrollouts gerade reihenweise zuschnappt.
Tunnel oder Direct
Tunnel ist für die meisten BW-Szenarien heute der strategisch richtige Default. Direct braucht ihr nur noch für zwei Dinge: die SAC Mobile App und das klassische SAP Analysis for Microsoft Office. Bei großen Rollouts kommt ein technisches Watch-Out dazu – die fehlende HTTP/2-Unterstützung im Cloud Connector.
Der kurze technische Unterschied
Bei der Direct Connection spricht der Browser des Endnutzers direkt mit dem BW. Das setzt voraus, dass das BW über das Internet erreichbar ist – in der Regel über einen Reverse Proxy oder SAP Web Dispatcher mit öffentlichem DNS-Eintrag und CA-signiertem Zertifikat.
Bei der Tunnel Connection läuft der Datenfluss anders: SAC → SAP Cloud Connector → BW. Der Cloud Connector baut die Verbindung von innen nach außen zum SAC-Tenant auf. Das BW bleibt im internen Netz, kein eingehender Port, keine Public-DNS-Veröffentlichung.
Was für den Tunnel spricht – die üblichen Argumente
- Endnutzer brauchen kein VPN. Wer aus dem Homeoffice oder als externer Berater auf SAC zugreift, kommt ohne Einwahl an die Daten.
- Kein Inbound-Port, kein Public DNS, kein öffentliches Server-Zertifikat fürs BW. Die Security-Abteilung freut sich, die Time-to-Production verkürzt sich.
- Cross-Origin- und SameSite-Cookie-Probleme entfallen. Wer schon mal eine Story-Kachel weiß bleiben gesehen hat, weiß warum das wichtig ist.
- Feingranulare Pfad-Freigabe. Im Cloud Connector wird nur
/sap/bw/ina/erlaubt – das BW ist nicht vollständig exponiert. - Audit und Monitoring an einer Stelle. Alle Live-Zugriffe landen in den Logs des Cloud Connectors.
Soweit so bekannt. Spannender wird es bei der nächsten Ebene.
Die wirklich entscheidenden Features: nur mit Tunnel
Dieser Punkt wird in vielen Architektur-Workshops übersehen: eine ganze Reihe von SAC-Features läuft technisch nur dann, wenn SAC serverseitig Daten ziehen darf – und das setzt einen Tunnel voraus, freigeschaltet über den Schalter „Allow live data to leave my network“.
Publication / Bursting. Zeitgesteuerter, personalisierter Story-Versand an viele Empfänger – als PDF, PPTX oder XLSX, jeweils mit dem Filter- und Berechtigungskontext des einzelnen Empfängers. Oft der eigentliche Business Case im Management-Reporting. Läuft serverseitig, braucht Tunnel.
SAC Add-in für Microsoft Office (Excel, Word, PowerPoint). Das neue Office-Add-in (nicht zu verwechseln mit dem klassischen SAP Analysis for Microsoft Office) unterstützt Live-Zugriff auf SAP BW und S/4HANA – ausschließlich über Tunnel. Direct funktioniert technisch nicht, der Office-Container blockt Cross-Domain-Aufrufe. Wer Controlling-Teams in Excel arbeiten lässt oder Management-Decks aus SAC heraus baut, hat keine Wahl.
Smart Insights, Search to Insight, Notifications, Calendar Tasks, Multi-Action-Scheduling. Alle „Advanced Features“ haben gemeinsam, dass SAC im Hintergrund Abfragen feuert – ohne dass ein Browser läuft. Dasselbe gilt für datenbasierte Benachrichtigungen, geplante Datenaktionen in BW-IP-Szenarien und Story-/Daten-APIs für Embedded-Use-Cases.
Was Tunnel nicht kann – wichtige Einschränkungen
Damit das Bild ehrlich bleibt:
- SAC Mobile App. Tunnel-Verbindungen werden auf der SAC Mobile App nicht unterstützt. Wer Stories auf iOS/Android-Geräten zeigen will, braucht zusätzlich eine Direct Connection oder muss mit Browser-Mobile-Zugriff leben.
- SAP Analysis for Microsoft Office (das klassische AfO). Das ältere Excel-Frontend funktioniert nur mit Direct Connection.
- Performance bei Großrollouts. Der gesamte Datenfluss läuft durch den Cloud Connector. Und damit kommen wir zum aktuell wichtigsten Watch-Out.
Watch-Out: Die HTTP/2-Bremse im Cloud Connector
Wer SAC produktiv mit BW betreibt, hat in den letzten Monaten vermutlich dieselbe Erfahrung gemacht: Mit jeder neuen Story, mit jeder zusätzlichen Nutzergruppe steigt die Last auf dem BW stärker als linear.
Der Grund liegt nicht in den Stories und nicht in der Hardware, sondern in einer technischen Lücke der Standardarchitektur: Der SAP Cloud Connector unterstützt kein HTTP/2 – bestätigt in SAP KBA 3312628. Sowohl das BW (icm/HTTP/support_http2 = TRUE) als auch der Web Dispatcher könnten HTTP/2 sprechen; der Cloud Connector dazwischen kann es nicht. Die gesamte Kette SAC → CC → Web Dispatcher → BW fällt auf HTTP/1.1 zurück.
Die Folge: Kein Request-Multiplexing. Jede InA-Abfrage – und davon erzeugt eine moderne Story mit vielen Widgets ein Vielfaches – braucht eine eigene HTTP-Verbindung. Auf dem ABAP-Stack landet daraus eine eigene Backend-Session.
In großen Landschaften sehen wir genau dieses Bild – und es deckt sich mit der SAP-Influence-Idee 369769 („Support for HTTP/2 in SAP Cloud Connector“, Status Acknowledged):
- Über 2.000 gleichzeitige HTTPS-Sessions auf dem BW – bei deutlich weniger aktiven Endnutzern.
- Mehr Backend-Sessions pro User als erwartet, auch wenn der SAC-Parameter „Number of parallel sessions for BW data sources“ bereits auf 8 reduziert ist.
- Wachsender Speicherverbrauch auf dem ABAP-Stack, bis hin zu Stabilitätswarnungen.
- Performance-Einbrüche bei Stories mit vielen Visualisierungen pro Page.
Mitigations bis SAP die Lücke schließt: mehrere Cloud Connectors als High Availability, „Number of parallel sessions for BW data sources“ gezielt auf 4–8 setzen, ABAP-ICM- und Workprozess-Parameter auf das User-Volumen abstimmen, Optimized Stories mit bewusst niedriger Widget-Anzahl, gestaffeltes statt gleichzeitiges Bursting, konsequentes Monitoring von ABAP-Sessions und Cloud-Connector-Logs.
Und: Voten. Die Influence-Idee braucht Stimmen, damit SAP das Thema in den Backlog hebt: Vote „Support for HTTP/2 in SAP Cloud Connector“ (Influence ID 369769)
Was wir in Projekten sehen
Pattern A – Tunnel only. Für SAC-zentrierte Landschaften ohne Mobile-App-Bedarf. Klar dominant: weniger Public-Exposure, mehr Features, schnellerer Rollout.
Pattern B – Tunnel + Direct parallel. Pro BW-Quelle werden in SAC zwei Verbindungen gepflegt – eine Tunnel-Verbindung für Stories, Add-ins und Bursting, eine Direct-Verbindung für Mobile und Analysis Office. Mehr Aufwand, aber bei Mischbetrieb meist unausweichlich.
Die wichtigste Empfehlung aus der Beratungspraxis
Use Cases vor Infrastruktur klären. Vor der Architekturentscheidung:
- Soll Bursting genutzt werden?
- Wird das neue Office-Add-in als Standard für Controlling gesetzt?
- Brauchen Außendienst oder Management die SAC Mobile App?
- Ist Analysis Office strategisch noch im Scope?
- Welche User-Zahlen werden auf der gemeinsamen BW-Quelle erwartet – und ist HTTP/2-Skalierung dann ein Thema?
Erst danach steht die Verbindungsstrategie. Andersherum – Infrastruktur zuerst, Features später – führt regelmäßig zu unangenehmen Überraschungen im Q3-Roadmap-Workshop.
Fazit
Tunnel oder Direct ist keine Netzwerk-, sondern eine Feature-Entscheidung. Tunnel ist in den meisten BW-/SAC-Szenarien heute die strategisch richtige Wahl: weniger Sicherheitsrisiken, mehr Features, niedrigere Hürden für externe Nutzer.
Die zwei Themen, die ihr trotzdem aktiv adressieren müsst: die Mobile-/AfO-Lücke und – bei Großrollouts – die HTTP/2-Bremse im Cloud Connector. Wer beides früh ins Architektur-Design einplant, vermeidet zwei Monate später unangenehme Diskussionen mit dem Fachbereich.
Quellen / weiterführend
- SAP Influence-Idee 369769 – „Support for HTTP/2 in SAP Cloud Connector“ (Status: Acknowledged, April 2026)
- SAP KBA 3312628 – HTTP/2 Support im SAP Cloud Connector
- SAP Help – Live Data Connection to SAP BW Using a Tunnel Connection
- SAP Note 2541557 – BW-Korrekturhinweise für SAC Live Connection
