ODP (Operational Data Provisioning): SAP-Definition

Operational Data Provisioning (ODP) ist ein SAP-Framework, das Daten aus SAP-Systemen (ERP-Systeme wie ECC oder S/4HANA und das Data-Warehouse BW) an SAP-Auswertungssysteme wie BW/4HANA, SAP Datasphere und die SAP Business Data Cloud weitergibt. Statt jedes Mal die komplette Datenbank neu zu kopieren, überträgt ODP nur die Änderungen seit der letzten Übertragung (Delta) und merkt sich pro Empfänger, wo zuletzt aufgehört wurde.

Was ist Operational Data Provisioning?

ODP ist eine Vermittlungsschicht innerhalb von SAP-Systemen und kein eigenes Produkt, das man zusätzlich kauft. Das Framework existiert seit rund 2011 im SAP-ERP (Enterprise Resource Planning) und im SAP-Data-Warehouse BW (Business Warehouse) und ersetzt ältere, produktspezifische Extraktionsverfahren durch eine einheitliche Logik. Ziel ist es, Änderungen aus einem SAP-Quellsystem so bereitzustellen, dass ein Zielsystem sie schrittweise (inkrementell) und wiederaufnehmbar abholen kann, also nach einem Abbruch dort weitermacht, wo es aufgehört hat.

Die Architektur besteht aus zwei Rollen. Ein Provider stellt die Daten bereit; das kann ein klassischer SAPI-Extraktor aus ECC (DataSources wie 0FI_ACDOCA_10 oder 2LIS_*), eine HANA-Calculation-View, eine ABAP-CDS-View mit der Annotation @Analytics.dataExtraction.enabled: true, ein SLT-Trigger oder ein BW-Objekt sein. Ein Subscriber abonniert den Provider und holt die Daten ab; typische Subscriber sind BW/4HANA-DataSources, SAP-Datasphere-Replication-Flows und die SAP Business Data Cloud.

Kern der Mechanik ist die Operational Delta Queue (ODQ), eine Tabelle im Quellsystem (ODQDATA), in der der Provider Änderungen persistiert. Beim ersten Extraction-Request eines Subscribers liefert der Provider einen Initial-Load, danach berechnet er pro Änderung einen Delta-Eintrag in der Queue. Der Subscriber quittiert die abgeholten Deltas, das Framework verwaltet Position und Wiederanlauf pro Subscription unabhängig. Ein Reload für einen Subscriber stört andere Subscriptions auf denselben Provider nicht.

ODP-Provider werden über Kontexte klassifiziert: SAPI (klassische BW-Extraktoren), HANA (Calculation Views), ABAP_CDS (annotierte CDS-Views), SLT (Trigger-basierte Replikation) und BW (BW-Objekte als Quelle). Die Sichtbarkeit im Quellsystem läuft über die Transaktionen RSA1 (Extraktor-Verwaltung) und ODQMON (Monitoring der Delta-Queues).

Seit SAP Note 3255746 ist die Nutzung der ODP-APIs (RFC- und OData-basiert) durch Drittanbieter-ETL-Werkzeuge wie Fivetran, Qlik oder Theobald offiziell untersagt bzw. lizenzpflichtig. Zwischen SAP-eigenen Systemen bleibt ODP der Standard-Extraktionspfad; für Nicht-SAP-Ziele verschiebt sich der Weg auf alternative Extraktionsmuster wie CDS-View-Konsum ohne ODP oder direkte Datenbank-Replikation.

Abgrenzung: ODQ, SLT, CDS-Views und generisches CDC

ODP wird häufig mit benachbarten Begriffen verwechselt, die entweder in ODP integriert sind oder eine andere Ebene der Extraktionslandschaft betreffen.

Begriff	Verhältnis zu ODP
Operational Delta Queue (ODQ)	Delta-Queue-Tabelle (ODQDATA) und Persistenz-Schicht innerhalb von ODP. ODQ ist die Speicherform der Deltas, ODP das Framework darum herum.
SLT (SAP Landscape Transformation)	Trigger-basierter Replikations-Server. Kann als ODP-Provider im Kontext SLT auftreten oder eigenständig replizieren. ODP ist die Verwaltung, SLT die Erfassung auf Tabellen-Ebene.
[ABAP-CDS-Views](/insights/glossar/cds-views/)	Modellierungs-Layer in S/4HANA. Ein CDS-View wird durch @Analytics.dataExtraction.enabled: true zum ODP-Provider im Kontext ABAP_CDS. Der View ist die semantische Definition, ODP die Transportschicht.
RMS/APE (Replication Management Service, ABAP Pipeline Engine)	Modernes Replikations-Backbone in Datasphere Replication Flows aus ABAP-Quellen. Nutzt ODP-Provider intern, orchestriert aber Parallelisierung und Wiederanlauf auf einer neueren Ebene.
[Change Data Capture (CDC)](/insights/glossar/change-data-capture/), generisch	Muster für inkrementelle Datenreplikation aus Log oder Trigger. ODP ist die SAP-spezifische Umsetzung mit Provider-Subscriber-Semantik und Delta-Queue.

Beispiel: S/4HANA-Finance-Daten in SAP Datasphere

Ein Unternehmen betreibt S/4HANA und modernisiert das analytische Frontend nach SAP Datasphere und der Business Data Cloud. Für Finance-Bewegungsdaten registriert das Team den Standard-Extraktor 0FI_ACDOCA_10 (Universal Journal) im ODP-Kontext SAPI als Provider im S/4HANA-System. In Datasphere wird ein Replication Flow angelegt, der diesen Provider als Quelle abonniert; die Ziel-Tabelle liegt im Open-SQL-Schema.

Beim ersten Lauf erzeugt der Provider im Quellsystem einen Initial-Load und schreibt danach jede Änderung als Delta-Eintrag in die ODQDATA-Tabelle. Der Replication Flow zieht die Deltas alle 15 Minuten per Extraction-Request, quittiert sie und schreibt sie inkrementell in die Ziel-Tabelle. Aus derselben Datasphere-Umgebung wird ein zweiter Subscriber (BW/4HANA-DataSource) auf denselben Provider aufgesetzt. Das Framework verwaltet beide Subscriptions unabhängig, sodass ein Reload in BW/4HANA den Datasphere-Delta nicht beeinflusst. Die Sichtbarkeit der Delta-Queues und der aktiven Subscriptions läuft im S/4HANA-System über die Transaktion ODQMON.