Ein Leitfaden zur SAP-Datenintegration

Heute wird SDI bei allen Hana-Lösungen eingesetzt und ist für Kunden selbstverständlich. Mit der nächsten Evolutionsstufe wollte ich Daten- und Prozessintegration in einer noch nicht da gewesenen Art zusammenbringen. Die Technik war endlich weit genug, um die beiden Produktkategorien zusammenführen zu können. Das ist aber mit der Organisationsstruktur von SAP kollidiert und wurde nicht aufgegriffen.

Heute ist das Integrationsthema bis zum Vorstand hochgekocht und das Ergebnis nicht gerade überzeugend. Schlimmer noch, ich sehe viele SAP-Bestandskunden, die dieses Problem der Integration für sich selbst auf clevere Art und Weise lösen, also bereits weiter als SAP selbst sind. Den letzten Schliff bekommen diese Kunden von der Open-Source-Lösung, die meine Firma zur Verfügung stellt.

In weiterer Folge möchte ich Sie mit auf die gedankliche Reise nehmen, welche Erkenntnisse diese Pioniere hatten und wo wir sie noch verbessert haben.

System vs. Datenintegration

Betrachtet man das Produktportfolio von SAP, gibt es eine scharfe Trennung zwischen Prozessintegration und Data-Integration. Einmal möchte man das ERP-System mit einer anderen Applikation verbinden, im anderen Fall Tabelleninhalte von A nach B übertragen. Fragt man einen Applikationsentwickler, so spricht dieser von „Entities“ wie dem Business-Partner. In der Datenintegration ist man eine Ebene tiefer unterwegs, den Tabellen. Diese Trennung gibt es in der Big-Data-Welt nicht. Dort können alle Produkte mit tief verschachtelten Objekten umgehen und eine Datenbanktabelle ist nur ein besonders einfaches Objekt. Daraus ergibt sich die erste Schlussfolgerung: Vergessen wir lieber Datenbank-Tools und sehen wir uns besser bei den Big-Data-Produkten um.

Batch vs. Realtime

Als Nächstes gibt es Tools, die Massendaten im Batch-Verfahren übertragen, und andere sind für Realtime gebaut. Diese Trennung hat technische Gründe, rein logisch betrachtet ist aber Realtime eine Obermenge der beiden. Im Batch kann man niemals die Daten in beliebig kurzen Abständen übertragen. Mit einem Realtime- System ist jedoch eine Batch-Verarbeitung möglich. Das sieht dann so aus, als würde in einer Quelle stundenlang nichts passieren und als würden dann plötzlich – für ein kurzes Intervall – sehr viele Daten erzeugt werden. Dazu muss das Realtime-Tool aber mit Massendaten umgehen können – womit wir erneut im Big-Data-Portfolio gelandet wären.

Betrachtet man die Lösung aus der Fragestellung heraus, welche Systeme mit welchen gekoppelt sind, so war das in der Vergangenheit eher eine Eins-zu-eins-Beziehung. Die SAP-ERP-Daten gehen nach SAP BW. Die Daten der Zeiterfassung landen als Buchungen im SAP-HCM-Modul. Und genau so sind die SAP-Werkzeuge gebaut. War diese Annahme früher schon nicht unbedingt richtig, sind heute an jedes Quellsystem sehr viele konsumierende Systeme angeschlossen – Tendenz steigend. Beispielsweise gehen die ERP-Daten ins SAP BW, in ein Data Lake, an Ariba, Salesforce und unzählige weitere Intelligent-Enterprise-Apps.

Damit kommt man auch mit einer Datenorchestrierung, wie bei allen SAP-Werkzeugen üblich, nicht weit. Es macht mehr Sinn, wenn jeder Konsument sich an den Daten beliebig bedienen kann, also eine Datenchoreografie. In solch einem Setup gibt nicht mehr der Dirigent vor, wer wann was zu tun hat, sondern es gibt für jedes Objekt einen Kanal, in dem Systeme Änderungen publik machen und andere Systeme die Änderungen nach Gutdünken konsumieren können.

Beispielsweise würde das ERP bei jeder Änderung eines Business-Partner-Eintrags die neueste Version veröffentlichen und das BW konsumiert diese einmal am Tag in einem Rutsch. Eine andere Applikation wiederum hört ständig auf Änderungen in diesem Topic und kann diese mit einer Latenz im Millisekundenbereich in die eigene Applikation integrieren.

Apache Kafka

Nimmt mal all diese Gedanken zusammen, landet man unweigerlich bei Apache Kafka. Nicht nur deswegen wird Kafka inzwischen von allen großen Firmen eingesetzt und setzt sich immer weiter als Standard durch. Wenn das für die Big-Data-Welt funktioniert, können wir das sicherlich auch für die operativen Daten gut gebrauchen, oder?

Apache Kafka besteht im Kern aus „Topics“, welche den Datenkanal darstellen. Jedes dieser Topics kann in sich partitioniert werden, um eine Parallelisierung der Massendaten zu ermöglichen. Und jede Änderungsnachricht hat ein Schema mit den zugehörigen Daten. Es gibt also in unserem Beispiel ein Schema „Business-Partner“ mit den Stammdaten wie Vorname und Nachname und darin sind alle Adressen des Kunden verschachtelt. Betrachtet man das aus der Datenintegrationssicht, sind das die SAP-ERP-Tabellen KNA1 mit den zugehörigen ADRC-Adressdaten. In der Prozessintegration verwendet man die verschachtelte Struktur, etwa über SAP IDocs oder Bapis.

