Von der Theorie zur Praxis: So verbinden Sie SAP BDC technisch mit Snowflake

In unserem ersten Blogbeitrag haben wir gezeigt, warum die Partnerschaft von SAP und Snowflake den Weg für eine echte Datendemokratisierung ebnet und wie das Zusammenspiel aus SAP Business Data Cloud (BDC) und der Snowflake AI Data Cloud konzeptionell funktioniert. In diesem Beitrag gehen wir einen Schritt weiter. Wir zeigen, welche Voraussetzungen für eine Anbindung notwendig sind und wie die technische Einrichtung von SAP BDC Connect for Snowflake konkret abläuft.

Wichtig für die Einordnung: Wir zeigen hier die Anbindung eines bereits bestehenden, eigenständigen Snowflake-Kontos an die BDC über SAP BDC Connect for Snowflake – nicht SAP Snowflake, die SAP-verwaltete Solution-Extension-Variante, bei der SAP eine vollständig integrierte Snowflake-Instanz automatisiert bereitstellt und betreibt.

Voraussetzungen vor dem ersten Klick

Bevor die eigentliche Einrichtung beginnt, lohnt sich ein Blick auf einige Rahmenbedingungen, die über Erfolg oder Frustration entscheiden:

• Cloud-Kompatibilität: Für die SAP-Seite besteht eine Hyperscaler-Bindung. Damit ist gemeint, dass das SAP-Quellsystem und die BDC Connect-Instanz auf demselben Hyperscaler und in derselben Region laufen müssen. Das Snowflake-Konto ist davon unabhängig und kann auf einem anderen Hyperscaler oder in einer anderen Region liegen. Zum Beispiel ist eine Kombination aus SAP-Quellsystem und BDC Connect auf AWS mit einem Snowflake-Konto auf einem anderen Hyperscaler oder in einer anderen Region möglich.
• Berechtigungen in Snowflake: Die Nutzungsbedingungen für den Connector müssen einmalig von einem ORGADMIN in Snowflake akzeptiert werden. Ohne diesen Schritt taucht der Zero-Copy-Connector im Menü gar nicht erst auf.
• Berechtigungen in SAP: Auf SAP-Seite braucht es einen S-User mit Zugriff auf SAP for Me sowie die passenden Rollen, um in der BDC Anwendungen zu provisionieren und Datenprodukte freizugeben.
• Datenprodukte: Welche Datenprodukte zur Verfügung stehen, hängt vom SAP-Setup ab. Die vorkonfigurierten Standard-Datenprodukte stehen nur Kunden zur Verfügung, die S/4HANA in der Private oder Public Cloud betreiben. Wer stattdessen ein SAP ECC- oder ein S/4HANA-On-Premise-System an die BDC angebunden hat, kann eigene, custom Datenprodukte bereitstellen.

Sind diese Punkte geklärt, kann die eigentliche Einrichtung beginnen.

Schritt für Schritt: Die Einrichtung des Zero-Copy-Connectors

1. Nutzungsbedingungen akzeptieren

Der erste Schritt findet in Snowflake statt, allerdings nicht im Ingestion-Menü, sondern im Bereich Admin unter Terms. Nur ein ORGADMIN kann die zusätzlichen Nutzungsbedingungen für SAP BDC Connect for Snowflake akzeptieren. Dieser Schritt ist einmalig pro Snowflake-Organisation notwendig und schaltet den Connector für alle Accounts der Organisation frei.

2. Zero-Copy Connectors aufrufen

In der Snowflake-Menüleiste unter „Work with data" führt der Weg über Ingestion zu Zero-Copy. Dort erscheint die Übersicht der verfügbaren Zero-Copy-Connectoren, aktuell unter anderem SAP BDC Connect for Snowflake.

3. Connector auswählen

Über die Kachel von SAP BDC Connect for Snowflake gelangt man mit einem Klick auf Connect in den Einrichtungsdialog.

4. Connector benennen und platzieren

Im ersten Teil des Dialogs vergibt man einen Namen für den Connector und legt fest, in welcher Datenbank und welchem Schema das Connector-Objekt abgelegt werden soll. Wichtig zu wissen: In dieser Datenbank wird ausschließlich das Connector-Objekt selbst gespeichert, nicht die eigentlichen SAP-Daten. Sie dient rein der technischen Organisation innerhalb des Snowflake-Kontos.

5. Verbindung zu SAP BDC herstellen

