SAP to Kafka: What Onibex OneConnect Delivers That SLT, Datasphere, and Fivetran Leave for You to Build
Ricardo
Last updated: August 2026
A native business event, a modeled entity, and a governed Kafka topic, end to end, out of the box. Here's what happens to that same requirement everywhere else in the SAP ecosystem.
Nobody building against SAP gets to read the database directly, so every serious integration path, SAP's own included, works through the application layer instead. That part isn't in dispute anymore. What's worth asking is what a complete answer to "SAP to Kafka" actually requires, and how much of it any given tool hands you versus leaves for you to build.
What a complete SAP to Kafka pipeline actually requires
Three things, in order, and all three have to hold:
- A trigger at the business-object level, not the table: the moment a sales order posts or a billing document clears, not the moment a row changes underneath it.
- That event resolved into a modeled, joined entity: the sales order as one thing, not
VBAKandVBAParriving separately for someone downstream to reassemble. - Delivery into Kafka as a governed, schema-enforced record: Avro, registered in a schema registry, ready for any destination that speaks Kafka.
Most tools in the SAP ecosystem hand you one of these, sometimes two. Almost none hand you all three already wired together.
How Onibex OneConnect delivers all three
This is the part built specifically to close that gap, in two pieces that hand off to each other.
The Data Modeler is where a business object gets declared (a sales order, a billing document, a material master) by joining the tables that make it up, visually, inside SAP, with no ABAP development. It ships with 150+ common entities pre-mapped, so most teams start from activation rather than modeling from scratch. That same declaration is where the entity gets wired to the native business event that should trigger it (the right BOR, RAP, BTE, or PPF event, depending on the SAP generation), so requirement one and two are satisfied by the same piece of configuration.
The Smart Gateway is what happens the instant that event fires: it receives the changed record, serializes it into Avro with the schema enforced at write time, registers that schema in the Confluent Schema Registry, and writes it to a Kafka topic, end to end in seconds. That's requirement three, satisfied automatically every time the entity fires, with no separate integration project per data product.
Put together, Onibex OneConnect is the only path in this landscape where all three requirements come from a single, SAP-verified product rather than from stitching several native building blocks together.
Measured against that bar
SLT (SAP Landscape Transformation Replication Server) gets close on delivery speed and nowhere near on the object. It installs a database trigger on every source table, logs changes into logging tables on the source system, and replicates them in order. It's genuinely event-driven at the row level, with a real footprint on the system you're trying to keep clean (a trigger, a logging table, and a queue per replicated table). But the unit it moves is the table. SLT doesn't know VBAK and VBAP belong to the same sales order, and it isn't a Kafka target on its own. It feeds SAP-side destinations like BW/4HANA, or feeds Datasphere.
Datasphere is where SAP's own Kafka story actually shows up: its Replication Flows now support Confluent Kafka as a target, with Avro and Schema Registry support on both sides. That's a real, current capability worth taking seriously. What it inherits from underneath is the same limitation SLT has: an ABAP-source flow still runs on SLT or ODP, so the unit moving through it is still a table or CDS view on a delta interval (60 minutes by default, tunable down but still schedule-driven), not a business object fired at the moment it changes. The delivery format problem is solved. The object problem is exactly where it started.
Fivetran takes a third path: an installed function module inside SAP, extracting over RFC using change pointers and table triggers. It's a real, lighter-weight CDC mechanism, but it answers a different question entirely: Fivetran's category is SAP-to-warehouse, landing data directly in Snowflake or BigQuery. If the actual requirement is a governed Kafka topic other systems can subscribe to independently, that's not the shape of tool this is, regardless of how good the underlying CDC is.
Building it yourself on SAP BTP with Event Mesh or Advanced Event Mesh is the closest any alternative gets to requirement one: the NetWeaver Event-Enablement Add-on publishes native S/4HANA business events straight out of the application layer, no table trigger involved. But it hands you the event and stops there. Modeling the business object is still your build. Serialization and schema governance are still your build. Event Mesh speaks CloudEvents over a pub-sub protocol, not Kafka, so bridging it into an actual Kafka topic with Avro and a schema registry is separate integration work. It's the right primitive. It's still a primitive, not a pipeline.
Side by side, against the same three requirements
| Onibex OneConnect | SLT | Datasphere | Fivetran | BTP Event Mesh (DIY) | |
|---|---|---|---|---|---|
| Trigger at the business-object level | ✅ Native (BOR/RAP/BTE/PPF) | ❌ Table-level trigger | ❌ Table-level, via SLT/ODP | ❌ Table-level (change pointers) | ✅ Native, same category |
| Business object modeled and joined for you | ✅ Data Modeler, 150+ pre-mapped | ❌ Your build | ❌ Your build | ❌ Your build | ❌ Your build |
| Delivered to Kafka with Avro + Schema Registry | ✅ Smart Gateway, automatic | ❌ Not a Kafka target | ✅ Yes, as of Replication Flows | ❌ Lands in a warehouse instead | ❌ Needs a bridge you build |
| All three from one product | ✅ | ❌ | ❌ | ❌ | ❌ |
What this actually means for the decision
Every alternative above is a legitimate tool for the specific slice it was built for: SLT and Datasphere for SAP-native and warehouse-adjacent replication, Fivetran for landing SAP data directly in a warehouse, Event Mesh for anyone building a fully custom event-driven architecture on BTP. None of them, on its own, closes all three requirements at once. Onibex OneConnect is built to be the one that does: the same category of native business event the rest of the ecosystem is converging toward, already modeled, already governed, already in Kafka, without assembling three separate tools to get there.
Frequently asked questions
What does Onibex OneConnect deliver that a native business event stream on its own doesn't? The event alone only tells you something happened. OneConnect's Data Modeler resolves it into a joined business object, and the Smart Gateway packages that object into a schema-governed Avro record in Kafka, automatically, every time the event fires.
Does SLT ever reach Kafka on its own? Not directly. SLT feeds SAP-side targets like BW/4HANA, or feeds Datasphere, which is where a Kafka target with Avro and Schema Registry actually appears.
Is Datasphere's Kafka delivery built on a different mechanism than SLT? No. An ABAP-source Replication Flow still runs on SLT or ODP underneath, so what reaches Kafka is still a table or CDS view moved on a delta interval, not a business object fired at the moment it changed.
Is Fivetran a SAP-to-Kafka tool? No. Its category is SAP-to-warehouse, landing data directly in destinations like Snowflake or BigQuery. A governed Kafka topic other systems can subscribe to independently isn't what it's built to produce.
If BTP Event Mesh already publishes native business events, why not just build on it directly? You can. It's a legitimate primitive. What it doesn't include is the business-object modeling, the Avro/schema-registry packaging, or a bridge into an actual Kafka topic. Those stay separate builds.
If you want to see all three requirements running end to end against your own SAP system (native event, modeled object, governed Kafka topic), Onibex runs the 15-Hour Business Value Challenge as a no-cost proof of concept.