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.

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.

Batching 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.

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:

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.

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.

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.

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

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.

Wachsende SAP-Integrationslandschaften scheitern im Betrieb selten an einem einzelnen iFlow – sondern an fehlender Gesamtsicht. Mehrere SAP Integration Suite Tenants, Edge Integration Cells und hybride Szenarien verteilen Informationen auf unterschiedliche Oberflächen. Wenn Teams zwischen Systemen wechseln, Fehler manuell suchen und erst durch Fachbereiche von Störungen erfahren, wird Monitoring zum reaktiven Firefighting.

IntegraMon ist ein zentrales Dashboard für CPI Monitoring in SAP Integration Suite und SAP Edge Integration Cell. Die Lösung führt Cloud- und On-Premise-Umgebungen in einer Weboberfläche zusammen und unterstützt Teams dabei, iFlows, Nachrichten, Fehler, Zertifikate und Kennzahlen zielgerichtet zu überwachen.

Warum dezentrales CPI Monitoring an Grenzen stößt

Die Standardwerkzeuge bieten eine wichtige Grundlage für die operative Sicht auf einzelne Tenants. Mit zunehmender Zahl von Integrationsszenarien reichen getrennte Einzelansichten jedoch häufig nicht mehr aus. IntegraMon adressiert die typischen Betriebslücken einer wachsenden SAP-Integration-Landschaft.

Was IntegraMon für professionelles CPI Monitoring zusammenführt

IntegraMon verbindet operative Sichtbarkeit mit Analyse- und Governance-Funktionen. Die Lösung ist für Multi-Tenant- und hybride Umgebungen ausgelegt und kann sowohl SAP Integration Suite als auch Edge Integration Cell in einem zentralen Monitoring-Kontext abbilden.

Where Used: Abhängigkeiten vor Änderungen erkennen

Eine Suchfunktion beantwortet, welcher Fehler vorliegt. Eine Where-Used-Analyse beantwortet die weiterführende Betriebsfrage: Wo wird ein Objekt tatsächlich verwendet? IntegraMon macht diese Abhängigkeiten für iFlows, Artefakte, Integrationsszenarien, Zertifikate, Keystore-Einträge, Value Mappings und Endpunkte sichtbar.

Das ist besonders relevant, bevor ein Zertifikat erneuert, ein Keystore-Eintrag ersetzt, ein Endpunkt angepasst, ein Value Mapping geändert oder ein Artefakt deaktiviert wird. Teams können den potenziellen Wirkungsbereich eines Objekts nachvollziehen und Änderungen gezielter planen. Die Funktion schafft Transparenz über Verwendungen; eine automatische Änderung oder Reparatur von Abhängigkeiten wird damit nicht beschrieben.

CPI Monitoring für SAP Integration Suite in drei Schritten zentralisieren

Die Produktseite beschreibt eine Bereitstellung ohne Agent und ohne Änderungen an den bestehenden SAP-Systemen. IntegraMon wird als Container betrieben – wahlweise in der Cloud, beispielsweise auf BTP oder Azure, oder On-Premise.

Nach Angaben der Produktseite ist die Einrichtung in weniger als 30 Minuten möglich. Die tatsächliche Dauer hängt von der Zielumgebung, Netzwerkkonfiguration und der Anzahl der anzubindenden Systeme ab.

SAP Standard Monitoring und IntegraMon im Vergleich

Die folgende Übersicht fasst die auf der Produktseite beschriebenen Unterschiede zusammen. Sie dient als Orientierung für Teams, die prüfen, ob eine zentrale Betriebsplattform für ihre SAP-Integration-Landschaft sinnvoll ist.

Wann sich IntegraMon besonders lohnt

Ein zentrales CPI Monitoring ist besonders relevant, wenn mehrere SAP Integration Suite Tenants, Edge Integration Cells oder hybride Szenarien betrieben werden. Auch bei einer hohen Zahl geschäftskritischer iFlows, wiederkehrenden Zertifikats- oder Keystore-Themen, umfangreicher Payload-Analyse und verbindlichen SLA- oder Reporting-Anforderungen schafft eine gemeinsame Sicht schnell operativen Mehrwert.

