SAP SLT: Definition, Funktionsweise und Abgrenzung

SAP Landscape Transformation Replication Server (SLT) ist ein SAP-Werkzeug, das Daten aus SAP-ERP-Systemen (SAP ECC, SAP S/4HANA) nahezu in Echtzeit in Analyseplattformen wie SAP BW/4HANA, SAP HANA, SAP Datasphere, Databricks oder Kafka kopiert. Dafür setzt SLT im Quellsystem sogenannte Datenbank-Trigger (kleine Regeln, die bei jeder Datenänderung auslösen) und überträgt zuerst den vollen Bestand (Initial Load) und danach laufend die neuen Änderungen (Delta Load) ins Ziel.

Was ist SAP SLT?

SLT ist ein SAP-eigenes Replikations-Werkzeug, geschrieben in der SAP-Programmiersprache ABAP. Ursprünglich diente es dazu, SAP-Systemlandschaften umzubauen, etwa einen Mandanten (also einen abgegrenzten Datenbereich in einem SAP-System) zu kopieren oder zwei Buchungskreise zusammenzuführen. Heute liegt der Schwerpunkt darauf, Daten aus operativen SAP-Systemen in analytische Zielsysteme zu spiegeln, vor allem in SAP BW/4HANA (SAPs Data Warehouse) und HANA-basierte Datenplattformen.

Technisch läuft SLT entweder als eigenständiges ABAP-System zwischen Quelle und Ziel oder als Add-on direkt im Quellsystem (Embedded SLT). Die Konfiguration erfolgt in den Transaktionen LTRC (Konfiguration und Monitoring) und LTRS (erweiterte Replikations-Einstellungen). Für jede Tabelle im Scope legt SLT im Quellsystem drei Datenbank-Trigger an (Insert, Update, Delete), die bei jeder Änderung einen Eintrag in eine Logging-Tabelle schreiben. Ein Reader-Job im SLT-System holt diese Einträge, transformiert sie bei Bedarf über Include-Regeln oder Feld-Mappings und schreibt sie ins Ziel.

Der Betrieb kennt zwei Lademodi. Der Initial Load lädt den vollen Bestand einer Tabelle in einem Batch, parallelisiert über mehrere Reader-Jobs. Der Delta Load hält das Ziel danach kontinuierlich synchron: neue Änderungen fließen laufend über die Trigger und die Logging-Tabelle nach. Beide Modi lassen sich kombinieren, sodass das Zielsystem nach dem Erstlauf konsistent bleibt. Filter, Reader-Anzahl und Bulk-Größen sind die zentralen Stellschrauben, um den Trigger-Overhead im OLTP-Quellsystem zu begrenzen.

Als Ziele unterstützt SLT SAP BW/4HANA, SAP HANA on-premise und Cloud, die SAP BW Bridge, SAP Datasphere sowie über die SAP-Databricks-Integration weiter Delta-Tabellen im Unity Catalog. Für Streaming-Szenarien existiert eine Kafka-Integration. Innerhalb SAP Datasphere sitzt SLT häufig als unterliegende Engine unter dem [Replication Flow](/insights/glossar/replication-flow/); die Datasphere-Oberfläche kapselt die SLT-Mechanik, sodass der Nutzer das SLT-Objekt selbst nicht mehr sieht.

Abgrenzung: Replication Flow, CDC, ODP-Extraktoren, Remote Tables

SLT wird häufig mit benachbarten SAP-Integrationsbegriffen verwechselt. Die folgende Tabelle klärt die wichtigsten Unterschiede.

Begriff	Verhältnis zu SLT
Replication Flow	Datasphere-natives Replikations-Objekt. Nutzt für ABAP-Quellen intern SLT-Muster über den Replication Management Service, abstrahiert die SLT-Konfiguration aber weg. SAP positioniert Replication Flows als First-Choice für Extract-and-Load in Datasphere.
Change Data Capture (CDC)	Verfahrens-Ebene: Muster zur Erfassung von Row-Level-Änderungen, unabhängig vom konkreten Werkzeug. SLT ist eine konkrete SAP-Implementierung dieses Musters mit Trigger-Ansatz; andere CDC-Implementierungen setzen auf Datenbank-Logs oder Change-Feeds.
ODP-Extraktoren	Ältere BW-Extraktoren auf Basis der Operational Data Provisioning API. Seit SAP Note 3255746 sind diese APIs für Dritt-Tools gesperrt. SLT ist der Weg an dieser Sperre vorbei, weil es unabhängig von der ODP-API auf der Datenbank-Ebene arbeitet.
Remote Tables	Föderierter Query-Zeit-Zugriff auf eine Quelle über Smart Data Access oder Smart Data Integration. Keine Kopie, Datenhaltung bleibt in der Quelle. SLT materialisiert Daten physisch im Ziel.
Datasphere Transformation Flow	SQL-Transformation zwischen bereits vorhandenen Datasphere-Objekten. Kein Extraktionsweg aus SAP-Quellsystemen, sondern der T-Schritt eines ELT-Musters.

Die zentrale Betriebsfrage bei SLT ist der Trigger-Overhead im Quellsystem. Sehr große Tabellen mit hoher Änderungsrate belasten das OLTP-System messbar; deshalb gehören Filter-Regeln in LTRS, eine sinnvolle Anzahl paralleler Reader-Jobs und passende Bulk-Größen zum Standard-Setup.

Beispiel: Buchhaltungs-Bewegungsdaten aus ECC in BW/4HANA

Ein Konzern betreibt SAP ECC 6.0 als operatives ERP und ein SAP BW/4HANA-System als analytische Plattform. Die Bewegungsdaten der Finanzbuchhaltung, technisch die Tabellen BKPF (Belegkopf) und BSEG (Belegposition), sollen mit möglichst geringer Latenz für ein Finanz-Reporting zur Verfügung stehen.

Ein SLT-System wird als eigenständige Instanz zwischen ECC und BW/4HANA aufgesetzt. In LTRC wird eine Konfiguration angelegt mit ECC als Quelle und BW/4HANA als Ziel; BKPF und BSEG werden dem Scope hinzugefügt. In LTRS werden Filter auf relevante Buchungskreise und ein Include-Regelwerk für die benötigten Felder gesetzt, um die Datenmenge im Delta-Modus zu begrenzen.

Der Initial Load läuft nach dem Deployment und lädt den historischen Bestand parallelisiert über vier Reader-Jobs. Danach schaltet die Konfiguration in den Delta-Modus: Insert-, Update- und Delete-Trigger auf BKPF und BSEG schreiben laufend Einträge in die zugehörigen Logging-Tabellen, ein Reader-Job im SLT-System holt sie im Sekundentakt ab und schreibt sie nach BW/4HANA. Das Monitoring in LTRC zeigt Latenz und Backlog pro Tabelle; die Reader-Anzahl wird nachjustiert, wenn der Delta-Backlog wächst.