Danach öffnet sich ein Wizard, der die eigentliche Kopplung zwischen Snowflake und SAP BDC herstellt. Snowflake stellt einen Unique Connector Identifier bereit, der in SAP BDC im Feld External System Instance Identifier hinterlegt werden muss. Im Gegenzug generiert SAP BDC einen Invitation-Link, der zurück in Snowflake in den Wizard eingetragen wird. Der Invitation-Link lässt sich laut SAP nur einmal für die Verbindung nutzen und verliert danach seine Gültigkeit. Erst mit diesem beidseitigen Austausch wissen beide Systeme, dass sie zueinander gehören.

6. Verbindung abschließen und provisionieren

Ein Klick auf Connect schließt die Einrichtung auf Snowflake-Seite ab. Anschließend muss die Verbindung auch in SAP BDC Connect provisioniert werden. Dieser Vorgang kann einige Minuten dauern, bevor der Status auf „Processing" oder „Ready" wechselt.

7. Datenprodukte in SAP BDC freigeben

Ist die Provisionierung abgeschlossen, werden in SAP BDC Connect die gewünschten Datenprodukte für die Freigabe an Snowflake ausgewählt. Je nach SAP-Landschaft stehen hier entweder die Standard-Datenprodukte oder individuell modellierte, custom Datenprodukte zur Verfügung. Damit die Freigabe-Option überhaupt sichtbar ist, braucht der Nutzer die Rolle „Data Catalog Administrator“, und die Ziel-Snowflake-Instanz muss Teil derselben Formation wie das Quellsystem sein – fehlt eine der beiden Voraussetzungen, bleibt der Share-Button ausgegraut.

8. Datenprodukte in Snowflake mounten

Sobald ein Datenprodukt in SAP BDC freigegeben ist, erscheint es in Snowflake in der Connector-Übersicht mit dem Status „Unmounted". Mounten bedeutet an dieser Stelle, dass aus der reinen Freigabe ein nutzbares Objekt im Snowflake-Account wird. Erst durch das Mounten legt Snowflake die zugehörige Catalog-linked Database mit allen Schemas und Tabellenreferenzen an. Vor dem Mounten ist das Datenprodukt zwar sichtbar, aber technisch noch nicht im Account nutzbar.

9. Datenbank benennen

Vor dem Mounten lässt sich der Name der Catalog-linked Database anpassen. Verzichtet man darauf, übernimmt Snowflake automatisch den Namen des Datenprodukts aus SAP BDC eins zu eins als Datenbanknamen.

Was beim Mounten technisch entsteht

Nach dem Mounten legt Snowflake automatisch eine eigenständige Catalog-linked Database an, die aus drei Bestandteilen besteht:

• INFORMATION_SCHEMA: das übliche Metadaten-Schema jeder Snowflake-Datenbank.
• SNOWFLAKE$-Schema: enthält die Semantic View des Datenprodukts mit allen semantischen Informationen aus SAP.
• Tabellen-Schema (benannt nach dem SAP-Datenprodukt, z. B. dp_ordertocash_srv:v1): enthält die eigentlichen Tabellen.

Bei diesen Tabellen handelt es sich um Iceberg-kompatible Tabellen, die über eine Catalog Integration auf die Daten zugreifen, die SAP im Hintergrund als Delta-Tabellen im HANA Data Lake Files Storage (HDLF) der SAP BDC ablegt. Snowflake kopiert dabei keine Daten in den eigenen Account, sondern registriert lediglich die Metadaten und greift bei jeder Abfrage live auf den Datenbestand in SAP zu. Das ist der Kern des Zero-Copy-Ansatzes: Die Daten bleiben physisch dort, wo sie entstanden sind.

Ein Blick in eine reale Verbindung zeigt das Prinzip: Aus dem Datenprodukt DP_OrderToCash.DELTA_SHARING:v1 entsteht nach dem Mounten die Datenbank SAP_ORDERTOCASH mit dem Tabellen-Schema dp_ordertocash_srv:v1, in dem unter anderem die Tabellen ad_hdlf_sd_lt_businesspartner, ad_hdlf_sd_lt_salesdocitem und vbak liegen.

Die Semantic View: Business-Kontext statt kryptischer Feldnamen

