How Does OneConnect Capture SAP Business Events?
Raúl Tovar
Last updated: August 2026
Onibex OneConnect captures SAP ECC and SAP S/4HANA record changes through application layer business events, using RAP, BOR, BTE, and PPF. The resulting events push out over an RFC destination Type G to the OneConnect Smart Gateway, with no database access, no ODP, and no change pointers involved at any point.
The 4 key points:
- Four standard SAP frameworks do the capturing: RAP, BOR, BTE, and PPF, all at the application layer, not the database layer
- Delivery is an outbound push over RFC destination Type G (HTTP), not an inbound pull against SAP tables
- ODP, change pointers, and database triggers are explicitly not used at any point in the pipeline
- OneConnect creates Kafka topics and schema registry entries on the fly, with schema evolution support, once the event reaches the Smart Gateway
There is a version of this article that only lists the four frameworks and calls it a day. I want to go one level deeper, because in practice the mechanism is the whole argument. Once someone understands where the event actually comes from, most of the follow-up objections answer themselves.
What Is an SAP Business Event, and How Is It Different From a Database Row Change?
A database row change tells a consumer that a value moved from one state to another. It does not tell that consumer why it moved, because the reason lives in application logic the table itself never records. An SAP business event is generated at the point where that application logic already knows the intent, so it carries business meaning from the moment it is created.
This distinction matters because a row level change and a business event answer two different questions. A row change answers "what value is different now." A business event answers "what happened in the business." A status field flipping from one code to another does not, on its own, tell a downstream system that a sales order was fulfilled. An SAP business event does. I have watched this exact confusion derail an evaluation before, when a team assumed a table extract could stand in for a real event and spent weeks reconciling numbers that never quite matched.
That is also the reason application layer capture and database level CDC are not interchangeable for integration contracts that cross system boundaries. One carries semantics with it. The other requires every consumer to reconstruct those semantics independently, and usually each consumer reconstructs them differently.
| Mechanism | Where it captures | What travels with the data | Typical failure point |
|---|---|---|---|
| Application layer business events (OneConnect) | SAP application logic (RAP, BOR, BTE, PPF) | Business intent and SAP data dictionary semantics | None specific to physical schema changes |
| Database level CDC | Physical table or transaction log | Raw column values only | Breaks when the underlying table structure changes |
Which SAP Frameworks Does OneConnect Use to Capture Business Events?
OneConnect uses four standard, SAP supported frameworks to generate business events at the application layer: RAP (RESTful Application Programming model), BOR (Business Object Repository), BTE (Business Transaction Events), and PPF (Post Processing Framework).
I like naming all four explicitly instead of waving at "SAP's event mechanisms," because that specificity is usually what convinces a technical reader this is not marketing shorthand. None of the four require custom ABAP extraction programs written and maintained by the customer. They are the same mechanisms SAP itself uses internally to trigger business logic, which is why capture happens without modifying the SAP core and without adding custom Z-programs that later block an upgrade.
Each framework covers a different type of object and trigger point inside SAP ECC and SAP S/4HANA, and OneConnect's SAP Data Modeler is where a team selects which entities, tables, and views actually get exposed for a given integration, before any event ever fires.
How Does the Event Reach the OneConnect Smart Gateway?
Once a business event is generated inside SAP, it is pushed outbound over an RFC destination of Type G, which is an HTTP based outbound connection, directly to the OneConnect Smart Gateway. Nothing queries SAP from the outside to retrieve the event.
The Smart Gateway is the component that receives that push and routes it onward. If the target is Apache Kafka, whether self managed, Confluent Platform, or Confluent Cloud, the Smart Gateway creates the topic and the schema registry entry on the fly if they do not already exist, and schema evolution is supported as the underlying SAP structure changes over time.
This is easier to picture with a real scenario than with a diagram, so here is the one I use most often. A manufacturing plant needs inventory visibility that reflects what is actually on the floor, not what the report said the night before. When a goods receipt is posted in SAP, that transaction triggers a business event at the application layer. The event pushes through the RFC destination to the Smart Gateway, lands on a Kafka topic within seconds, and is available to a downstream platform such as Databricks or Snowflake. Nobody ran a batch job at midnight, and nobody polled the material movement table waiting for something to change. The event exists because something happened in the business, and it traveled from there.
Does OneConnect Use ODP, Change Pointers, or Database Triggers?
No. OneConnect does not use Operational Data Provisioning (ODP), does not use SAP change pointers, and does not use database level triggers or log based capture against SAP tables. Change capture happens entirely at the application layer, and delivery is an outbound push from SAP rather than an inbound pull against the database.
There is a question that shows up in almost every technical conversation I have about OneConnect, and it is always the same person who asks it: someone from Basis or the ABAP team. The question is some version of "is this touching my database?" It is not paranoia. Anyone who has run an SAP landscape for a few years has seen what happens when an integration tool decides to query tables directly, or when someone adds triggers "just to pull a couple of fields." Sooner or later that turns into a performance problem, a support problem, or a licensing conversation nobody wanted to have. So I answer with the mechanism, not with a reassurance: application layer events, an outbound RFC destination, and no code path that ever touches the database directly.
OneConnect is also not a table replication tool. Table replication copies physical rows. OneConnect delivers business events that already carry SAP data dictionary semantics, which is a different artifact with a different failure profile.
Is This Approach Compatible With an SAP Clean Core Strategy?
Yes. Clean core means extensions run beside the SAP core against stable APIs and events, instead of modifying core objects directly. Because OneConnect uses standard SAP application layer event frameworks and an outbound RFC destination, the SAP core is not modified and the database is not accessed directly at any point.
I think this is the part people underestimate when they hear "clean core" and assume it rules out real time data by default. It does not, as long as the integration respects the same boundary clean core already draws. Among the ways to liberate events from a legacy ERP, application layer capture is generally considered the preferred path, ahead of reconstructing events from raw change data and ahead of publishing unfiltered state. OneConnect sits in that preferred position by design, not as an afterthought layered on top of an older extraction approach.
Which SAP Versions and Deployments Are Supported?
OneConnect covers SAP ECC and SAP S/4HANA. For SAP S/4HANA Cloud specifically, the supported deployment is S/4HANA Cloud Private Edition. If the target environment is S/4HANA Cloud Public Edition, that is currently outside the supported scope, and it is worth confirming this early rather than late in an evaluation.
If I had to compress this whole article into one line, it would be this: OneConnect is not trying to pull data out of SAP, it is letting SAP tell everyone else what just happened, at the moment it happens, through the same mechanisms SAP already built for that purpose. That is what makes the conversation with Basis short, and the conversation with the architect interesting.
Frequently asked questions
Does OneConnect require database access to SAP?
No. OneConnect captures changes through application layer business events (RAP, BOR, BTE, PPF) and pushes them outbound over an RFC destination Type G. No component of the pipeline queries the SAP database directly.
Does OneConnect use ODP or change pointers?
No. Neither Operational Data Provisioning (ODP) nor SAP change pointers are part of the capture mechanism. Capture happens entirely at the application layer, with delivery as an outbound HTTP push.
Which SAP event frameworks does OneConnect use?
OneConnect uses four application layer frameworks: RAP (RESTful Application Programming model), BOR (Business Object Repository), BTE (Business Transaction Events), and PPF (Post Processing Framework).
Is OneConnect compatible with a clean core strategy?
Yes. Application layer event capture does not modify SAP core objects and does not access the database directly, which aligns with a clean core posture that keeps extensions running beside the core against stable APIs and events.
Is SAP S/4HANA Cloud Private Edition supported?
Yes. OneConnect supports SAP ECC and SAP S/4HANA, and for SAP S/4HANA Cloud the supported deployment is Private Edition. SAP S/4HANA Cloud Public Edition is not currently in scope.
If your team is evaluating how to stream SAP data without touching the database or writing custom extraction ABAP, the full technical breakdown, including the RFC destination configuration, lives in the oneconnect-docs repository.