Wer in einer SAP-Landschaft unterwegs ist, kommt an der SAP Analytics Cloud als Frontend kaum vorbei. Und wer gleichzeitig Snowflake als zentrales Data Warehouse betreibt, stand bislang vor einem echten Konfigurationsaufwand. Mit QRC1 2026 hat SAP das grundlegend vereinfacht: native Live-Verbindung, kein Agent, kein Gateway. In diesem Artikel zeigen wir, wie man die Verbindung aufsetzt, was das Modell-Konzept bedeutet und wo die Grenzen liegen.
Bevor man loslegt, gibt es eine technische Voraussetzung: Der SAC-Mandant muss auf SAP HANA Cloud laufen und der Data Access Agent muss aktiviert sein. Der Data Access Agent ist die Komponente, über die SAC live auf externe Quellen zugreift. Ohne ihn gibt es keine Live-Verbindung zu Snowflake.
Den Data Access Agent aktiviert man in der SAC-Administration unter Konfiguration der Datenquelle. Einmaliger Schritt, erfordert Admin-Rechte (Ausführungsrecht für SDA-Administration).
Danach geht man in SAC unter Verbindungen auf das "+" und wählt Snowflake. Hier nicht irritieren lassen, die Verbindung ist zwar unter „Acquire Data“ anstatt „Live-Data“ gelistet, aber am Ende der Konfiguration ist es trotzdem eine Live Verbindung.
Folgende Angaben sind nötig:
• Verbindungsname (frei wählbar)
• Snowflake Account Name
• Benutzername (der Snowflake-User, dem der Public Key zugewiesen wird)
• Privater Schlüssel (.p8-Datei)
• Passphrase – nur wenn der private Key verschlüsselt ist (dazu gleich mehr)
• Snowflake Datenbankname
Kein JDBC-Treiber, kein lokaler Agent, keine komplexe Installation. Verglichen mit dem alten Import-Setup ist das eine deutliche Vereinfachung.
Wichtiger Hinweis: Sofern der Snowflake User neu ist, muss diesem gegeben falls eine Standard Datenbank zugewiesen werden. Dies kann per SQL in der Snowflake geschehen, oder einfach durch öffnen einer beliebigen Datenbank. In dem Moment fragt dann das Snowflake System automatisch nach.
Die Live-Verbindung setzt auf Key-Pair-Authentifizierung. Das bedeutet: Statt Username und Passwort authentifiziert sich SAC über ein kryptografisches Schlüsselpaar. Der private Key bleibt auf dem SAC-System, der öffentliche Key wird dem Snowflake-User zugewiesen. Kein Passwort geht über das Netz.
Wer den privaten Key sicher aufbewahrt, kann auch ohne Passphrase arbeiten. In Produktivumgebungen empfehlen wir sie trotzdem.
Schritt 1: Private Key erstellen
Die OpenSSL-Befehle werden lokal im Terminal ausgeführt. Für Windows empfiehlt sich die Installation von OpenSSL (z.B. über Win32 OpenSSL: https://slproweb.com/products/Win32OpenSSL.html), auf macOS und Linux ist es in der Regel bereits vorinstalliert.
Alternativ kann man die Befehle auch direkt über SnowSQL ausführen, dies war unser bevorzugter Weg (https://docs.snowflake.com/en/user-guide/snowsql-install-config).
Unverschlüsselter Key (einfachste Variante):
openssl genrsa 2048 | openssl pkcs8 -topk8 -inform PEM -out rsa_key.p8 -nocryptopenssl genrsa 2048 | openssl pkcs8 -topk8 -inform PEM -out rsa_key.p8openssl rsa -in rsa_key.p8 -pubout -out rsa_key.pubIn Snowflake (als SECURITYADMIN oder mit OWNERSHIP-Rechten auf den User) einfach folgendes ausführen:
ALTER USER Mein User SET RSA_PUBLIC_KEY='<Mein Schlüssel Inhalt>';DESC USER Mein User;Wer bereits mit Live-Verbindungen zu SAP BW oder SAP Datasphere gearbeitet hat, muss hier umdenken. Die Snowflake-Verbindung funktioniert anders – konzeptuell ist sie näher an der Seamless Planning Connection als an einer klassischen BW Live Connection.
Modell anlegen
Das Modell wird im SAC Modeler über Start with Data angelegt. Als Datenquelle wählt man Snowflake, dann die angelegte Verbindung und anschließend eine View. Wichtig: SAC erwartet reguläre Snowflake Views. Snowflake Semantic Views - die neuere Objektschicht in Snowflake mit eigenen Logical Tables, Dimensions und Metrics - werden aktuell nicht unterstützt und können nicht als Basis für ein SAC-Modell verwendet werden. Auch bei regulären Views kann es vereinzelt zu Kompatibilitätsproblemen kommen, etwa wenn die View komplexe Konstrukte oder nicht unterstützte Datentypen enthält.
Im Anschluss wählt man als Verarbeitungsmethode Live Connection. Das Modell wird entlang der Struktur der View angelegt, man sieht sofort eine Datenvorschau. Dimensionen und Kennzahlen können angepasst, umbenannt und bei Bedarf entfernt werden. Live-Berechnungen sind auf Modellebene möglich.
Die Daten aus Snowflake stehen im Modell als sogenannte Live Version zur Verfügung. Das ist kein Planungsstand im klassischen Sinne - es ist eine direkte, nicht replizierte Ansicht der Quelldaten aus Snowflake, die live zur Laufzeit abgefragt wird.
Was man damit machen kann:
• Live-Versionsdaten in Charts, Tabellen und Stories anzeigen
• Live-Versionsdaten in Modell- und Story-Berechnungen referenzieren
• Live-Versionsdaten in Data Actions verwenden - inklusive Advanced Formulas
• Live-Versionsdaten via Copy/Paste oder Data Actions in Planungsversionen kopieren
Was nicht geht: direkt in die Snowflake-Quelle zurückschreiben. Die Live Version ist read-only. Plankorrekturen werden immer in den internen SAC-Planungsversionen gespeichert. Wer Plandaten zurück nach Snowflake übertragen möchte, kann das über separate Prozesse (z.B. Datenabzug aus SAC) realisieren - das ist aber nicht Bestandteil der Live Connection selbst.
SAC bietet Flexibilität: Wer die Daten repliziert haben möchte (bessere Performance bei großen Datenmengen, Offline-Verfügbarkeit), kann das weiterhin tun. Wer live aus Snowflake abfragt, ohne Replikation, wählt die Live Connection. In einer Story können beide Ansätze gleichzeitig genutzt werden - auch über mehrere Quellen hinweg.
Unterstützte Datentypen
SAC unterstützt bei der Snowflake Live Connection folgende Datentypen:
• Vollständig unterstützt: NUMBER, DECIMAL, VARCHAR, DATE, TIMESTAMP, TIMESTAMP_LTZ, TIMESTAMP_NTZ, TIMESTAMP_TZ
• Als Text interpretiert (funktioniert, aber mit Einschränkungen): FLOAT, TIME – diese können im Modeler angepasst werden, was aber zu Performance-Einbußen führen kann. Empfehlung: Datentypen direkt in der Snowflake-View anpassen.
• Eingeschränkt unterstützt (können Validierungs- oder Story-Fehler verursachen): ARRAY, GEOGRAPHY, GEOMETRY, OBJECT, VARIANT
• Nicht unterstützte Datentypen: Alles außerhalb der obigen Liste wird von SAC automatisch erkannt und verhindert das Anlegen des Modells. In dem Fall muss die View in Snowflake angepasst werden, bevor man weitermachen kann.
Das ist der Teil, der in der Praxis am meisten interessiert. Die kurze Antwort: Im Grunde alles, was SAC Stories können - weil SAC das SAC-Modell mit Snowflake Live Connection wie jedes andere SAC Analytical Model behandelt. Die Story "weiß" nicht, dass im Hintergrund Snowflake steckt. Alle Story-Features, die mit einem normalen SAC-Modell funktionieren, stehen zur Verfügung.
Das bedeutet konkret:
Charts und Tabellen in allen verfügbaren Typen - Balken, Linien, Wasserfall, Pareto, Fläche, Geo- Charts, etc.
Filter, Input Controls, Linked Analysis
Berechnete Kennzahlen und Dimensionen auf Story-Ebene
Thresholds und bedingte Formatierungen
Scripting und API-Zugriff auf das Modell
Bookmarks
Mehrere Modelle in einer Story - auch gemischt mit Datasphere- oder anderen Quellen
Story Versioning: bis zu 10 Versionen pro Story speichern und wiederherstellen
Zentrales Kommentar-Management
Auch Planungsfunktionen stehen zur Verfügung: Planungsmodelle können direkt auf Basis von Snowflake-Views erstellt werden. Die Live Version aus Snowflake dient als Ist-Datengrundlage. Wichtig dabei: Plandaten werden immer in den internen SAC-Planungsversionen gespeichert - ein direktes Zurückschreiben in Snowflake ist nicht möglich. Außerdem gilt diese Funktionalität nur für SAC-Modelle, die direkt in SAC angelegt wurden. Anders als bei Seamless Planning mit SAP Datasphere können Snowflake-basierte Modelle nicht auf Datasphere deployed werden - das SAC-Modell mit Snowflake Live Connection bleibt immer ein natives SAC-Modell.
My Metrics
My Metrics ist kein Story-Feature, sondern ein eigenständiger Bereich in SAC - aber er funktioniert ebenfalls mit SAC-Modellen mit Snowflake Live Connection. Mit den letzten Updates wurden My Metrics außerdem deutlich aufgewertet: Nutzer können KPI-Reports abonnieren und sich diese nach Zeitplan per E-Mail zusenden lassen. Wer Snowflake als Datenbasis nutzt, kann diesen Workflow vollständig nutzen.
Data Analyzer
Auch der Data Analyzer funktioniert ohne Einschränkungen - ad-hoc Analysen, Drag-and-Drop, Kennzahlen kreuzen, alles direkt auf den Live-Snowflake-Daten. Da SAC das SAC-Modell mit Snowflake Live Connection wie jedes andere Analytical Model behandelt, gibt es innerhalb von SAC grundsätzlich keine werkzeugspezifischen Sonderregeln.
SAC Excel Plugin
Das SAC Add-in für Excel kann ebenfalls auf SAC-Modelle mit Snowflake Live Connection zugreifen. Fachbereiche, die ihre Analysen lieber in Excel machen, bekommen damit die Flexibilität von Excel kombiniert mit Live-Daten direkt aus Snowflake - kein manueller Export, keine veralteten Zahlen.
Wer direkt einsteigen will, sollte diese Punkte kennen:
Nur reguläre Snowflake Views: Snowflake Semantic Views werden nicht unterstützt. Auch bei einzelnen regulären Views kann es zu Kompatibilitätsproblemen kommen - das sollte im Setup getestet werden.
Data Access Agent ist Pflicht: Für Mandanten, die nicht auf SAP HANA Cloud laufen, ist die Live-Verbindung aktuell nicht verfügbar.
Kein Zurückschreiben via Live Connection: Die Live Version ist read-only. Plandaten nach Snowflake exportieren geht generell, aber nicht über die direkte Verbindung.
Wer bisher Daten nach dem Import in der SAC über den Data Wrangler nachbearbeitet hat, muss bei Live-Verbindungen umdenken. Für Snowflake, Google BigQuery und perspektivisch auch SharePoint steht der Data Wrangler aktuell nicht zur Verfügung. Die Daten sollten bereits im Quellsystem in einem sauberen, konsumfähigen Zustand vorliegen – sprich: Gold Standard. Besonders betroffen sind Stories, die mit mehreren Quellen und Data Blending arbeiten, denn die Daten aus den verschiedenen Modellen müssen zusammenpassen – und ohne Data Wrangler muss das im jeweiligen Quellsystem sichergestellt werden.
SAP ist sich bewusst, dass das ein echter Schmerzpunkt ist. Eine grundlegend neue Lösung soll geplant sein – leistungsfähiger, mit SQL und möglicherweise auch Python als Transformationssprachen. Offizielle Roadmap-Einträge dazu gibt es aktuell nicht, und wer die SAC-Geschichte kennt, weiß, dass ähnliche Vorhaben schon einmal still und leise wieder verschwunden sind. Wir bleiben gespannt, ob und wann er kommt.
Snowflake und SAP Snowflake
Warum Snowflake nicht gleich Snowflake ist: Hier lohnt sich ein wichtiger Hinweis. Es gibt reguläres Snowflake und SAP Snowflake. Technisch handelt es sich um dasselbe Produkt - SAP Snowflake ist jedoch eine von SAP gemanagte Solution Extension, die direkt über SAP beschafft wird und - entscheidend - im selben Rechenzentrum wie SAC, SAP Business Data Cloud und Datasphere betrieben werden kann. Snowflake empfiehlt in der eigenen Dokumentation explizit, SAP Snowflake in derselben Region wie das SAP BDC Cockpit zu provisionieren. Wenn das der Fall ist, ist die Performance gut. Wenn Snowflake und SAC hingegen in unterschiedlichen Regionen oder Rechenzentren betrieben werden, kann die Performance deutlich schlechter ausfallen - das deckt sich mit unserer Projekterfahrung, wo wir die Live Connection zu einem externen Snowflake-System als tendenziell langsamer empfunden haben als vergleichbare Live Connections zu SAP Datasphere oder SAP BW. Die Empfehlung: Wer SAP Snowflake nutzt, sollte auf eine gemeinsame Region achten. Wer ein bestehendes Snowflake-System anbindet, sollte die regionale Nähe prüfen und ein dediziertes Warehouse für SAC-Abfragen einrichten.
Die native Live-Verbindung zwischen SAC und Snowflake ist ein echter Fortschritt. Kein externer Agent, keine JDBC-Konfiguration, keine Replikationspflicht, kein Passwort-Auth-Problem. Für Unternehmen, die Snowflake als zentrales Data Warehouse nutzen und SAC als Frontend einsetzen wollen, ist das der bisher sauberste Weg.
Was bleibt: Das Modell-Konzept mit der Live Version ist nicht dasselbe wie eine BW oder Datasphere Live Connection. Wer das versteht und die Einschränkungen - insbesondere bei Views und gegeben falls Performance - im Blick hat, kann die Verbindung gut einsetzen. Wer lieber repliziert, kann das weiterhin tun. Beides ist möglich, und das ist genau die Flexibilität, die man sich von einer modernen Konnektivität erwartet.
Ein Wermutstropfen bleibt allerdings: Man kann nicht direkt auf Snowflake durchgreifen - es muss immer erst ein SAC-Modell angelegt werden, das dann auf eine Snowflake View zeigt. Für einzelne Anwendungsfälle ist das völlig in Ordnung, aber wer viele Modelle für ein großes Reporting-Portfolio aufbauen will, sollte den initialen Konfigurationsaufwand einplanen.
Wenn Sie die SAC-Snowflake Live-Verbindung in Ihrer Landschaft evaluieren oder optimal aufsetzen möchten, kontaktieren Sie uns gerne für eine unverbindliche Beratung.