SAP Business Events vs. Database CDC: Why the Difference Decides Your Architecture

Last updated: August 2026

What is the difference between SAP business events and database CDC

SAP business events and database change data capture (CDC) are two ways to detect that SAP data changed. Database CDC reports that a table row was inserted, updated, or deleted. An SAP business event reports what happened in the business, named in business language, captured in the application layer where the intent is known. The distinction is not cosmetic. It decides whether the integration you build survives contact with a real SAP landscape.

The domain events versus CDC question is one enterprise architects genuinely argue about, and it has a correct answer for most cross-context integration: a row change carries the mutation, not the meaning, and the meaning is exactly what a downstream consumer needs.

Why does raw database CDC break down as an SAP integration contract?

Change data capture is a good tool for replicating a database. It becomes a liability the moment its output crosses a bounded context and becomes a contract that another team depends on.

Three failures follow, and all three are structural rather than incidental.

The first is lost intent. A CDC event says a status field moved from one code to another. It cannot say a sales order was fulfilled, because the business meaning of that transition lives in application logic the table never sees. Every consumer then re-derives the meaning from raw codes, and every consumer derives it slightly differently.

The second is physical coupling. Raw CDC exposes the physical table structure of the source. That structure is the private raw material of the context that owns it, not a published interface. When the source is upgraded or refactored, the CDC contract breaks, and it breaks silently, discovered by a business user looking at a wrong number rather than by an alert.

The third is unowned ownership. A CDC stream that other domains consume becomes a de facto business contract that nobody agreed to own. There is no versioning, no compatibility guarantee, and no clear source of truth for any field.

What do a CDC event and a business event look like side by side?

The dimensions below are the ones an architect weighs when deciding what may cross a context boundary.

Dimension	Database CDC event	SAP business event (application-layer)
What it carries	A row mutation: before and after values	What happened in the business, in business language
Where the intent lives	In application logic the table never sees	Captured at the point the application knows it
Coupling	To the physical table structure	To a business event definition
Survives an upgrade or refactor	Breaks when the physical schema changes	Less exposed, because capture is above the database
Deletes	A removed row can simply stop appearing	The delete is an event with meaning
Fit as a cross-context contract	Poor: unowned, physical, unversioned	Suited: governed, semantic, versionable
Governance	Re-derived per consumer	Registered schema, compatibility enforced

The table is the argument. A business event is publishable as a contract because it is expressed in terms that do not change when a database administrator reorganizes a table. A raw CDC event is not, because it is the table.

How does SAP actually emit business events?

The common objection is that a monolithic ERP cannot emit clean domain events, so raw CDC is the only option. That is not correct. SAP exposes application-layer extension points designed to be subscribed to.

Onibex OneConnect captures SAP ECC and SAP S/4HANA changes through application-layer business events using four standard SAP frameworks: the RESTful Application Programming model (RAP), the Business Object Repository (BOR), Business Transaction Events (BTE), and the Post Processing Framework (PPF). When one of these fires, the event, together with its SAP data dictionary metadata, is pushed outbound over an HTTP RFC destination of Type G to the OneConnect Smart Gateway, and streamed to Apache Kafka with topics and schema registry subjects created on the fly and schema evolution supported. The mechanism is documented in the open OneConnect documentation.

Two properties of this mechanism matter to an architect. Capture is application-layer, so nothing reads the database and nothing modifies the SAP core, which keeps the approach inside SAP clean core guidance. And the event arrives already carrying business semantics, because it is captured where the intent is known rather than reconstructed downstream from raw codes.

This is the mechanical answer to the "just CDC with marketing on top" objection. There is no Operational Data Provisioning, there are no change pointers, and there is no database-level change data capture on SAP tables. The frameworks named above are the specific proof.

What happens when SAP changes the underlying structure?

The question that decides adoption is what happens when SAP changes.

Because capture is application-layer rather than table-level, the stream is less exposed to physical schema refactoring than a table-level CDC pipeline is. A business event definition does not change every time the underlying storage does.

Where schemas do evolve, evolution is handled at the schema registry. The compatibility mode set on the subject determines what happens when a changed schema arrives, and that behavior is enforced by the registry, not by the capture layer. Versioning an event contract is therefore a registry and contract concern with a defined policy, rather than an accident waiting on the next transport.

A worked example: a sales order is fulfilled

Consider a delivery being posted against a sales order.

A database CDC pipeline observes several row changes across header and item tables. A status character moves from one value to another. A consumer receiving those rows has to know that this particular combination of table mutations, in this order, means the order was fulfilled, and it has to keep knowing that after the next SAP change.

An application-layer business event observes the same posting and emits an event that names it: the order was fulfilled, with the fields that describe it, in business language, keyed on the SAP primary key. Every consumer reads the same governed event. None of them re-derives the meaning, and none of them breaks when the physical tables are reorganized.

Same source change. One approach exports raw material, the other exports a contract.

When is database CDC still the right tool?

CDC is not wrong, it is scoped. Inside the bounded context that owns a data store, for database replication, backup, or migration, CDC is often the correct and simplest choice. The argument here is narrow and specific: raw CDC should not be the contract that crosses a context boundary. Translate it into a governed domain or integration contract before another team depends on it. Choosing between the two is usually the wrong framing. Choosing where each belongs is the right one.

Frequently asked questions

What is the difference between a domain event, an integration event, and a CDC event?

A CDC event reports a database row mutation. A domain event reports something that happened inside one bounded context, in that domain's language. An integration event is the version of a domain event deliberately shaped and versioned for other contexts to consume. CDC is raw material; domain and integration events are contracts.

Can SAP publish domain events natively?

Yes, through the application layer. OneConnect captures SAP ECC and SAP S/4HANA changes using RAP, BOR, BTE, and PPF, and pushes them outbound over an HTTP RFC destination to the Smart Gateway. The events carry business semantics because they are captured where the application knows the intent.

Does OneConnect use ODP or change pointers?

No. OneConnect does not use Operational Data Provisioning, change pointers, database triggers, or log-based change data capture on SAP tables. It captures application-layer business events through RAP, BOR, BTE, and PPF, pushed over an HTTP RFC destination of Type G.

How do you version an SAP event contract without breaking consumers?

Schema evolution is handled at the schema registry, and the compatibility mode on the subject governs what happens when a schema changes. Breaking changes are managed as new contract versions under that policy rather than as silent mutations of the existing one.

What OneConnect does not do

OneConnect does not read the SAP database layer and does not use database triggers, log-based change data capture, or table replication. It does not use Operational Data Provisioning or change pointers. It captures application-layer business events and pushes them outbound over an HTTP RFC destination. Coverage is SAP ECC and SAP S/4HANA, with S/4HANA Cloud Private Edition as the supported cloud target, not S/4HANA Cloud Public Edition. OneConnect does not replace an architect's integration framework; it is a reference implementation component for the SAP source-aligned edge.

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), a semantic-layer specification and platform that grounds AI agents in governed, business-ready SAP data. Onibex is headquartered in The Woodlands, Texas.