SAP Data Extraction Without ODP: How OneConnect Streams SAP Data in Real Time
Raúl Tovar
Last updated: August 27, 2026
Short answer: SAP data extraction without ODP is the whole point of how OneConnect works. Instead of reading a delta queue, it captures application layer business events (RAP, BOR, BTE, and PPF). SAP Data Modeler pushes them over an HTTP RFC destination of type G to the Smart Gateway, which streams them through Kafka or Confluent Cloud to any destination you need.
The question that always comes up first
Every time a Basis lead sits in on a review, the conversation goes the same way. Somebody on the data team says "we want to stream SAP in real time," and before the sentence is even finished, the Basis lead asks the only question that actually matters to them: is this going through ODP?
It is a fair question. For years, ODP (Operational Data Provisioning) has been the default answer to "how do I get data out of SAP." It works, SAP supports it, and most Basis teams have opinions about it, some good, some not. So when a new tool shows up claiming real time streaming, the reasonable assumption is that it is just ODP with a nicer UI on top.
OneConnect is not that. This page exists to answer the ODP question directly, in plain terms, so a Basis review does not stall on an assumption that turns out to be wrong.
Which SAP event frameworks does OneConnect use?
OneConnect captures SAP changes through application layer business events. That means it uses four standard SAP frameworks, all of them already part of the ABAP stack your team knows:
The RESTful Application Programming model (RAP), the Business Object Repository (BOR), Business Transaction Events (BTE), and the Post Processing Framework (PPF). When a business event fires inside one of these frameworks, say a sales order gets created or a delivery gets confirmed, OneConnect picks up the event at the point where the application already knows what happened. It does not go looking for the change afterward in a table or a log.
The event itself just identifies that a record was created or modified in SAP. From there, SAP Data Modeler is what pushes that identified change outbound from SAP ECC or SAP S/4HANA, over an HTTP RFC destination of type G, to the OneConnect Smart Gateway. That RFC destination is a standard SAP outbound connection type, configured the same way any other RFC destination is configured.
The Smart Gateway processes the incoming change through Apache Kafka or Confluent Cloud. Once the record is sitting in that stream, it can be delivered onward to whatever destination you actually need it in: Databricks, Snowflake, ClickHouse, or any other target on the list.
How OneConnect moves data from SAP to any destination, with no ODP, change pointers, or database triggers
Does OneConnect use ODP or change pointers?
This is the part worth repeating, because it is the part that actually closes the objection:
OneConnect does not use ODP or ODP RFC. It does not use SAP change pointers. It does not use database triggers, and it does not do log based or database level change data capture against SAP tables. There is no polling of a delta queue, no extraction job reading from a change document table, none of it. Every trigger in the path is at the application layer, and every delivery is an outbound push initiated by SAP, not an inbound pull against the database.
If your team's first question when evaluating a new integration tool is "does this read my tables directly," the honest answer here is no, and that is not a marketing line, it is the actual mechanism.
How does ODP extraction compare to application layer event capture?
Putting the two approaches side by side usually settles the conversation faster than a paragraph does.
| ODP based extraction | OneConnect application layer capture | |
|---|---|---|
| What triggers the capture | A delta queue is read, typically on a schedule | A business event fires inside RAP, BOR, BTE, or PPF |
| Direction of the connection | SAP is queried by an extraction job | SAP pushes the event out over RFC destination type G |
| What travels with the data | Raw field values from the extraction structure | The business event, already carrying application intent |
| Exposure to schema change | Coupled to the underlying extraction structure | Coupled to the event framework, which changes less often |
| Load pattern on SAP | Batch reads, often scheduled around off hours | Continuous, small events pushed as they occur |
| Database access | None directly, but reads through the ODP layer | None. No table access at any point |
Neither approach is wrong on its own terms. ODP was built to solve a different problem, moving structured extracts into BW or a data warehouse on a schedule. OneConnect is solving a different one: getting a business fact out of SAP the moment it happens, with enough context for the receiving system to know what actually occurred, not just that a row changed somewhere.
Why this distinction is worth defending, not just explaining
A row that changed in a delta queue tells you a field moved from one value to another. It does not tell you why. A goods movement table update does not say "this shipment just left the plant," it says a quantity field changed on a material document. The business meaning behind that change lives in the application logic, in the same place RAP, BOR, BTE, and PPF already sit. Capturing at that layer means the event that reaches Kafka already carries the business fact, not just the row delta.
That is also the reason this matters more than it sounds like it should to a Basis team specifically. ODP extraction structures are tied to the underlying data model. When that model shifts across a support pack or an upgrade, the extraction has to be revalidated. Application layer events are tied to a business process definition that tends to be more stable across releases, because SAP itself has less reason to change what "a sales order was created" means than it has reason to reshape an underlying table.
Is OneConnect compatible with a clean core strategy?
If your organization has a clean core mandate on the table, this is usually the second question after the ODP one. The answer here is straightforward: OneConnect uses standard, sanctioned SAP frameworks and an outbound RFC destination, so nothing in the SAP core gets modified and nothing reads the database directly. That is consistent with a clean core posture, where extensions live beside the core against stable interfaces rather than inside it.
It is worth being precise about what "supported" means here too. OneConnect covers SAP ECC and SAP S/4HANA. For S/4HANA Cloud, the supported target is the Private Edition. If your landscape is planning a move to S/4HANA Cloud Public Edition specifically, that is a conversation to have early, not something to discover during a proof of concept.
A real scenario worth walking through
A review with an engineering team wanting real time inventory data flowing into a dashboard used by a plant operations group followed the same pattern. The data team had already built the dashboard mockups. The Basis lead had one open item on the approval list: "confirm this does not read the ECC database directly, and confirm it is not another ODP job we will have to babysit through the next upgrade."
Walking through the same four items covered above, RAP, BOR, BTE, PPF, and the outbound RFC destination of type G, closed it. No ODP, no change pointers, no triggers. The authorization objects were reviewed as a normal outbound RFC connection, because that is what it is. The review closed in one meeting instead of the usual back and forth over several weeks, because the questions had concrete, checkable answers instead of a vendor claim to take on faith.
That is really the point of this page. A Basis lead is not being difficult by asking whether a tool touches the database. It is the right question to ask about anything that claims real time access to a production ERP. The answer here just happens to be no, and it is worth being able to say that plainly, with the mechanism named, rather than around the question.
Frequently asked questions
Does OneConnect require any form of database access to SAP? No. Change capture happens entirely at the application layer, and delivery is an outbound HTTP push from SAP. There is no direct database read anywhere in the path.
Does OneConnect use SAP change pointers instead of ODP? No. Change pointers are a different extraction mechanism and OneConnect does not use them either. Capture is based on application layer business events through RAP, BOR, BTE, and PPF.
Is this compatible with a clean core strategy? Yes. OneConnect uses standard SAP frameworks and an outbound RFC destination of type G. The SAP core is not modified and the database is not accessed directly, which lines up with a clean core posture.
Which SAP releases does this apply to? SAP ECC and SAP S/4HANA. For SAP S/4HANA Cloud, the supported deployment is the Private Edition.
What is the actual authorization footprint for this? An outbound RFC destination of type G, configured and authorized the same way any other outbound HTTP connection from SAP would be. There is no special database access role involved, because there is no database access.
Related reading: for the full mechanism behind these four frameworks, including the exact event flow, see How Does OneConnect Capture SAP Business Events?. For the broader architectural argument on why a business event carries more than a database row change, see SAP Business Events vs. Change Data Capture.
For SAP's own documentation on Operational Data Provisioning, see sap.com/resources/what-is-a-clean-core.
About Onibex
Onibex is an SAP Silver Partner and Confluent Gold Partner building real-time SAP data hyperconnectivity for the enterprise. Its flagship platform, Onibex OneConnect, streams SAP ECC and SAP S/4HANA business events to Apache Kafka, Confluent Cloud, Databricks, Snowflake, and other destinations in real time. Onibex also maintains ASK (Agentic Semantic Knowledge), an open semantic-layer standard that grounds AI agents in governed, business-ready SAP data. Onibex is headquartered in The Woodlands, Texas.