Events einzeln zu publizieren ist einfach, wird aber aufwändig, sobald ein Quellsystem bereits eine vollständige Gruppe von Records besitzt. Jeder einzelne Aufruf wiederholt Netzwerk-, Authentifizierungs-, Integrationsflow-, Serialisierungs- und Bestätigungsaufwand. Noch wichtiger: Bei einem Teilausfall kann nur ein Teil einer logischen Gruppe in Kafka sichtbar werden.

Beim transaktionalen Kafka Batching für SAP Integration Suite – im Produkt als Transaktionales Receiver Batching (Atomic Receiver Batching) bezeichnet – adressiert der KaTe Kafka Adapter für SAP Integration Suite beide Punkte. Ein Austausch der SAP Integration Suite kann mehrere Kafka-Records in einer Kafka-Transaktion publizieren. Ein Consumer mit read_committed sieht entweder den vollständig bestätigten Batch oder keinen Record einer abgebrochenen Transaktion.

Eine Anfrage, eine Transaktion, viele Records

Der Receiver-Channel parst und validiert zunächst das vollständige Batch-Envelope. Anschließend reserviert er einen Producer exklusiv, startet eine Kafka-Transaktion, serialisiert und sendet jeden Record, wartet auf alle Bestätigungen und committet die Transaktion. Tritt vor einem bestätigten Commit ein Fehler auf, wird die Transaktion abgebrochen. Producer, die von Fencing, Transaktions-Timeouts, mehrdeutigen Commit-Ergebnissen oder fehlgeschlagenen Abbrüchen betroffen sind, werden geschlossen und vor der erneuten Verwendung neu erstellt.

Das Feature unterstützt drei Request-Formate:

Jeder publizierte Record erhält die Korrelationsheader kate.batch.id, kate.batch.index und kate.batch.size. Eine detaillierte Eingabe kann zusätzlich eine recordId liefern, die zu kate.event.id wird. Derselbe Batch-Vertrag kann die im Receiver-Channel konfigurierte Wertserialisierung Avro, JSON, JSON Schema oder Protobuf verwenden.

Durchsatzeffekt durch weniger Integrationsaufrufe

Der erste Gewinn entsteht vor Kafka: Eine Upstream-Anfrage und ein Cloud-Integration-Austausch transportieren viele Records. Um die mögliche Größenordnung zu veranschaulichen, nehmen wir ein Topic mit vier Partitionen, vier parallele Upstream-Publishing-Lanes, eine durchschnittliche Single-Record-Interaktion von 50 ms und einen Netzwerkanteil von 25 ms innerhalb dieser Zeit an.

Kann ein Batch aus 100 Records ungefähr in denselben 50 ms angenommen, transformiert und committed werden, liegt die rechnerische Obergrenze bei 8.000 Records/s – also beim 100-Fachen der Single-Record-Rate. Dies ist der Idealfall einer effizienten Bulk-Verarbeitung.

Wird der Netzwerkkostenanteil geteilt, bleiben aber 25 ms Transformations- oder Applikationsarbeit pro Element bestehen, benötigt ein Batch aus 100 Records ungefähr 25 ms + 100 × 25 ms = 2.525 ms. Vier Lanes erreichen dann rund 158 Records/s beziehungsweise 1,98×. Ein Batch aus 10 Records erreicht rund 145 Records/s beziehungsweise 1,82×.

Dies ist ein illustratives Latenzmodell und kein Produktbenchmark. Auf der Receiver-Seite sind vier Kafka-Partitionen Verteilungs-Lanes, aber keine strikte Parallelitätsgrenze für einen Producer. Die tatsächlichen Ergebnisse hängen von der konfigurierten Zahl paralleler Producer, Record- und Batch-Größen, Serialisierung, Broker-Bestätigungen, Transaktionslatenz, Kompression, Worker-Node-Ressourcen und der Upstream-Parallelität ab.

Einordnung der 50-ms-Annahme

Die 50 ms enthalten Bestätigung und Commit. Wie bei einem JDBC-Batch kann das Teilen fester Aufruf- und Transaktionskosten zusätzliche Records vergleichsweise günstig machen; Kafka-Timings müssen jedoch separat gemessen werden. Benötigen 100 Records beispielsweise 100–200 ms, liefern vier aktive Publishing-Lanes 2.000–4.000 Records/s beziehungsweise das 25- bis 50-Fache der Single-Record-Basislinie. Diese Szenarien sind illustrativ: Für eine Messung sollten gleichwertige Durability-Einstellungen verglichen und die Batch-Sammelzeit in die Ende-zu-Ende-Latenz einbezogen werden.

Ein Austausch kann auch den Message-Verbrauch senken

