Best Practices: Change Data Capture (CDC) in CDS Views richtig umsetzen

Vor einigen Wochen haben wir über das S/4HANA Virtual Data Model (VDM) geschrieben und erläutert, wie gut es mit der SAP Datasphere zusammenpasst. Heute möchten wir auf einen besonders spannenden Aspekt eingehen, den wir dort nur kurz angerissen haben: die Vereinfachung der Datenintegration mit Change Data Capture (CDC).

Was ist Change Data Capture in CDS Views und warum ist es wichtig?

Eine extraktionsfähige S/4HANA CDS View ermöglicht es, die entsprechenden Daten beispielsweise durch die SAP Datasphere zu exportieren, um Ihre Reporting-Anforderungen zu erfüllen. Bei großen und zahlreichen Datenmengen ist es jedoch ineffizient und zeitaufwendig, den kompletten Datenbestand immer wieder neu zu laden (Full Load).

Für S/4HANA hat SAP ein ausgefeiltes Verfahren bereitgestellt, das eine performante Datenreplikation „out of the box“ ermöglicht – ohne großen manuellen Entwicklungsaufwand. Dieses Verfahren nennt sich Change Data Capture. Es erkennt und protokolliert Änderungen im Quellsystem (S/4HANA), die dann in regelmäßigen Abständen von konsumierenden Systemen abgeholt werden können.

Wird die SAP Datasphere mit Replication Flows als konsumierendes System eingesetzt, werden ausschließlich die geänderten Daten übertragen (Delta Load). Dadurch lassen sich extrem kurze Ladezeiten realisieren. Gleichzeitig wird es möglich, Daten häufiger zu laden und damit ein Near-Real-Time-Reporting zu etablieren.

Ein Beispiel für eine von SAP ausgelieferte CDS View mit bereits integrierter CDC-Funktionalität ist C_SalesDocumentItemDEX_1, die Verkaufsbelege wie Aufträge zur Verfügung stellt. Diese View kann ohne jegliche Anpassungen oder Entwicklungsaufwände auf der S/4HANA-Seite von der Datasphere extrahiert werden.

Nicht alle ausgelieferten CDS Views von SAP sind jedoch gleich aufgebaut. So fehlt beispielsweise in der Adress-View I_Address, die zusätzliche Adressinformationen enthält, die notwendige CDC-Definition. Standardmäßig könnten diese Informationen also nur über einen geplanten Full Load extrahiert werden. Um dies zu vermeiden, zeigen wir, wie die CDC-Definition mit wenigen Entwicklungsschritten in S/4HANA manuell ergänzt werden kann.

Alles, was wir im Folgenden zeigen, ist Teil des von SAP vorgesehenen Extension Frameworks für CDS Views. Es handelt sich also um den offiziell unterstützten und empfohlenen Ansatz zur Erweiterung dieser Funktionalität.

Szenario

Zunächst vergleichen wir die Definitionen beider CDS Views. In den folgenden Screenshots haben wir die CDC-Definition hervorgehoben, die in der SalesDocument-View vorhanden ist, in der Address-View jedoch fehlt. Unser Ziel ist es, eine ähnliche CDC-Definition für I_Address aufzubauen.

Da SAP Änderungen an ausgelieferten (SAP-managed) CDS Views nicht zulässt, erstellen wir eine neue (Customer-managed) CDS View, die die bestehende I_Address konsumiert. Diese neue CDS View erweitern wir anschließend um die spezifischen Annotations für die CDC-Definition.

Grundpfeiler einer Custom CDS View

Bei der Erstellung einer neuen View wie z. B. Z_I_Address gibt es zwei zentrale Bereiche:

• Annotations

  In diesem Bereich definieren Sie alle notwendigen „Attribute“, Labels oder Semantiken Ihrer View. Hier befindet sich auch die CDC-Definition (im Screenshot blau hervorgehoben).
  
  

• View Definition

  Hier wählen Sie die Felder aus, setzen Filter oder transformieren Daten. In unserem Szenario möchten wir alle Felder SELECTen, da das Ziel ausschließlich darin besteht, CDC anzuwenden – nicht, bestehende Felder auszuschließen.
  
  Hinweis: Es ist entscheidend, zuerst alle Schlüssel-Felder der zugrunde liegenden Tabelle zu SELECTen, da ansonsten die CDC-Definition fehlschlägt.

Aufbau der CDC-Definition

Der Kern der CDC-Definition liegt in der Abbildung der Tabellen und den notwendigen Filtern. Um herauszufinden, welche Tabellen für CDC relevant sind (und hier gemappt werden müssen), navigieren Sie einfach durch die Quellstruktur der jeweiligen CDS View bis zur Basistabelle. Je nach Komplexität kann dies mehr oder weniger aufwendig sein, die meisten Fälle sind jedoch 1:1-Szenarien.

