Konzeptkarte

Datasphere Replication Flows für KI-Grounding

Stand 2026-07-24T14:00:00Z

Redaktion: Cédric-Olivier Mâry, alleiniger Redakteur und verantwortlich für die Veröffentlichung — 27 Jahre im SAP-Ökosystem. Wie diese Seiten entstehen und wo Automatisierung eingesetzt wird.

Was ist Datasphere Replication Flows für KI-Grounding?

Der konkrete Fehler, den dies verhindert, ist entweder ein Agent, der eine Anfrage ablehnt (sicher, aber nutzlos), oder einer, der aus einem veralteten Cache antwortet (gefährlich) – die Lösung ist ein Delta-Replication-Flow plus DAC plus Registrierung im Knowledge Graph, mit einer angestrebten Aktualität von 5-30 Minuten.

Worum es geht

Replication Flows in SAP Datasphere sind verwaltete Pipelines, die Quellsystemtabellen — S/4HANA, ECC, SuccessFactors, Drittanbieter-JDBC-Quellen — nach einem Zeitplan oder per Change Data Capture in einen Datasphere Space übertragen. Diese Beschreibung war vor der Ankunft generativer KI zutreffend, und sie ist es immer noch. Was sich geändert hat, ist die zweite Aufgabe, die Replication Flows nun erfüllen — eine Aufgabe, die die meisten Teams erst entdecken, nachdem Joule produktiv geht: Sie sind der primäre Mechanismus, um Antworten großer Sprachmodelle in faktischen, governten Unternehmensdaten zu verankern, statt in dem, was das Modell während des Trainings zufällig memoriert hat.

Das Grounding-Problem ist leicht zu erkennen, sobald man danach sucht. Ein Joule-Agent, der offene Bestellungen zusammenfassen soll, kann keine korrekte Antwort geben, wenn die Bestelltabelle nie in einen Space repliziert wurde, den der Knowledge Graph indizieren kann. Ohne einen Replication Flow, der diesen Space speist, lehnt der Agent die Frage entweder ab — sicher, aber nutzlos — oder, schlimmer, antwortet aus einem veralteten Cache oder einem lose verwandten Objekt und produziert einen selbstbewusst klingenden Satz, der still und leise falsch ist. Die Abhilfe ist architektonisch, nicht auf Prompt-Ebene: Definieren Sie einen Replication Flow von den Quell-Einkaufstabellen in einen Datasphere Space, verankern Sie eine Data Access Control an der Space-Grenze und registrieren Sie die replizierte View im Knowledge Graph. Joule verankert dann jede Antwort auf Zeilen, die der anfragende Nutzer tatsächlich einsehen darf — das löst das Halluzinationsproblem und das Problem der zeilenbasierten Sicherheit in einem einzigen Designschritt.

Warum es zählt

Ohne einen Replication Flow lehnt ein Joule-Agent, der nach offenen Bestellungen gefragt wird, entweder die Antwort ab oder greift auf veraltete, möglicherweise falsche Daten zurück
Der Delta-/CDC-Modus zielt auf eine Aktualität von 5-30 Minuten für das Grounding — echtes Streaming unter einer Sekunde gibt es nicht ohne SAP Event Mesh oder eine Kafka-Bridge
Wird die DAC bereits auf Space-Ebene angewendet, bevor die Registrierung im Knowledge Graph erfolgt, respektiert das Grounding die zeilenbasierte Sicherheit automatisch, nicht als nachträglichen Gedanken

Kernpunkte

Replication Flows sind der primäre Aktualitätsmechanismus für das Joule-Knowledge-Graph-Grounding — ein fehlgeschlagener Flow bedeutet veraltete KI-Antworten.
Der Delta-Modus (CDC) ist für KI-Grounding zwingend erforderlich; Full Load ist nur für Referenztabellen < 10 Mio. Zeilen ohne CDC-Unterstützung geeignet.
Ziel-Delta-Latenz für KI-Grounding-Anwendungsfälle: 5–30 Minuten. Streaming unter einer Sekunde erfordert Event Mesh oder Kafka, nicht Replication Flows.
Stack: Replication Flow → replizierte Tabelle → SQL-View mit semantischen Typen → Analytic Model → Knowledge-Graph-Knoten.
Filter werden an der Quelle ausgewertet (Push-down); filtern Sie immer nach Buchungskreis oder Werk, um das Replizieren irrelevanter Zeilen zu vermeiden.
Begrenzen Sie Flows aus Gründen der Handhabbarkeit auf 20 Objektpaare pro Flow; nutzen Sie eine Parallelität von 8 Threads (per Support-Ticket erhöhbar).
Verdrahten Sie die Alerts des Data Integration Monitor mit Incident-Kanälen — stille Flow-Ausfälle sind der häufigste operative Fehlermodus bei produktivem Joule.
Verweisen Sie den Knowledge Graph niemals direkt auf eine rohe replizierte Tabelle; kapseln Sie sie immer zuerst in einer View mit Annotationen des semantischen Typs.
Datasphere Replication Flows für KI-Grounding sind erst beherrscht, wenn sie eine konkret benannte Käuferentscheidung verändern.
Beginnen Sie mit dem semantischen Vertrag und dem Kontrollmodell, bevor Sie das Tool demonstrieren.

Begriffe auf dieser Seite

Replication Flow: Verwaltete Datasphere-Pipeline, die Quelltabellen nach einem Zeitplan oder per CDC in einen Space kopiert; der primäre Aktualitätsmechanismus für KI-Grounding.
CDC (Change Data Capture): Technik, die seit dem letzten Lauf nur geänderte Zeilen aus der Quelle liest — ermöglicht den Delta-Modus und eine nahezu echtzeitnahe Replikationslatenz.
SLT (SAP Landscape Transformation): SAP-native CDC-Trigger-Schicht für ECC/S/4HANA; die häufigste Quelle für Delta-Ereignisse bei Replication Flows.
ODP (Operational Data Provisioning): S/4HANA-natives Extraktions-Framework, das Replication Flows als Änderungserfassungskanal für BW-nahe Objekte nutzen.
Knowledge-Graph-Knoten: Ein registriertes semantisches Objekt im Datasphere Knowledge Graph, das Joule-Agenten durchlaufen können, um Antworten in natürlicher Sprache zu verankern.
Data Integration Monitor: Datasphere-UI-Oberfläche, die Flow-Laufstatus, Zeilenanzahlen, Latenz und Fehlerdetails anzeigt — der operative Herzschlag für KI-Grounding-Pipelines.
Entscheidungsverantwortlicher: Die verantwortliche Person, die den Trade-off akzeptiert und die nächste Maßnahme finanziert.
Semantischer Vertrag: Die gemeinsame Definition von Geschäftsbegriffen, Kennzahlen, Entitäten und Zugriffsregeln, die von Tools und Teams verwendet wird.

Quellen

Vollständige Karte für Mitglieder. Was die vollständige Karte ergänzt: den vollständigen Entscheidungsrahmen · den Vergleich SAP · Snowflake · Databricks · Fabric · die häufigen Fallstricke und ihre Behebung · die Kurzreferenz · die Architekturschemata · die Codeblöcke · die zitierfähigen Kennzahlen.

In der App öffnen →