Im Schema SNOWFLAKE$ legt der Wizard automatisch ein Objekt vom Typ Semantic View an. Darin werden die klassischen SAP-Bezeichnungen in verständliche Business-Begriffe übersetzt: Statt technischer Tabellennamen wie in den zugrunde liegenden SAP-Tabellen stehen in der Semantic View sprechende Bezeichnungen zur Verfügung. So wird aus der SAP-Tabelle ad_hdlf_sd_lt_businesspartner in der Semantic View die logische Tabelle „Business Partner HDLF Table", aus ad_hdlf_sd_lt_salesdocitem entsprechend „Sales Document Item HDLF Table". Auch die klassische SAP-Tabelle VBAK, die im Tabellen-Schema nur unter diesem vierstelligen Kürzel erscheint, bekommt so ihre sprechende Bezeichnung im SAP-Data-Dictionary als „Verkaufsbeleg: Kopfdaten" hinterlegt.

Zu jeder logischen Tabelle in der Semantic View gehören zudem strukturierte Kategorien:

• Dimensions: beschreibende Attribute, etwa Kundennummer oder Vertriebsorganisation
• Time Dimensions: zeitbezogene Attribute für Trend- und Periodenanalysen
• Facts: die eigentlichen Kennzahlen und Messwerte
• Named Filters: vordefinierte, wiederverwendbare Filterbedingungen
• Metrics: aggregierte Kennzahlen, die auf den Facts aufbauen

Diese Struktur ist die Grundlage für Snowflake Cortex Analyst. Cortex Analyst nutzt genau diese semantische Beschreibung, um natürlichsprachliche Fragen von Fachanwendern in korrekte SQL-Abfragen zu übersetzen. Ohne die klare Trennung in Dimensionen, Fakten und Metriken könnte der Agent die Business-Logik hinter den SAP-Tabellen nicht zuverlässig interpretieren.

Der große Vorteil: Alle drei Schemas, die Tabellenreferenzen und die Semantic View werden vom Wizard vollautomatisch angelegt. Ein manuelles Nachmodellieren der SAP-Semantik in Snowflake entfällt vollständig.

Zusammenführen mit Non-SAP-Daten

In Snowflake werden SAP-Datenprodukte wie ganz normale Tabellen behandelt. Dadurch lassen sich SAP- und Non-SAP-Daten in Snowflake problemlos joinen und gemeinsam weiterverarbeiten.

Grenzen und Stolpersteine in der Praxis

So reibungslos der Wizard im Idealfall wirkt, sollten dennoch vorab ein paar Punkte eingeplant werden:

• Cloud-Grenze: Die Cloud-Bindung betrifft, wie erwähnt, nur SAP-Quellsystem und BDC Connect – hier müssen Hyperscaler und Region übereinstimmen. Für die Snowflake-Seite gilt diese Einschränkung nicht, sie kann auf einem anderen Hyperscaler oder in einer anderen Region liegen.
• Erste Einrichtung braucht Geduld: Bis Unique Connector Identifier, Invitation-Link und Provisionierung sauber zusammenspielen, sind in der Praxis oft mehrere Anläufe nötig, insbesondere wenn Rollen oder Freigaben zunächst fehlen.
• Berechtigungen auf beiden Seiten: Ohne passende Rollen und Freigaben, sowohl in SAP BDC als auch in Snowflake, geht an mehreren Stellen im Prozess nichts voran. Es lohnt sich, frühzeitig zu klären, wer auf beiden Seiten als Admin zur Verfügung steht.

Fazit: Vom Konzept zur lauffähigen Verbindung

Was im ersten Beitrag als architektonisches Prinzip beschrieben wurde, lässt sich in der Praxis in überschaubaren Schritten umsetzen. Der Wizard nimmt Snowflake-Anwendern die komplette technische Modellierung ab, von der Anlage der Datenbanken über die Iceberg-Tabellen bis zur Semantic View. Der eigentliche Aufwand verschiebt sich damit weg vom Data Engineering hin zur organisatorischen Vorbereitung: Berechtigungen klären, Cloud-Umgebungen abgleichen und entscheiden, welche Datenprodukte welchen Teams zur Verfügung stehen sollen.

Wer diesen Weg gemeinsam mit einem erfahrenen Partner gehen möchte: Bei adesso SE unterstützen wir Sie sowohl bei der SAP-seitigen Bereitstellung der Datenprodukte als auch bei der Snowflake-seitigen Einrichtung, Governance und Nutzung für Cortex Analyst. Sprechen Sie uns an.