In unserem Beispiel ist die zentrale Tabelle “ADRC” – deshalb haben wir ihre “role:” als “#MAIN” definiert. Die Annotationen t”ableElement” und “viewElement” enthalten dabei respektive die Namen der Schlüsselfelder der Tabelle sowie deren Alias in der aktuellen View-Definition.

Handelt es sich um komplexere CDS Views, kann die CDC-Definition dies auch berücksichtigen. Im Screenshot zeigen wir beispielsweise den Einsatz einer “filter”-Annotation und der “role:” “#LEFT_OUT_TO_ONE_JOIN”. Grundsätzlich sind diese Eigenschaften optional, bestimmen jedoch maßgeblich das Verhalten des CDC-Mechanismus:

Ohne Filter reagiert CDC auf jede Änderung in der Tabelle.

Mit Filter werden nur Änderungen berücksichtigt, die dem Filterkriterium entsprechen.

Wenn Sie keine zweite Tabelle (z. B. ADCP) definieren, werden Änderungen an dieser Tabelle keine CDC-Events auslösen – selbst wenn sie diese in der View in Joins verwenden.
Der CDC-Mechanismus basiert in diesem Fall also ausschließlich auf Änderungen in ADRC. Jede dieser Varianten ist ein legitimer Anwendungsfall. Dementsprechend hängt die korrekte Lösung letztendlich von Ihren fachlichen Anforderungen ab.

Hinweis: Damit Ihre neue CDS View in der Datasphere konsumiert werden kann, müssen Sie die “dataExtraction”-Annotation auf “enabled:true” setzen.

Sehen Sie sich die Aufzeichnung unseres Webinars an: 
"SAP Datasphere and the Databricks Lakehouse Approach"

CDC überall einsetzen?

Beachten Sie, dass jede CDC-fähige CDS View, die Sie per Replication Flow replizieren, zusätzliche Ressourcen sowohl auf der Quellseite (S/4HANA) als auch auf der Zielseite (Datasphere) benötigt.

Quelle (S/4HANA): Es werden Datenbank-Trigger auf den entsprechenden Tabellen gesetzt, wodurch Schreiboperationen länger dauern können.

Ziel (Datasphere): Der Replication Flow prüft regelmäßig auf neue Änderungen, was Prozesse auf beiden Seiten beansprucht.

Bei vielen Objekten und hoher Ladefrequenz kann die Belastung schnell ansteigen.

Während CDC äußerst hilfreich ist, gibt es Szenarien, in denen der Mehrwert gering ist. Ein Beispiel sind Text-Views: Zwar lässt sich CDC hier einsetzen, aber die Datenmenge ist in der Regel klein und Änderungen selten – ein Full Load reicht vollkommen aus.

Ein weiterer Aspekt ist der Stabilitätsvertrag der verwendeten CDS Views. Es empfiehlt sich, mindestens C1-freigegebene Views zu verwenden (unabhängig von CDC oder Full Load). Nur dann ist sichergestellt, dass die Struktur der View auch in zukünftigen S/4HANA-Releases stabil bleibt. Bei nicht freigegebenen Views besteht mindestens die Gefahr, dass Ihre Replikation bei einem Release-Upgrade bricht. Häufig bleibt aber auch keine andere Option als eine nicht freigegebene CDS View zu verwenden - die Risiken sollte man dennoch kennen.

Delta-Mechanismus (CDC) auf einer CDS-View: Unser Fazit

Der Delta-Mechanismus über Change Data Capture (CDC) ist ein leistungsstarkes Werkzeug für die effiziente Datenreplikation von S/4HANA in die SAP Datasphere bzw. Business Data Cloud insgesamt.

SAP liefert hierfür bereits zahlreiche CDS Views mit CDC-Funktionalität aus. Für Views, bei denen dies fehlt, haben wir gezeigt, wie sich die Funktionalität mit den empfohlenen Erweiterungsmechanismen manuell nachrüsten lässt.

Allerdings erzeugt CDC zusätzliche Last auf Quell- und Zielsystem. Daher sollte in jedem Szenario sorgfältig geprüft werden, ob ein Delta Load gegenüber einem Full Load einen spürbaren Mehrwert bietet.

Haben Sie Fragen zu SAP Datasphere? Oder benötigen Sie Unterstützung bei einer konkreten Fragestellung? 

Wir helfen Ihnen gerne dabei. Nehmen Sie einfach Kontakt zu uns auf!