Technology
Inside SAP, Not Outside.
DataXover runs as native ABAP inside your SAP system — not middleware calling from outside. Direct access to the data dictionary, change documents, and transactional data. No RFCs. No BAPIs. No bottlenecks.
Architecture
Push-based. Outbound only.
Three components. One direction.
All communication is outbound HTTPS from SAP. Data files upload to cloud object storage via time-limited presigned URLs. No inbound firewall rules. No persistent storage credentials in SAP.
Extraction Profiles
Profile-driven. No custom ABAP.
Define what you want — tables, fields, filters, schedule. The transport reads directly from your SAP data dictionary. No guessing at field names. No custom development.
Background jobs only. Dialog work processes untouched.
Large Table Seeding
The table that couldn't be extracted. Until now.
Certain SAP objects contain billions of records. BSEG — accounting document line items — is the canonical example. A single SELECT against BSEG in a mature system will time out, consume dialog work processes, and get killed by your Basis team.
DataXover seeds large tables differently.
Cursor-based chunking opens a database cursor and reads records in configurable package-sized chunks. Each chunk writes to a single compressed file on the application server file system. The next chunk. The next file. Until the entire object has been read.
The files are the work queue. Every file is individually tracked. If the process stops at file 134 — restart from file 130. Reprocessing uses upsert logic — no duplicates. Nothing is lost.
Seeding doesn't require a single uninterrupted execution window. Run during your maintenance window. Pause. Continue tomorrow. The system knows exactly where it left off.
Concurrent delivery means completed files begin uploading to the target database while extraction is still running. The execution engine creates the landing table from the first file. All subsequent files load as inserts. Your destination starts receiving data before SAP-side extraction finishes.
When the last file lands, CDC takes over. Automatically.
The table that couldn't be extracted is in your data warehouse.
Change Data Capture
Change data capture the way SAP intended.
DataXover CDC uses SAP change documents — CDHDR and CDPOS. SAP's native application-layer audit trail. When users modify business objects, SAP writes change documents. DataXover reads them. Creates, updates, and deletes — exactly as SAP recorded them, at the moment the business transaction posted.
Not database transaction logs. Not inferred changes. The authoritative record.
If a table doesn't generate change documents natively, your Basis team enables it via SCDO. Standard SAP functionality. No customization required.
Why not database-level CDC?
Database-level CDC tools sit outside the SAP application layer. They read transaction logs. They can tell you a row changed. They cannot tell you what business event caused it, who initiated it, or what it means in SAP context. SAP is also database-agnostic — the same system might run on HANA, Oracle, SQL Server, or DB2. Database-level CDC has to handle each differently.
DataXover reads what SAP wrote. That's the difference.
Destinations
Your data, your destination.
The engine handles schema creation, type conversion, and incremental loading automatically.
Landscape Refresh Protection
PRD to QAS. Handled.
SAP customers routinely copy production systems to lower environments for testing. Without safeguards, a refreshed QAS environment could begin sending stale or test data to production ISV destinations — corrupting live data flows.
DataXover detects system identity mismatches when a refreshed environment attempts to communicate with the SaaS coordination layer. The mismatched environment is automatically locked down. Production data flows are protected before anyone realizes the refresh happened.
Compatibility
Works on your system.
See it running.
One conversation. We'll walk you through the technology on a real SAP system.