Das bedeutet zwar einen Mehraufwand für den einen (!) Producer, dafür haben es aber die vielen Consumer viel leichter. In einer Welt, in der es für jeden Bereich viele Consumer gibt, ist das insgesamt der kostengünstigere Weg.

Jetzt ist es aber nicht damit getan, einfach z. B. jede IDoc an Kafka zu übergeben – und hinter mir die Sintflut. Wenn schon, sollte das volle Potenzial mobilisiert werden. Eine dieser Chancen dreht sich um Änderungen der Struktur – der Tod jeder aktuellen Integrationslösung. Weder ist es gangbar, alle Producer und Consumer synchron anzupassen, noch ist es sinnvoll, mehrere Versionen der Struktur gleichzeitig vorzuhalten. Darum folge ich dem Konzept der Schema-Evolution, also die Fähigkeit, ein Schema zu erweitern, ohne dass etwas kaputtgeht.

Der einfachste Fall ist leicht erklärt: Angenommen, es gibt zwei Producer und zehn Consumer für Business-Partner-Stammdaten. Der eine Producer, das SAP-System, hat heute ein Z-Feld zusätzlich bekommen. Der SAP-Producer fügt dieses in das offizielle Schema ein und gibt ihm einen Default-Wert <null>. Von nun an kann das SAP-System auch dieses Feld mitversenden.

Der andere Producer verwendet die nächsten 20 Minuten weiter die vorhergehende Schemaversion, bis er sich neu synchronisiert. Das Umschalten auf das neue Schema bringt ihn aber nicht aus dem Tritt, denn dieses Feld gibt es für ihn nicht, also füllt er es nicht, also bleibt es auf <null>. Es muss nichts an diesem Producer geändert werden, er läuft einfach weiter wie gehabt.

Bekommen die Consumer das erste Mal die neue Schemavariante, wird ab jetzt diese zum Lesen aller Nachrichten verwendet. Somit ist das zusätzliche Feld immer vorhanden. Wird eine alte Nachricht über das neue Schema gelesen, ist das Z-Feld nicht in den Daten und daher . Auch in diesem Fall gibt es also keine Komplikationen.

Die Consumer wiederum können selbst entscheiden, wie sie mit dem neuen Feld umgehen. Ein Applikations-Consumer holt sich aus dem Schema sowieso nur die Felder, die er wirklich benötigt, und das Z-Feld hat im Moment gar keine Entsprechung in der Zielapplikation. Ein Data Lake Consumer erweitert wahrscheinlich die Zielstruktur um dieses zusätzliche Feld automatisch, um nie Information zu verlieren.

Die Schema-Evolution erlaubt somit das sukzessive Anpassen des offiziellen Schemas über die Zeit. Dann gibt es noch Fälle, in denen der Producer technische Informationen mitschicken möchte. Dafür hat jedes Schema einen Extension-Bereich reserviert.

Überhaupt beinhaltet das Schema noch einige weitere Informationen, die später interessant sein können: Was ist das Quellsystem der Nachricht? Welchen Transformationen wurden die Daten unterzogen? Wie ist die Datenqualität des Satzes einzuschätzen?

Message Queue vs. Kafka Transaction Log

Der Fall, bei dem ein Consumer das zusätzliche Feld gesehen hat, aber nicht verwenden konnte, zeigt ein anderes, ungelöstes Problem auf: Wie bekommt man die bereits geladenen Daten nochmals? Vor der Zeit von Kafka hätte man Message Queues verwendet und dort ist die einzige Möglichkeit, alle Daten nochmals zu bekommen, sie nochmals von der Quelle produzieren zu lassen. Damit fließen sie jedoch durch alle Consumer, selbst solche, die daran gar kein Interesse haben. Wird der nächste Consumer angepasst, müssen wieder alle Daten produziert werden. Was für ein Horror. Darum haben sich Message Queues auch nie so durchgesetzt, wie man ursprünglich erwartet hat.

Die Prämisse unserer Lösung war jedoch, dass der Consumer entscheiden kann, was er wann liest. In diesem Fall sollte er auch die Möglichkeit haben, schon einmal gelesene Daten nochmals lesen zu können. Praktisch würde man diesen Consumer wie gewünscht verändern und bei dessen Neustart sagen, er möge die ­Daten der vergangenen sieben Tage bitte nochmals lesen. Anders als Message ­Queues schmeißt Kafka die Daten nicht sofort weg, sondern ist als Big-Data-Tool dafür gebaut, die Änderungsnachrichten eine Weile oder sogar für immer vorzuhalten.

Diese Option ist für zahlreiche weitere Situationen ein immenser Gewinn. Zum Beispiel kann der Entwickler die gleichen Tests beliebig oft wiederholen und bekommt die gleichen Änderungsdaten. Oder ein neuer Consumer fängt nicht ohne Daten an, sondern bekommt beim ersten Aufruf gleich eine große Menge an Daten.

Sollten Sie ebenfalls eine günstige, offene und zukunftsweisende Lösung für die Integration Ihrer verschiedenen Applikationen suchen, können Sie sich auf meiner Website inspirieren lassen.