Kafka Sender Batching für SAP Integration Suite: Records effizient bündeln
Der KaTe Kafka Adapter bündelt Records aus einem Kafka-Poll zu einem Batch-Payload. Damit können SAP Integration Suite und Edge Integration Cell Kafka-Workloads mit weniger wiederholten Integrations- und Netzwerkaufrufen verarbeiten.
Kafka kann deutlich mehr Events bereitstellen, als ein klassisches Backend einzeln pro Anfrage verarbeiten kann. Der Engpass ist dabei häufig nicht Kafka selbst. Er entsteht durch den wiederholten Integrations- und Netzwerk-Overhead, wenn jeder Record eine eigene Message in der SAP Integration Suite und einen eigenen Backend-Aufruf auslöst.
Die Funktion Sender Batch des KaTe Kafka Adapters für SAP Integration Suite verändert diese Gleichung. Statt jeden aus Kafka gepollten Record in eine separate Cloud-Integration-Message zu überführen, kann der Adapter die aus einem Poll zurückgegebenen Records zu einem Batch-Payload zusammenfassen. Ein Integrationslauf kann dann viele Business-Records gemeinsam validieren, mappen und zustellen.
Batching und Partition-Parallelität ergänzen sich: Partitionen liefern parallele Verarbeitungslanes, Batching macht jede Lane effizienter. Das Ergebnis können erheblich weniger Integrations- und Netzwerk-Round-Trips für Kafka-Workloads sein, die über die SAP Integration Suite verarbeitet werden.
Was ändert sich im Batch-Modus?
Im Single-Record-Modus erzeugen 100 Kafka-Records bis zu 100 Cloud-Integration-Messages. Im Batch-Modus kann der Adapter eine Message mit bis zu der konfigurierten Anzahl Max poll records erzeugen. Das Backend erhält weniger, dafür größere Aufrufe. Kafka-Offsets werden erst committed, nachdem der vollständige Batch erfolgreich in die Cloud Integration übertragen wurde.
Zwei Payload-Formate stehen zur Verfügung:
Für eine kontinuierliche Verarbeitung sammelt der Adapter verfügbare Records bis zum konfigurierten Poll-Limit. Ist der Batch noch nicht voll, kann er das konfigurierbare Batch-Fenster abwarten, bevor die bereits verfügbaren Records übergeben werden. Die Intervallverarbeitung erzeugt einen Batch aus den Records, die der Poll dieses Intervalls zurückliefert.
Ein illustratives Durchsatzmodell für Kafka Sender Batching
Betrachten wir ein Topic mit vier Partitionen und genügend parallelen Consumern, um alle vier auszulasten. Eine Single-Record-Backend-Interaktion dauert Ende zu Ende 50 ms: 25 ms Netzwerk- und Protokolllatenz plus 25 ms Backend-Arbeit.
Dies sind vergangene Zeiten einschließlich Bestätigung und Commit, sofern zutreffend. Das Modell nimmt vier aktive Verarbeitungslanes an und schließt zusätzliche iFlow-Verarbeitung sowie Batch-Sammelzeiten aus.
4 parallele Partitionen / 0,050 Sekunden = 80 Records pro SekundeBatching amortisiert die Integrations- und Netzwerkkosten. Der genaue Gewinn hängt davon ab, ob das Backend eine echte Bulk-Operation unterstützt oder den Großteil der Arbeit weiterhin Record für Record erledigt.
| Modus | Illustrativer Durchsatz | Gewinn gegenüber Single Record |
|---|---|---|
| Single Record | 80 Records/s | 1× |
| Batch mit 10 Records; vollständiger Batch in 50 ms verarbeitet | 800 Records/s | 10× |
| Batch mit 100 Records; vollständiger Batch in 50 ms verarbeitet | 8.000 Records/s | 100× |
| Batch mit 10 Records; 25 ms Netzwerk pro Batch + 25 ms Arbeit pro Record | ca. 145 Records/s | ca. 1,82× |
| Batch mit 100 Records; 25 ms Netzwerk pro Batch + 25 ms Arbeit pro Record | ca. 158 Records/s | ca. 1,98× |
Der optimistische Fall setzt voraus, dass ein Backend den vollständigen Batch ungefähr in denselben 50 ms wie einen einzelnen Record verarbeiten kann. Der konservative Fall nimmt an, dass nur der Netzwerkanteil von 25 ms geteilt wird, während pro Record 25 ms Arbeit verbleiben. Sein Speed-up lautet:
Speed-up(B) = 50 × B / (25 + 25 × B) = 2B / (B + 1)Unter diesen Annahmen kann das Vermeiden wiederholter Netzwerk-Round-Trips selbst bei linearer Backend-Arbeit einen Wert nahe 2× erreichen. Eine echte Bulk-API, eine Bulk-Datenbankoperation oder eine vektorisierte Transformation kann das Ergebnis deutlich näher an den Batch-Größen-Multiplikator bringen. Die Werte sind ein Kapazitätsplanungsmodell und kein gemessener Produktbenchmark: Payload-Größe, Mapping-Kosten, Worker-Anzahl, Broker-Latenz, Retries und Backend-Limits beeinflussen den produktiven Durchsatz.
Warum ein JDBC-Batch fast so schnell wie ein einzelnes Insert sein kann
Ein JDBC-Insert von 50 ms einschließlich Netzwerkweg und Commit ist für eine entfernte Datenbank eine plausible Annahme. Ein moderater Batch kann nahe an diesem Wert liegen, wenn der feste Overhead dominiert: JDBC Batching reduziert Round-Trips, während eine Transaktion den Commit-Overhead auf mehrere Zeilen verteilt.
Ein Beispiel: 49 ms fester Overhead + 1 ms pro Zeile ergeben 50 ms für ein Insert und 149 ms für 100 Zeilen. Vier parallele Lanes liefern dann ungefähr 2.685 Records/s – das 33,6-Fache der Single-Record-Basislinie. Dies sind illustrative Eingaben; Indizes, Trigger und Lock Contention beeinflussen die tatsächlichen Ergebnisse. Der zuvor beschriebene Fall nahe 2× nimmt an, dass sich die gesamte Backend-Arbeit pro Zeile wiederholt. Er ist daher kein allgemeines JDBC-Limit.
Weniger gemessene Messages in der SAP Integration Suite
Batching kann auch den Message-Verbrauch der SAP Integration Suite senken. Nach der öffentlichen SAP-Preisdefinition werden Cloud-Integration-Messages in 250-KB-Blöcken – nicht 256 KB gezählt. Eine Outbound-Message bis 250 KB zählt als eine Message; jeder weitere angefangene 250-KB-Block als weitere. Bei synchronen Receiver-Aufrufen betrachtet SAP Request und Response gemeinsam, und spezielle Muster wie Splitter haben eigene Zählregeln. Die konkrete kommerzielle Wirkung hängt von Kundenedition, enthaltenem Volumen, Vertrag und der Frage ab, ob eine Message abrechenbar ist. Prüfen Sie die aktuelle SAP Integration Suite Pricing Definition und validieren Sie den ausgerollten Flow im Message Usage Dashboard des Tenants, bevor eine Schätzung für die Budgetplanung verwendet wird.
Beispielsweise erzeugen 20 einzeln verarbeitete Records unter 250 KB üblicherweise 20 Outbound-Backend-Messages und damit mindestens 20 gemessene Messages. Bilden dieselben Records einen Outbound-Batch, der einschließlich Envelope und – bei synchronem Aufruf – Response bei oder unter 250 KB bleibt, kann dieser Batch als eine gemessene Message zählen. Wächst der Batch auf 600 KB, zählt er als drei statt 20. Batching macht Payload-Volumen nicht kostenlos, beseitigt aber die sonst für jeden kleinen Outbound-Aufruf anfallende Mindestmenge von einer Message.
Single-Record-Einheiten ≈ Anzahl Records × ceil(Größe eines Outbound-Records / 250 KB)
Batch-Einheiten ≈ ceil(Gesamtgröße des gebündelten Outbound-Payloads / 250 KB)Dies ist eine Planungsnäherung. Header, Envelopes, Receiver-Aufrufe, synchrone Responses, Retries, Splitter und der final ausgerollte Flow können den gemessenen Gesamtwert verändern.
Wo Kafka Sender Batching besonders hilft
Sender Batching ist besonders wirksam, wenn das nachgelagerte System bereits Bulk-Requests, Datenbank-Array-Operationen, Massenänderungen oder dateiorientierte Schnittstellen unterstützt. Es kann auch die Anzahl von Cloud-Integration-Message-Processing-Logs und wiederholten Verbindungsaufbauten für dasselbe Geschäftsvolumen reduzieren.
Es gibt einen bewussten Trade-off: Ein Batch ist eine Verarbeitungseinheit. Größere Batches verbessern die Amortisation, können aber die Latenz pro Record, den Speicherverbrauch und den bei einem Fehler erneut zu verarbeitenden Arbeitsumfang erhöhen. Eine Channel-seitige Single-Record-Deduplizierung steht für variable Batches nicht zur Verfügung. Die Downstream-Verarbeitung sollte deshalb idempotent sein oder Records anhand stabiler Business-Identifikatoren deduplizieren. Batching steht zudem nicht für selektive Support-Mode-Reads zur Verfügung.
Entscheidungsmatrix: Soll der Sender Batching verwenden?
Entscheidend ist, ob das angebundene Backend eine Sammlung effizient verarbeiten kann. Das bloße Verpacken von Single-Record-Aufrufen in ein XML-Dokument schafft noch keine Bulk-Operation.
| Backend oder Anforderung | Eignung | Hinweis |
|---|---|---|
| BI-, Data-Warehouse- oder Data-Lake-Ingestion | Stark | Diese Systeme bevorzugen häufig größere Blöcke, Staging-Dateien oder Bulk-Load-APIs. |
| JDBC Batch Insert/Upsert oder set-basierte Datenbankprozedur | Stark | Eine echte Bulk-Anweisung, Array Binding, Staging-Tabelle oder massenfähige Prozedur nutzen; eine Schleife einzelner Inserts bringt weniger Nutzen. |
OData $batch | Stark, wenn unterstützt | Prüfen, ob der Service $batch unterstützt, festlegen, ob Operationen zu einem transaktionalen Change Set gehören, und den Kafka-Batch auf die erforderliche Multipart-Anfrage abbilden. |
| Datei-, SFTP- oder Object-Storage-Zustellung | Stark | Ein Batch passt natürlich zu einer Datei mit mehreren Records, wenn der Empfänger dies erwartet; er ist ungeeignet, wenn jedes Event eine separate Datei bleiben muss. |
| Massenfähige BAPI- oder SOAP-Operation | Bedingt | Batching nur verwenden, wenn die Operation oder ein kontrollierter Wrapper eine Tabelle/Liste akzeptiert und das Verhalten bei Teilfehlern definiert. |
| Standard-BAPI- oder SOAP-Service für ein Einzelobjekt | Meist schwach | Viele Standardoperationen führen weiterhin eine Business-Transaktion pro Aufruf aus; Batching kann einen spezifischen Wrapper und sorgfältiges Commit-Handling erfordern. |
| Response pro Record, unabhängiger Retry oder sehr niedrige Latenz | Schwach | Single-Record-Verarbeitung bewahrt granulare Bestätigungen und vermeidet das Warten auf ein Batch-Fenster. |
| Stark variable oder sehr große Payloads | Bedingt | Konservative Limits setzen und die kombinierte Anfrage gegen CPI-, Adapter-, Backend- und Netzwerkgrößenlimits testen. |
| Backend kann keine Sammlungen verarbeiten | Nicht batchen | Der iFlow müsste aufsplitten und loopen. Das verliert einen großen Teil von Durchsatz- und Metering-Vorteil und erhöht zugleich die Komplexität. |
Ein praktischer Startpunkt
Beginnen Sie mit einem moderaten Wert für Max poll records, etwa 10 oder 25, richten Sie die Anzahl paralleler Consumer an den verfügbaren Topic-Partitionen aus und prüfen Sie, ob das Backend den Batch tatsächlich effizient verarbeitet. Erhöhen Sie die Batch-Größe anschließend schrittweise und beobachten Sie Ende-zu-Ende-Latenz, gemessenen Message-Verbrauch, Payload-Größe, Speicher, Retry-Verhalten und Backend-Sättigung. Ein Batch-Fenster sollte lang genug sein, um sinnvolle Batches zu bilden, aber kurz genug bleiben, um das Latenzziel des Szenarios einzuhalten.
Batching und Partition-Parallelität ergänzen sich: Partitionen liefern parallele Verarbeitungslanes, Batching macht jede Lane effizienter. Gemeinsam ermöglichen sie der SAP Integration Suite, Kafka-Workloads mit deutlich weniger Integrations- und Netzwerk-Round-Trips zu verarbeiten.
Was dieses Update für SAP-Integrationsteams bedeutet
Die folgenden Kurzantworten bewahren den technischen Umfang des Updates und verbessern die Auffindbarkeit in klassischer sowie KI-gestützter Suche.
Was ist Kafka Sender Batching?
Kafka Sender Batching ist eine Funktion des KaTe Kafka Adapters. Sie gruppiert Records aus einem Kafka-Poll in einem Batch-Payload und übergibt diese Gruppe als eine Cloud-Integration-Message zur weiteren Verarbeitung.
Garantiert Sender Batching einen bestimmten Durchsatzgewinn?
Nein. Die Zahlenbeispiele sind Kapazitätsplanungsmodelle und keine gemessenen Produktbenchmarks. Das Ergebnis hängt von Bulk-Fähigkeit und Limits des nachgelagerten Systems sowie von der vollständig ausgerollten Architektur ab.
Was folgt als Nächstes?
Ein Folgeartikel untersucht, wie Confluent Parallel Consumer das Sender-seitige Design durch kontrollierte Parallelität auf Record-Ebene erweitern kann. Dabei werden Reihenfolgeentscheidungen, Offset-Management und die Situationen betrachtet, in denen dieser Ansatz die klassische an Partitionen gebundene Verarbeitung ergänzt oder ersetzt.
Mehr über den KaTe Kafka Adapter
Entdecken Sie unterstützte Kafka-Funktionen, Sicherheitsmerkmale und Integrationsoptionen für SAP Integration Suite und SAP Edge Integration Cell. Sie können auch Ihre Kafka-Architektur mit unseren Integrationsexperten besprechen.
Zur Kafka-Adapter-Seite
