What Is a Business Event in SAP? The Answer Changes How You Do Change Data Capture
Alberth Flores
Last updated: August 2026
A business event in SAP is a notification the system raises by itself when something happens to a business object: a sales order was created, a customer was changed, a delivery was deleted. It is not a row that changed, it is the object that changed, announced by the application that owns the rules about what that object is.
The 4 key points:
- One sales order is not one row. In our own SD reference, the Sales Order data product can draw on nine tables (
VBAK,VBAP,VBPA,VBFA,PRCD_ELEMENTS,MARD,FPLA,VBKD,VBEP), so log based capture returns nine uncorrelated streams with no document boundary. - SAP gives you two event models, BOR for the classic stack and RAP for S/4HANA, plus two on-ramps into them, BTE and PPF.
- BTE is not an alternative to BOR. A business transaction event makes SAP call a function module that creates the BOR event (SAP documentation, 2026).
- The real cost of business events is coverage: a standard event may not exist for the fields you need, and extending it is ABAP work that belongs in the estimate.
Why does the database log look like the right way to do SAP change data capture?
Because it is the door that exists on every other system. There is a write ahead log, a binlog, a redo stream, and a mature tool that reads it, so the instinct is to look for the same door on SAP. I asked an AI assistant whether I could build change data capture on SAP that way, and it told me yes.
It was not exactly wrong, and that is the problem. Something can usually be read. What comes back is rows.
Here is what that costs. In SAP, one sales order is not one row in one table. In our own SD reference, the Sales Order data product can draw on nine tables: VBAK, VBAP, VBPA, VBFA, PRCD_ELEMENTS, MARD, FPLA, VBKD and VBEP.
A stream built from row changes gives you nine uncorrelated streams, in no particular order, with nothing in them that says this document is now complete and consistent. On top of that, the table names do not carry business meaning. VBAK holds sales orders, but it also holds quotations and contracts, so a change to a row in VBAK does not even tell you which kind of document you are looking at.
You do not have an access problem. You have a meaning problem, and the log is the wrong layer to solve it on.
What does Onibex build?
Onibex builds real-time SAP data products and the AI-ready semantic layer on top of them.
The product that does the extraction is Onibex One Connect, a real-time SAP data streaming platform. It has three parts. The SAP Data Modeler runs inside SAP, as a transport package reached through transaction ZONT_ONECM, and it is where you design a data product by connecting tables and CDS views with inner or left outer joins.
The Smart Gateway runs on Kubernetes, receives the data and the metadata, and turns them into Apache Kafka topics and schemas. The Premium Kafka Connectors deliver the result into Databricks, Snowflake or ClickHouse. Alongside them, the One Connect Data Market ships more than 150 pre-packaged SAP data products, so most are extended rather than built.
It is verified by SAP. The part that matters here: the way in is SAP's own.
One layer up, ASK, Agentic Semantic Knowledge, is Onibex's semantic layer for AI agents, built on the medallion architecture. That is a different problem, which is how an AI agent reads this data without guessing. This article stays on the layer below it: getting the change out of SAP in the first place, correctly.
What is a business object in SAP?
A business object is SAP's representation of a real business concept: a sales order, a material, a customer, a production order, an invoice. The important part for anyone building a pipeline is that a business object almost never lives in a single table. It is made up of several related tables, most commonly a header and its items, plus the tables that carry partners, pricing, schedule lines and document flow.
That the document spans many tables is SAP's structure, not anybody's design decision. Which of those tables your data product actually includes is a design decision, and it is yours.
One sales order, nine tables, each carrying a different part of the same document.
Why is a business event different from a log entry?
Because an external system can subscribe to it and be told, instead of asking the database over and over whether anything has moved. That is the practical difference. The structural one is that this is not a workaround anyone invented from the outside.
SAP's own documentation describes a BOR event as a status change in an object that is published across the system, so that potential receivers can react to it, and it is published without the application that raised it knowing who is listening. Assigning a receiver to an event is called a linkage, and the event carries an event container holding the context of how it came about.
That is a publish and subscribe design, described as such, in the vendor's own documentation. The mechanism is not a side door. It is the front door, and it was built for exactly this.
The difference from log based capture is not the delivery speed. It is the unit. A log entry is a row that changed. A business event is a business object that changed, raised by the application that owns the rules about what that object is.
Which mechanisms does SAP actually give you?
Four names come up, and they are not four of the same thing. Two are event models. Two are on-ramps that feed an event model.
| Mechanism | What it actually is | Where it applies |
|---|---|---|
| BOR | Business Object Repository. The classic event model: the object's status change is published for any receiver, through a linkage | SAP ECC, and in S/4HANA for backward compatibility |
| RAP | RESTful ABAP Programming model. The modern event model: the event is declared in the business object's behavior definition | SAP S/4HANA, on-premise and cloud |
| BTE | Business Transaction Events. Financial accounting occurrences. On the event, SAP calls a function module that creates the BOR event | Financial accounting: general ledger, accounts receivable and payable |
| PPF | Post Processing Framework. An action framework: condition dependent generation of actions, and an action can start a workflow or a Business Add-In | Applications that use PPF for output and action determination |
BOR is tied to SAP Business Workflow. A business object is defined in transaction SWO1 with its attributes, methods and events. The event fires through a function module, through change documents that detect changes on specific fields, or through custom logic in a user exit, a BAdI or an enhancement when the standard event does not cover the case. Linkage is configured in SWE2 and SWE3, and you can watch events actually firing in the event linkage log, transaction SWEL.
RAP declares events inside the business object's behavior definition, using the events keyword at the root entity or at a child entity, and raises them from the behavior pool, typically in the method that handles the save. Because the model was designed for decoupled consumption, RAP events integrate natively with Enterprise Event Enablement and with SAP Event Mesh.
BTE is where financial accounting comes in, and it explains why FI shows up in a list of event mechanisms at all. A business transaction event is an occurrence in financial accounting, and when it happens SAP calls a function module that creates the corresponding BOR event.
SAP's documentation is explicit about the purpose of the publish and subscribe interfaces in the general ledger and in accounts receivable and payable: they exist to inform other application components, and external interested parties such as partners and customers, that something has happened in financial accounting. The interface is one way, and no data comes back.
PPF is the odd one out, and calling it an event mechanism oversells it. The Post Processing Framework is a uniform interface for generating actions when conditions are met on an application document: printing a delivery note, faxing an order confirmation, triggering an approval.
What makes it useful here is what an action is allowed to be. An action can start a workflow or start a Business Add-In, and it can be configured to process at the moment the document is saved. That is a hook, and a hook at save time is enough to push a change out.
So the honest shape of the list is two event models, BOR for the classic stack and RAP for the modern one, plus two ways an application reaches them.
Four names, two of them event models and two of them doors into one. BTE creates a BOR event. PPF can start a workflow or a Business Add-In when the document is saved.
Here is what a configured data product looks like, from the SD module reference. The change document object and the event are the two values the SAP Data Modeler needs in order to stream it in real time.
| Data product | Change document object | BOR event | RAP event | Actions |
|---|---|---|---|---|
| Sales Order | VERKBELEG |
BUS2032 |
R_SALESORDERTP |
Create, update, delete |
| Customer Master | DEBI |
BUS1006 |
I_BUSINESSPARTNERTP_2 |
Create, update |
Notice VERKBELEG again. The sales quotation and the sales contract use the same change document object as the sales order, for the same reason they share VBAK. The document type is a business distinction, not a storage one, which is exactly the kind of thing the application layer knows and a row does not.
Where the change document object and the event are declared for a data product, inside SAP. Choosing between the classic and the modern event model is a dropdown with 27 entries.
Look at the table relations. The data product joins five tables, in sequence: header, items, partners, document flow and business data, with items joined INNER and the rest LEFT OUTER. Our SD reference lists nine tables that the Sales Order data product can draw on. Five is what it needed, so five is what it declares.
That is easy to miss, because it looks like a configuration detail. You pick the tables of the business object your data product needs. Reading the database log gives you row changes from all nine whether the data product wanted them or not, and no way to say that it did not.
What happens when the event you need does not exist?
Sometimes it does not, and this is the part that gets left out of architecture diagrams.
Not every business object in the BOR has standard events covering everything an integration needs. It is common to find a creation event and no change event for the specific fields you care about. When that happens, the event has to be extended through an enhancement or a BAdI so that it fires at the right moment. That is real work, it is ABAP work, and it belongs in the estimate.
We would rather say that plainly than let you discover it in week three. Business events are a better foundation, not a free lunch: the mechanism is native and supported, and coverage still has to be checked object by object before you promise a date.
How does a business event become an Apache Kafka topic?
Once the event fires, the path out is the same for every data product.
Every hop from the business event inside SAP to the table in the destination platform.
The Premium Kafka Connectors write into the destination, creating tables and adding columns as new fields appear, with idempotent writes so that a redelivered message does not become a duplicate row.
Two choices are worth making deliberately at modeling time.
The first is the mode, and we frame it as a producer and subscriber model: real-time events on one side, mass data transfer on the other. Real-Time is event driven, using the mechanisms above. Batch is a bulk extraction, run manually or by a scheduled SAP job. Master data that changes twice a year does not need an event.
The second is the shape. In Table Format, each table or CDS view becomes its own topic, which is the familiar CDC shape and suits normalized, field level consumption downstream. In Document Format, called KDOC, the whole document becomes one nested topic, structured the way an IDoc is, which suits consumers that want the document as a unit.
Both can run at the same time. If the nine table problem from the top of this article is what worries you, Document Format is the direct answer to it.
The same event, the same source, two shapes. Both can run at the same time.
How do the approaches to SAP change data capture compare?
Four ways to notice that something changed in SAP, described as classes of mechanism rather than as products.
| Approach | The unit it gives you | What it costs |
|---|---|---|
| Reading the database log | A row that changed | No document boundary, no document type, no business meaning. You rebuild the business object yourself, downstream, from the outside |
| Trigger based replication | A row that changed, at commit time | Same row shaped output, plus objects to install and maintain in the source system |
| Batch or delta extraction | A consistent set of rows on a schedule | Staleness between runs, and reconciliation work when records are modified or deleted between them |
| Business events | The business object that changed, and what happened to it | The event has to exist for that object, or be extended. Coverage is checked per object |
Of these four, the last is the only one where the thing you receive is the thing you wanted.
Where is all of this documented?
The event mechanisms, the per module event reference tables for SD, MM, PP, PM, FI and QM, and the architecture are documented publicly in the One Connect documentation repository.
If you are scoping this work, the order that saves time is: pick the data product, decide which of its tables it needs, check whether a standard event exists for the actions you need, and only then design the pipeline. The pipeline is the easy half. Event coverage is what moves your date.
Frequently asked questions
Can you run Debezium on SAP?
Debezium is built to read a database's change log, which is the layer this article argues against for SAP. Even where rows can be read, what arrives is row changes: nine independent streams for one sales order, no signal that the document is complete, and no way to tell a quotation from a contract when both live in VBAK. The mechanisms SAP itself provides for change notification are BOR and RAP, fed where relevant by BTE and PPF, and they sit in the application layer, where that context still exists.
Can I read the SAP database directly instead?
You can get rows that way, and you will then be reconstructing SAP's business logic outside of SAP, maintaining it yourself, and re-deriving it every time the model changes. Onibex One Connect takes the other route on purpose: it operates as an external data layer using standard SAP mechanisms (RFC, BOR, RAP, BTE and PPF) and does not modify the SAP core, which is what keeps a Clean Core intact.
What is the difference between a BOR event and a RAP event?
BOR is the classic model, available in SAP ECC and kept in S/4HANA for backward compatibility, tied to SAP Business Workflow and configured through SWO1, SWE2 and SWE3. RAP is the modern one, available in S/4HANA, where the event is declared in the business object's behavior definition and integrates natively with Enterprise Event Enablement and SAP Event Mesh. When both are listed for an object, pick the one that matches your release and your architecture. When it offers only one, that is the one.
Is BTE a different mechanism from BOR?
No, and this trips people up. A business transaction event is an occurrence in financial accounting, and when it fires SAP calls a function module that creates the corresponding BOR event. So BTE is how FI gets onto the BOR event model, not an alternative to it.
Does this require ABAP development?
Modeling does not. Data products are designed visually in the SAP Data Modeler, transaction ZONT_ONECM, by joining tables and CDS views, and any of the 150+ pre-packaged data products can be extended the same way. Two cases do involve ABAP: sending custom Z tables programmatically, where Onibex provides reusable templates that a customer adapts, and extending a BOR event that does not exist yet.
Does streaming from business events affect the SAP Clean Core?
No. Extraction uses standard SAP mechanisms and requires no custom enhancements to standard SAP objects, and the governed layer lives outside SAP. Authorization is respected rather than bypassed: a data product can be assigned an SAP authorization object, and for CDS views every access control value is supported except #PRIVILEGED_ONLY.
If you are about to reach for the log because that is what works everywhere else, that instinct is right in general and wrong here: SAP will tell you what happened, in its own words, if you ask in the right place. You can see how Onibex One Connect asks at onibex.com.
Alberth Flores is a data engineer at Onibex, where he works on SAP data products and on ASK, the semantic layer for AI agents. Onibex builds real-time SAP data products and the AI-ready semantic layer on top of them.
Apache, Apache Kafka, Kafka, Apache Avro and Avro are either registered trademarks or trademarks of The Apache Software Foundation in the United States and/or other countries. SAP, SAP ECC, SAP S/4HANA and other SAP products mentioned are trademarks or registered trademarks of SAP SE in Germany and other countries.