Transaktionales Receiver Batching kann neben technischem Overhead auch den Message-Verbrauch der SAP Integration Suite reduzieren. Die aktuelle öffentliche SAP-Preisdefinition misst Cloud-Integration-Messages in 250-KB-Blöcken – nicht in 256 KB: Eine Outbound-Message bis 250 KB zählt als eine Message, jeder weitere angefangene 250-KB-Block als weitere. Bei synchronen Receiver-Aufrufen werden Request- und Response-Größe gemeinsam betrachtet. Vertragsbedingungen, enthaltenes Volumen, SAP-zu-SAP-Ausnahmen, Retries und die Struktur des ausgerollten Flows entscheiden, ob eine technische Reduktion die tatsächliche Abrechnung verändert. Bitte prüfen Sie die aktuelle SAP Integration Suite Pricing Definition sowie die eingesetzte Lösung im Message Usage Dashboard des Tenants.

Als vereinfachtes Beispiel erzeugt die Publikation von 20 kleinen Records über 20 separate Receiver-Austausche üblicherweise mindestens 20 gemessene Outbound-Messages. Trägt ein Receiver-Austausch den vollständig bestätigten Batch und bleibt dessen gemessene Outbound-Größe bei oder unter 250 KB, kann er als eine Message zählen. Ein 600-KB-Batch zählt als drei 250-KB-Einheiten statt als 20. Envelopes, Replies, Retries, Splitter und weitere Receiver-Aufrufe müssen bei der Schätzung eines realen Flows berücksichtigt werden.

Transaktionale Alles-oder-nichts-Sichtbarkeit – nicht End-to-End Exactly-once

Der Zustellvertrag bedeutet vollständige oder keine Sichtbarkeit und ist mindestens einmal. Die transaktionale Alles-oder-nichts-Sichtbarkeit verhindert, dass ein read_committed-Consumer einen partiellen Batch sieht. Sie verhindert jedoch nicht, dass ein Upstream-Retry den vollständigen Batch nach einem unsicheren clientseitigen Ergebnis nochmals als neue Transaktion publiziert. Downstream-Consumer sollten deshalb Batch-ID, Batch-Index, optionale Event-ID oder einen stabilen Business-Key für eine idempotente Verarbeitung verwenden, wenn Duplikate relevant sind.

Consumer, die die Transaktionsgrenze für vollständige oder keine Sichtbarkeit einhalten müssen, sollten Read committed wählen. Ein read_uncommitted-Consumer kann Records aus offenen oder abgebrochenen Transaktionen sehen und eignet sich nicht, wenn der All-or-Nothing-Vertrag erforderlich ist.

Ein Nachweis für jede Publikation

Der Receiver kann keinen Body, eine Zusammenfassung oder detaillierte Record-Metadaten zurückgeben. Eine Zusammenfassung bestätigt generierte Batch-ID, Status COMMITTED und Record-Anzahl. Eine detaillierte Antwort liefert zusätzlich Topic, Partition, Offset und Timestamp für jeden Record und schafft damit einen präzisen Publikationsnachweis. Antworten können XML, JSON oder passend zur Request-Familie sein.

KaTe Launchpad 1.0.6 oder höher kann passende Sender-, Receiver- oder Interoperability-Batch-Verträge aus dem Value Schema generieren. Damit entfallen manuell gepflegte Envelope-Definitionen, während XML-WSDL/XSD- oder JSON-OpenAPI-Verträge mit den konfigurierten Request- und Reply-Modi ausgerichtet bleiben.

Wann ist transaktionales Kafka Batching für SAP Integration Suite sinnvoll?

Das Feature eignet sich besonders für Auftragsgruppen, Stammdatenpakete, synchronisierte Zustandsänderungen oder jede Upstream-Bulk-Schnittstelle, bei der partielle Kafka-Sichtbarkeit irreführend wäre. Starten Sie mit Batches, die sicher in die Payload-Grenzen von Broker und CPI passen, konfigurieren Sie einen Transaktions-Timeout, der Transformation, Bestätigung und Commit abdeckt, und erhöhen Sie Number of producers per worker node nur dann, wenn unabhängige Batches gleichzeitig publizieren müssen.

Das Ergebnis sind nicht nur weniger Aufrufe. Es ist ein klarer Integrationsvertrag: Das Upstream-System übergibt eine logische Gruppe, Kafka macht diese Gruppe vollständig oder gar nicht sichtbar, und der Aufrufer kann einen Record-genauen Publikationsnachweis erhalten.

Dieses Produkt-Update wird von der KaTe GmbH veröffentlicht. Performance- und Message-Consumption-Werte sind illustrative Kapazitätsplanungswerte und müssen mit den ausgerollten Integrationsflows, Payloads und kommerziellen Bedingungen des jeweiligen Kunden validiert werden.