Die entscheidende Frage lautet nicht nur, ob einzelne Messages technisch sichtbar sind. Entscheidend ist, ob Betriebsteams eine Störung systemübergreifend erkennen, belegen, analysieren und priorisieren können – bevor sie Geschäftsprozesse beeinträchtigt. Genau hier setzt IntegraMon mit zentralem Dashboard, Suche, Alerting und Reporting an.

Dieses Produkt-Update wird von der KaTe GmbH veröffentlicht. Funktions-, Setup- und Lizenzangaben basieren auf der bereitgestellten IntegraMon-Produktseite und sollten vor Vertragsabschluss oder Go-live gegen den aktuellen Produkt- und Angebotsstand geprüft werden.

KaTe GmbH hat den KaTe Kafka Adapter für die SAP Integration Suite um eine sichere Anbindung privater Netzwerke über den SAP Cloud Connector erweitert. Das Update ermöglicht SAP Cloud Integration und SAP Edge Integration Cell den Zugriff auf private Kafka-Umgebungen, ohne Broker Advertisements zu verändern oder die TLS-Sicherheit zu schwächen.

Sichere hybride Kafka-Anbindung für die SAP Integration Suite

Organisationen, die Apache Kafka in hybriden Umgebungen betreiben, können private Kafka-Broker, Schema-Registry-Dienste und OAuth-2.0-Identitätsanbieter jetzt bei Bedarf über den SAP Cloud Connector erreichen. Gleichzeitig kann jeder Endpunkt weiterhin unabhängig das öffentliche Netzwerk nutzen, wenn dies architektonisch sinnvoll ist.

Das ist relevant, weil Kafka-Landschaften selten einem einheitlichen Netzwerkmodell folgen. Eine Organisation kann private Kafka-Broker betreiben und gleichzeitig einen öffentlich erreichbaren Identitätsanbieter verwenden oder die Schema Registry in einer separaten Netzwerkzone bereitstellen. Der KaTe Kafka Adapter für SAP Integration Suite unterstützt diese Kombinationen, ohne alle Kafka-bezogenen Dienste auf denselben Verbindungspfad festzulegen.

Keine individuelle Broker-Advertisement-Umschreibung und keine TLS-Kompromisse

Eine häufige Herausforderung in hybriden Kafka-Deployments ist der Umgang mit Broker-Adressen, die Clients mitgeteilt werden. Der aktualisierte Adapter vermeidet für die Anbindung über SAP Cloud Connector eine individuelle Umschreibung der Broker Advertisements. Daher müssen Teams keine zusätzliche Ebene für die Adressübersetzung einführen, um von der SAP Integration Suite aus einen sicheren Zugriff auf private Kafka-Dienste herzustellen.

Ebenso wichtig: Die Verbindung bewahrt TLS, Server Name Indication (SNI) und die Hostnamenprüfung. Die etablierte Zertifikatsprüfung bleibt damit erhalten, statt für eine funktionierende hybride Verbindung umgangen zu werden.

Eine praxisnahe Option für SAP Cloud Integration und Edge Integration Cell

Die Erweiterung richtet sich an SAP-Integrationsteams, die SAP-Systeme über Cloud- und private Netzwerkgrenzen hinweg mit ereignisgesteuerten Kafka-Plattformen verbinden müssen. Unabhängig davon, ob eine Architektur SAP Cloud Integration, SAP Edge Integration Cell oder eine Kombination aus beiden nutzt, trennt der Adapter die Integrationslogik klar von den Entscheidungen zur Netzwerkführung.

Das Ergebnis ist eine echte hybride Kafka-Anbindung: privat, wo erforderlich, öffentlich, wo sinnvoll, und durchgängig abgesichert.

Dieses Produkt-Update wird von der KaTe GmbH veröffentlicht. Technische Details und Informationen zu Ihrer Integrationsarchitektur finden Sie auf der oben verlinkten Kafka-Adapter-Produktseite.