Die Frage, die mir jede Woche von Kunden weltweit gestellt wird: Wie kann ich mein SAP-System mit Apache Kafka integrieren? Dieser Beitrag untersucht verschiedene Alternativen, darunter Konnektoren, Drittanbieter-Tools, kundenspezifischen Code und die Abwägung zwischen den verschiedenen Optionen.
Nach einer Einführung in SAP werden wir mehrere Integrationsmöglichkeiten zwischen Apache Kafka und SAP-Systemen diskutieren:
- Traditionelle Middleware (ETL/ESB)
- Webdienste (SOAP/REST)
- Fertige Drittanbieter-Lösungen
- Kafka-native Konnektivität mit Kafka Connect
- Kundenspezifischer Code unter Verwendung von SAP SDKs
Hinweis vorab:
Ich bin kein SAP-Experte. Es ist schwierig, mit dem riesigen und komplexen Ökosystem von SAP-Produkten, (Re-)Marken, Versionen, Diensten, SDKs und APIs auf dem Laufenden zu bleiben. Ich bitte um Entschuldigung, falls einige der unten stehenden Informationen nicht 100% korrekt oder veraltet sind. Überprüfen Sie immer auf der SAP-Website (falls die Links von Google noch funktionieren – ich hatte bei der Recherche für diesen Blogbeitrag einige Probleme mit Seiten, die „nicht mehr verfügbar“ waren). Wenn Sie ungenaue oder fehlende Informationen entdecken, lassen Sie es mich bitte wissen, und ich werde den Blogbeitrag aktualisieren.
Was ist SAP?
SAP ist ein deutsches multinationales Softwareunternehmen, das Unternehmenssoftware herstellt, um Geschäftsabläufe und Kundenbeziehungen zu verwalten. Im Jahr 2019 erzielte SAP einen Umsatz von 27,553 Milliarden Euro, einen Nettogewinn von 3,387 Milliarden Euro und beschäftigte rund 100.000 Mitarbeiter.
Es ist ziemlich interessant: Niemand fragt, wie man sich mit IBM oder Oracle integrieren kann. Stattdessen fragen die Leute spezifischer, wie man sich mit IBM MQ, IBM DB2, IBM Mainframe (immer noch sehr mehrdeutig) oder einem der Hunderte von IBM-Produkten integrieren kann.
Bei SAP fragen die Leute: Wie kann ich mich mit SAP integrieren? Klären wir zunächst, was SAP ist, bevor wir die Integrationsoptionen untersuchen.
Das Unternehmen ist primär für seine ERP-Software bekannt. Aber wenn Sie die offizielle Seite „Was ist SAP?“ besuchen, stellen Sie fest, dass SAP Lösungen in einem breiten Spektrum von Bereichen anbietet:
- ERP und Finanzen
- CRM und Customer Experience
- Netzwerk- und Ausgabenmanagement
- Digitale Lieferkette
- HR und Mitarbeiterengagement
- Experience Management
- Business Technology Platform
- Digitale Transformation
- Kleine und mittlere Unternehmen
- Branchenlösungen
SAPs Software-Portfolio
Der SAP-Stack umfasst hauseigene Produkte wie SAP ERP und Akquisitionen mit eigenem Code, darunter Ariba für Lieferantennetzwerke, hybris für E-Commerce-Lösungen, Concur für Reise- und Spesenmanagement und Qualtrics für Experience Management.
Selbst wenn Sie über SAP ERP sprechen, ist die Situation immer noch nicht so einfach. Die meisten Unternehmen betreiben immer noch SAP ERP Central Component (ECC, früher SAP R/3), SAPs ausgeklügeltes (und in die Jahre gekommenes) ERP-Produkt. ECC läuft auf einer relationalen Datenbank eines Drittanbieters von Oracle, IBM oder Microsoft, während HANA SAPs In-Memory-Datenbank ist. Das neue ERP-Produkt ist SAP S/4HANA (nein, das ist nicht nur die berühmte In-Memory-Datenbank). Oh, und es gibt SAP S/4HANA Cloud. Und bevor Sie sich wundern: Nein, das ist nicht derselbe Funktionsumfang wie die On-Premise-Version!
Je nach Produkt existieren verschiedene Schnittstellen. Eine Schnittstelle kann eine (schreckliche) proprietäre Technologie wie BAPI oder iDoc sein, (halbwegs brauchbare) standardbasierte Webdienst-APIs unter Verwendung von SOAP oder REST/HTTP, eine (nicht skalierbare) JDBC-Datenbankkonnektivität oder, wenn Sie Glück haben, sogar eine (skalierbare und Echtzeit-)Ereignis-/Nachrichten-API. Der Artikel „The ERP is Dead. Long live the Distributed Planning System“ aus dem SAP-Blog beschreibt die Situation sehr gut.
Und Entschuldigung, wir sind noch nicht fertig. Selbst wenn Sie über ERP-Systeme sprechen, kann dies je nachdem, mit wem Sie sprechen, einen ganzen Zoo von Produkten oder Komponenten bedeuten:
SAP ERP System: Ein Ökosystem aus Produkten wie MES, CRM, PLM, WMS, LMS
Bevor Sie also die Integration Ihres SAP-Produkts mit Kafka besprechen möchten, finden Sie bitte, bitte, bitte das Produkt, die Version und die Bereitstellungsinfrastruktur Ihrer SAP-Komponenten heraus.
Verschiedene Integrationsoptionen zwischen Kafka und SAP
Nach dieser Einführung verstehen Sie hoffentlich, dass es keine Patentlösung für die SAP-Integration gibt. Im Folgenden werden verschiedene Integrationsoptionen zwischen Kafka und SAP sowie deren Kompromisse untersucht. Der Schwerpunkt liegt auf SAP ERP (altes ECC und neues S/4HANA), aber die Übersicht ist allgemeiner gehalten und umfasst Integrationsmöglichkeiten mit anderen Komponenten und Produkten.
SAP Integration mit Apache Kafka: Übersicht über R3, ERP, S4 Hana, Ariba, Concur und verschiedene Schnittstellen
Beachten Sie außerdem, dass Sie sich in der Regel mit einer Funktion oder einem Dienst integrieren müssen oder möchten. Eine direkte Integration mit dem Datenobjekt ist in den meisten Fällen nicht sinnvoll, da Sie die Abbildung und Denormalisierung zwischen den Datenobjekten neu implementieren müssten. Dies gilt insbesondere für die Quellintegration, d.h. den Aufbau von Pipelines von SAP zu Kafka. Im Falle von SAP ERP integrieren Sie sich aus diesem Grund in der Regel mit RFC/BAPI/iDoc oder einer anderen Webdienstschnittstelle.
Traditionelle Middleware (ETL / ESB) für die SAP-Integration
Integrationswerkzeuge existieren nur zum Zweck der Integration verschiedener Quellen und Senken:
- Extract-Transform-Load (ETL) für die Batch-Integration, wie Informatica, Talend oder SAP NetWeaver Process Integration
- Enterprise Service Bus (ESB) für die Integration über Webdienste und Messaging, wie TIBCO BusinessWorks oder Software AG webMethods
- Integration Platform as a Service (iPaaS) für Cloud-native Integration, ähnlich wie ETL/ESB-Tools, aber als vollständig verwalteter Dienst bereitgestellt, wie Boomi, Mulesoft oder SAP Cloud Integration (und einige „Cloud-gewaschene“ Produkte von Legacy-Middleware-Anbietern).
Die meisten traditionellen Middleware-Produkte wurden entwickelt, um komplexe, proprietäre Systeme der letzten 20+ Jahre zu integrieren, wie IBM Mainframe, EDIFACT und, Sie ahnen es, ERP-Systeme wie SAP ECC. Inzwischen verfügen alle auch über einen Kafka-Konnektor. Es gibt viele gute Gründe, warum viele Unternehmen Kafka als moderne Integrationsplattform anstelle einer älteren traditionellen Middleware gewählt haben.
Die meisten traditionellen ETL- und ESB-Tools bieten SAP-Konnektivität. SAP Cloud Platform Integration (SAP CPI) ist SAPs eigene „moderne“ Middleware-Lösung. CPI enthält einen Kafka-Adapter, um Kafka-Nachrichten zu senden und zu empfangen.
Vorteile:
- Vorhanden: Typischerweise bereits im Einsatz, kein neues Projekt erforderlich.
- Reife: Über Jahre (aufgrund der Komplexität) entwickelt, seit langer Zeit produktiv.
- Tooling: Visuelle Programmierung für die Integration (aufgrund der Komplexität erforderlich), direkte Abbildung von iDoc / BAPI / Hana / SOAP-Schemata auf andere Datenstrukturen.
- Integration: Nicht nur Konnektoren zu den Altsystemen, sondern auch Kafka zum Erzeugen und Konsumieren von Nachrichten (aufgrund des Marktdrucks).
Nachteile:
- Legacy: Produkte sind so alt wie die Quell- und Zielsysteme.
- Skalierbarkeit: Monolithische, unflexible Architektur.
- Starke Kopplung: Die Integration muss auf der Middleware entwickelt und ausgeführt werden, keine echte Entkopplung und Domain-Driven Design (DDD) wie in Kafka.
- Lizenzierung: Hohe Kosten pro Server, oft ist bereits ein Ersatz geplant (z.B. können Sie über 100 IBM MQ- oder TIBCO EMS-Server durch einen einzigen Kafka-Cluster ersetzen).
- Punkt-zu-Punkt: Keine Streaming-Architektur, die meisten Integrationen basieren auf Webdiensten (auch wenn der Kern darunter auf einem Messaging-System basiert).
Kurz gesagt:
Traditionelle Integrationstools sind ausgereift und bieten ein hervorragendes Tooling, weisen jedoch eine begrenzte Skalierbarkeit/Flexibilität und hohe Lizenzkosten auf. Oft ein schneller Gewinn, da sie bereits laufen und Sie nur den Kafka-Konnektor hinzufügen müssen.
Kundenspezifischer Code für die Kafka-Integration mit SAP SDKs
Das Schreiben Ihres kundenspezifischen Integrationscodes zwischen SAP-Systemen und Kafka ist eine praktikable Option. Dieser Code nutzt typischerweise dieselben SDKs, die auch Drittanbieter-Tools im Hintergrund verwenden:
- Legacy: SAP NetWeaver RFC SDK – eine C/C++-Schnittstelle zur Verbindung mit SAP-Systemen von Release R/3 4.6C bis zu den heutigen SAP S/4HANA-Systemen.
- Legacy: SAP Java Connector (SAP JCo) – die bekannte JCO.jar-Bibliothek – ist ein Java SDK für die Integration in SAP ECC / ERP (dies ist lediglich ein Wrapper um das C/C++ SDK).
- Legacy: SAP ACO ist eine integrierte ABAP-Komponente, die zum Konsumieren von RFC-Diensten auf entfernten ABAP-Systemen entwickelt wurde.
- Legacy: SAP ABAP TCP Push Channel, wenn Sie gezwungen sind, kundenspezifischen ABAP-Code zu verwenden und TCP anstelle des Confluent REST Proxys für die HTTP-Kommunikation nutzen müssen oder möchten.
- Legacy: JMS Adapter zur Integration über das Standard-Messaging-Protokoll. Eine großartige Option (wenn Sie es für Ihren Anwendungsfall und Ihre Funktionen zum Laufen bringen). Zum Beispiel kann die JMS-Integration über SAP PI erfolgen.
- Modern: SAP Cloud SDK ermöglicht die Entwicklung von Anwendungen mit Java oder JavaScript, die mit SAP-Lösungen und -Diensten wie SAP S/4HANA Cloud, SAP SuccessFactors und anderen kommunizieren (der Begriff „Cloud“ bedeutet in diesem Fall tatsächlich „Cloud-native“, d.h. dieses SDK funktioniert auch mit SAPs On-Premise-Produkten).
- Modern: SAP Cloud Platform Enterprise Messaging: S/4HANA bietet eine asynchrone Messaging-Schnittstelle (die im Hintergrund auf Solace auf CloudFoundry läuft). Verschiedene Messaging-Standards werden unterstützt, darunter AMQP 1.0 und JMS (je nachdem, welches spezifische Produkt Sie betrachten). Einige Beispiele zeigen, wie man sich über den Java Client mit der JMS API verbinden kann.
- Modern: SAP ODP (Operational Data Provisioning): Technische Infrastruktur für operative Analysen und Datenextraktion + Replikation. Eine Art CDC (Change Data Capture) mit Out-of-the-Box-Unterstützung für verschiedene SAP-Produkte, darunter SAP BW, SAP BW/4HANA, SAP Data Services und SAP HANA Smart Data Integration. ODP ist nicht nur für SAP-Schnittstellen, sondern integriert sich auch mit Drittanbieter-Technologien (über einen kundenspezifischen Konnektor, nicht Out-of-the-Box) wie HDFS oder Kafka.
Vorteile:
- Flexibilität: Kundenspezifischer Code ermöglicht die präzise Umsetzung Ihrer Anforderungen.
Nachteile:
- Wartung: Keine Anbieterunterstützung – Entwicklung, Wartung, Betrieb, Support liegen in Ihrer eigenen Verantwortung.
- Punkt-zu-Punkt: Keine Streaming-Architektur; die meisten Integrationen basieren auf Webdiensten (auch wenn der Kern darunter auf einem Messaging-System basiert).
Kurz gesagt:
„Selbst entwickeln vs. Kaufen“ hat immer Kompromisse. Kundenspezifischer Code für die SAP-Integration ist mir im Feld nur begegnet, wenn keine Lösung eines Anbieters verfügbar und erschwinglich war. SAP Cloud Platform Enterprise Messaging ist ein mögliches Integrationsmuster für Kafka, fügt der Architektur jedoch eine weitere Messaging-Schicht hinzu.
SOAP / REST Webdienste für die SAP-Integration
Die letzten 15 Jahre haben uns Webdienste für den Aufbau einer Service-orientierten Architektur (SOA) zur Integration von Anwendungen beschert. Ein Webdienst verwendet typischerweise SOAP oder REST/HTTP als Technologie. Ich werde hier keinen weiteren FUD-Krieg beginnen. Beide haben ihre Anwendungsfälle und Kompromisse.
Vorteile:
- Standardbasiert: Verschiedene SDKs, Produkte und Dienste sprechen dieselbe Sprache (zumindest theoretisch; dies gilt für HTTP, weniger für SOAP); die meisten Middleware-Tools unterstützen das Erstellen von HTTP-Diensten.
- Einfachheit (HTTP): Gut verstanden, von den meisten Programmiersprachen und APIs unterstützt, für viele Anwendungsfälle etabliert – Middleware ist nur ein weiterer davon.
Nachteile:
- Punkt-zu-Punkt: Keine Streaming-Architektur; die meisten Integrationen basieren auf Webdiensten (auch wenn der Kern darunter auf einem Messaging-System basiert).
- Starke Kopplung: Die Integration muss auf der Middleware entwickelt und ausgeführt werden, keine echte Entkopplung und Domain-Driven Design (DDD) wie in Kafka.
- Komplexität (SOAP): SOAP/WSDL ist nur die Spitze des Eisbergs! Werfen Sie einen Blick auf die Liste der WS-*-Standards, um zu verstehen, warum dies oft als „WS-Stern-Hölle“ bezeichnet wird. Das AXIS-Framework (Apache eXtensible Interaction System) ist ein Beispiel für SAPs SOAP-Integration unter Verwendung eines offenen Frameworks. Während das Apache-Projekt zuletzt 2006 aktualisiert wurde, empfiehlt SAP die Verwendung dieser Schnittstelle immer noch im Jahr 2020.
- Fehlende Funktionen (REST/HTTP): Representational State Transfer (REST) ist ein Konzept, aber die meisten Leute meinen synchrone HTTP-Kommunikation. Die meisten Middleware-Tools (und die meisten anderen Anwendungen) nutzen nur einen kleinen Bruchteil des vollständigen Standards. HTTP ist ein ausgezeichneter Standard, aber alle Tools und Funktionen müssen darauf aufbauen.
- Nur indirekte Unterstützung: Mehrere SAP-Produkte bieten keine offenen Schnittstellen. Obwohl SOAP oder HTTP im Hintergrund verwendet werden, sind Sie gezwungen, lizenzierte Tools zu verwenden, um Webdienste zu erstellen. Zum Beispiel SAP Business Connector (eingeschränkte Lizenzversion des webMethods Integration Servers), SAP NetWeaver Process Integration (PI), SAP Process Orchestration (PO), Cloud Platform Integration (CPI) oder SAP Cloud Integration.
Kurz gesagt:
SOAP- und REST-Webdienste eignen sich gut für die Punkt-zu-Punkt-Kommunikation und bieten eine gute Tool-Unterstützung. Beide haben ihre Kompromisse; stellen Sie sicher, dass Sie die richtige Wahl treffen – wenn Ihr SAP-Produkt beide Schnittstellen bietet. Leider haben Sie oft keine Wahl. Noch schlimmer: Sie können kein beliebiges Tool verwenden, sondern sind gezwungen, das richtige lizenzierte SAP-Tool oder eine Wrapper-Schnittstelle zu nutzen. Große Skalierung, hohes Volumen und kontinuierliche Datenverarbeitung sind keine idealen Anforderungen für diese (Legacy-)Integrationsprodukte.
Für die direkte HTTP(S)-Kommunikation mit Kafka ist der Confluent REST Proxy eine hervorragende Option zum Erzeugen, Konsumieren und Verwalten von jedem Kafka-Client (einschließlich kundenspezifischer SAP-Anwendungen). Zum Beispiel kann SAP Cloud Platform Integration (CPI) dieses Integrationsmuster nutzen, um zwischen SAP und Kafka zu integrieren.
SAP-spezifische Drittanbieter-Tools für Kafka
Die SAP-Integration ist weltweit ein riesiger Markt. SAP bietet mehrere Tools für die Datenintegration an (einige veraltet, einige modern – ehrlich gesagt habe ich keinen vollständigen Überblick über ihr komplexes Produkt- und API-Portfolio). Zusätzlich haben viele andere Softwareanbieter spezifische Integrationssoftware für SAP-Systeme entwickelt.
Einige Beispiele, die ich in letzter Zeit im Feld gesehen habe:
Beispiele:
Dies sind nur einige Beispiele. Viele weitere existieren für On-Premise-, Cloud- und Hybrid-Integration mit verschiedenen SAP-Produkten und Schnittstellen.
Einige dieser Tools sind nativ in SAPs Integrationstools integriert, anstatt völlig unabhängige Laufzeitumgebungen zu sein. Dies kann gut oder schlecht sein. Ein Vorteil dieses Ansatzes ist, dass Sie die SAP-nativen Funktionen für komplexe iDoc-/BAPI-Mappings und den integrierten Drittanbieter-Konnektor für die Kafka-Kommunikation nutzen können.
Vorteile:
- Schlüsselfertige Lösung: Für die SAP-Integration entwickelt, oft kombiniert mit weiteren nützlichen Funktionen jenseits der reinen Konnektivität, leichter als traditionelle generische Middleware.
- Fokus: Viele Drittanbieter-Lösungen konzentrieren sich auf einige spezifische Anwendungsfälle und/oder Produkte und Technologien. Es ist viel schwieriger, „SAP im Allgemeinen“ zu integrieren, als sich auf eine bestimmte Nische zu konzentrieren, z.B. Personalprozesse und zugehörige HTTP-Schnittstellen.
- Reife: Über Jahre entwickelt.
- Tooling: Visuelle Programmierung für die Integration (aufgrund der Komplexität erforderlich), direkte Abbildung von iDoc / BAPI / Hana / SOAP-Schemata auf andere Datenstrukturen.
- Integration: Nicht nur Konnektoren zu den Altsystemen, sondern auch moderne Technologien wie Kafka.
Nachteile:
- Skalierbarkeit: Oft monolithische, unflexible Architektur (aber mit Fokus auf SAP-Integration allein, daher oft „halbwegs in Ordnung“).
- Starke Kopplung: Die Integration muss auf dem Tool entwickelt und ausgeführt werden, aber getrennt von anderer Middleware, somit Entkopplung und Domain-Driven Design (DDD) in Verbindung mit Kafka.
- Lizenzierung: Moderate Kosten pro Server (typischerweise günstiger als die traditionelle generische Middleware).
- Punkt-zu-Punkt: Keine Streaming-Architektur; die meisten Integrationen basieren auf Webdiensten (auch wenn der Kern darunter auf einem Messaging-System basiert).
Kurz gesagt:
Eine schlüsselfertige Lösung ist in vielen Szenarien eine ausgezeichnete Wahl. Ich sehe dieses Muster, Kafka mit einer dedizierten Drittanbieterlösung für die SAP-Integration zu kombinieren, sehr oft. Ich mag es, da die Architektur immer noch entkoppelt ist, aber keine enormen Anstrengungen für eine (komplexe) SAP-Integration erforderlich sind. Und es besteht immer noch die Hoffnung, dass selbst SAP eine schöne Kafka-native Integrationsplattform herausbringt. 🙂
Kafka-native SAP-Integration mit Kafka Connect
Kafka Connect, eine Open-Source-Komponente von Apache Kafka, ist ein Framework zur Verbindung von Kafka mit externen Systemen wie Datenbanken, Schlüssel-Wert-Speichern, Suchindizes und Dateisystemen.
Kafka Connect-Konnektoren sind für SAP ERP-Datenbanken verfügbar:
Vorteile:
- Kafka-native: Kafka im Hintergrund, bietet Echtzeitverarbeitung für große Datenmengen mit hoher Skalierbarkeit und Zuverlässigkeit.
- Einfachheit: Nur eine Infrastruktur für Messaging und Datenintegration, viel einfacher zu entwickeln, zu testen, zu betreiben, zu skalieren und zu lizenzieren als die Verwendung verschiedener Frameworks oder Produkte (z.B. Kafka für Messaging plus ein ESB für die Datenintegration).
- Echte Entkopplung: Kafkas Architektur verwendet standardmäßig intelligente Endpunkte und dumme Pipes, eines der wichtigsten Designprinzipien von Microservices. Nicht nur für die Anwendungen, sondern auch für die Integrationskomponenten. Nutzen Sie alle Vorteile einer Domain-Driven-Architektur für Ihre Kafka-native Middleware.
- Kundenspezifische Konnektoren: Kafka Connect bietet eine offene Vorlage. Wenn kein Konnektor verfügbar ist, können Sie (oder Ihr bevorzugter Systemintegrator oder Kafka-Anbieter) einmal einen SAP-spezifischen Konnektor erstellen und ihn überall bereitstellen.
Nachteile:
- Nur Datenbankkonnektoren: Zum Zeitpunkt der Erstellung dieses Artikels sind über die native JDBC-Datenbankintegration hinaus keine weiteren Konnektoren verfügbar.
- Anti-Pattern des direkten Datenbankzugriffs: In den meisten Fällen möchten oder müssen Sie sich mit einer Funktion oder einem Dienst integrieren, nicht mit den