Change Data Capture

SAP knows what changed.
We read what it wrote.

CDC at the database layer sits outside SAP and infers what happened from transaction logs. DataXover reads the source SAP wrote — change documents that record exactly what changed, who changed it, when, and in what business context.

That's not a technical distinction. That's the difference between knowing and guessing.

The Problem

Database logs tell you a row changed. They don't tell you why.

Log-based CDC tools work at the database layer. They sit outside your SAP system and read database transaction logs — redo logs, transaction logs, depending on your database backend.

When a sales order is modified in SAP, the database log records that rows changed in VBAK, VBAP, and possibly a dozen other tables. It records the before and after values. It does not record what business event caused it. It does not record which SAP user initiated it. It does not record the business context that SAP tracks natively.

SAP is database-agnostic.
The same SAP system might run on HANA, Oracle, SQL Server, or DB2. Database-level CDC tools have to handle each differently — different log formats, different access methods, different behaviors. The tool that works on your Oracle-backed ECC system may behave differently when you migrate to HANA. DataXover doesn't care what database SAP runs on. It operates above the database layer entirely.
SAP's business logic lives in ABAP, not in database logs.
A change document in CDHDR/CDPOS tells you that a sales order was changed, which fields changed, who made the change, when, and the business context. A database log tells you rows changed. These are not the same thing. One is a business event. The other is a storage event.
BSEG isn't what it looks like at the database layer.
In SAP ECC, BSEG is a cluster table — SAP packs multiple logical records into single database rows and unpacks them at the application layer. A database-level CDC tool reading BSEG sees packed cluster data, not the business records SAP presents to the application. In S/4HANA, SAP converted BSEG to a transparent table (ACDOCA) — the cluster problem goes away, but the table is even larger because it holds the complete universal journal. Either way, database-level CDC tools are reading at the wrong layer. DataXover reads at the application layer through standard ABAP, where the unpacking is already done on ECC and the transparent table is accessed natively on S/4HANA.

How It Works

SAP has been writing change documents since the beginning. We read them.

When a user modifies a business object in SAP — a sales order, a vendor master, a material record, a financial posting — SAP writes two records:

CDHDR — Change Document Header
Object class, object ID, transaction code, user name, date, time. The who, what, and when of the business event.
CDPOS — Change Document Item
Table name, field name, change indicator. Pinpoints exactly which records and fields changed since the last run.

SAP has maintained this audit trail across every release, every database backend, every deployment model. It is the authoritative record of what happened in the system — written by SAP at the moment the business transaction posted, before any downstream system sees the data.

DataXover reads SAP's change documents (CDHDR/CDPOS) to identify which records changed since the last extraction run, retrieves the current state of those records, and delivers them to your destination with insert/update/delete flags. Your destination stays current. Your SAP system is not burdened with continuous extraction of unchanged data.

This is change data capture the way SAP intended — read from SAP's own change record, not inferred from database transaction logs.

Coverage

What about tables without change documents?

Most SAP business objects generate change documents natively. Sales orders, purchase orders, vendor master, customer master, material master, financial documents — the objects that matter most for analytics generate CDHDR/CDPOS records automatically.

Coverage is extensible with standard SAP techniques. For custom tables, define a change-document object in transaction SCDO; it generates the write function module, and your update routine calls it where the table is written — a few lines in code you already own, delivered by normal transport. For standard tables without native change documents, the same generated call is placed in an enhancement point, BAdI, or user exit in the save path. Nothing logs on generation alone: the call at the write point is what turns it on.

Where wiring change documents isn't wanted, date-based delta extraction or scheduled full extraction is always available. DataXover handles both modes from the same profile configuration.

Operations

Background jobs only. Your users won't feel it.

Configurable frequency. No platform minimum.
Run every 5 minutes, every 15 minutes, hourly — whatever fits your use case and your system's available background work process capacity. The schedule is yours to set and adjust at any time.
Watermark-based. No gaps. No duplicates.
DataXover maintains a high-water mark for each CDC profile. If a job fails or the system goes down, the next run picks up from the last successful point. No changes are missed. No records are processed twice.
Automatic transition from seeding.
When a large table seeding job completes, CDC starts automatically. DataXover captures a timestamp at the start of seeding — when the last file is delivered, CDC picks up from that timestamp. No manual switchover. No gap in the change record.
Full audit trail.
Every CDC run — records processed, changes detected, delivery status, elapsed time — logged automatically. The audit trail your compliance team needs, generated without additional configuration.

The Architectural Difference

Two architectures: read the database's logs, or read what SAP wrote.

This isn't a feature comparison. It's an architectural difference that matters in SAP environments specifically.

Log reading is a sound architecture for databases that expose change semantics in their transaction logs. SAP's change semantics live in the application layer, and that is where DataXover reads.

DataXover was built from the ground up for SAP. CDHDR and CDPOS aren't an integration — they're the foundation. The architecture that makes DataXover CDC work is the same architecture that makes everything else work. It's not bolted on. It's how the platform thinks.

Change data capture built for SAP.

Not adapted for it. Built for it.

Request Consideration Explore the technology