Real questions from real SAP teams.

DataXover ships as a standard SAP transport request. Import through STMS like any other transport. Promote through DEV → QAS → PRD using your standard change management process. No special installation procedure, no scripts, no manual steps outside of SAP.

ABAP 7.40 (SAP ECC 6.0 EhP7) and above. S/4HANA all releases.

Yes. Same transport, both platforms. Fully compatible with SAP ECC 6.0 EhP7 (ABAP 7.40) and all S/4HANA releases.

No. Runs on ECC with any supported database backend — Oracle, SQL Server, DB2, MaxDB, HANA. The SAP-side database is irrelevant to the extraction process.

No. DataXover communicates with its own SaaS coordination layer via outbound HTTPS. No BTP dependency, no SAP cloud services required.

/SDN/ — all repository objects use the registered /SDN/ namespace.

Yes. DataXover detects the SID/client mismatch when a refreshed environment attempts to connect and automatically locks down the copied system. It will not send data to production destinations from a refreshed lower environment.

No. Clean installation with no SAP system parameter modifications.

Six custom authorization objects in the /SDN/ namespace: /SDN/PROF (profile management), /SDN/REVW (profile review and QA approval), /SDN/BASI (Basis technical approval), /SDN/JOBS (job activation and monitoring), /SDN/ADMN (system administration), /SDN/PROD (ISV product management — ISV landscapes only). Five standard roles delivered with the transport. The two-stage governance workflow enforces separation of duties by design.

Yes — approximately 20 repository objects in the /SDN/ namespace covering profile configuration, scope data, job status, and audit logging.

No. DataXover uses native cursor-based reads in background work processes through the standard ABAP database interface. RFC_READ_TABLE is dialog-bound, width-limited, and was flagged by SAP themselves as not for productive use (SAP Note 382318). By bypassing it entirely for native cursor reads, DataXover gets the performance of direct table access without touching any restricted or discouraged SAP interface. The same architectural decision that makes it fast is the one that keeps it entirely outside the API surface affected by SAP Note 3255746.

No. Note 3255746 restricts third-party use of ODP Data Replication APIs via RFC. DataXover does not use ODP. It does not call any ODP function modules. It reads SAP tables through the standard ABAP database interface using cursor-based SELECT in background work processes, and reads change documents through CDHDR/CDPOS. SAP's own Version 11 of the note explicitly clarifies the safe-harbor boundary: RFC as a general protocol is fine, standard table extraction is fine, BAPIs and function modules are fine. Only ODP-RFC is restricted. DataXover operates entirely within the boundary SAP defined. There is no SAP-owned API surface to restrict, no proprietary entry point to revoke, and no call to validate against. For full context, see our SAP Note 3255746 analysis.

DataXover installs in its own namespace (/SDN/) and does not modify SAP standard objects. No enhancements, no user exits, no modifications to standard code. It runs as self-contained ABAP within the customer's transport landscape, fully removable through standard STMS processes. Already aligned with Clean Core principles.

No. DataXover runs exclusively as background jobs. Dialog work processes are untouched. Your users will not feel it.

Background (batch) work processes only. Controlled via standard SAP background job management — SM36/SM37.

One per active extraction job. Configure concurrency to fit your available background WP headroom.

DataXover uses cursor-based chunked reads with configurable package sizes. No unbounded SELECT statements against large tables. Control chunk size, schedule, and concurrency to fit your system's capacity. Designed to run alongside production without impacting end users.

Jobs restart cleanly. For CDC, the watermark is maintained — the next run picks up from the last successful point. For seeding, the file system state tracks completed files — the job resumes from the next unprocessed file.

Full scheduling flexibility — frequency, run windows, priority. Run CDC every 15 minutes during business hours, less frequently overnight. Run seeding jobs during maintenance windows only.

Yes. This was a design requirement. BSEG in a mature SAP system can contain billions of rows. DataXover handles it through cursor-based chunked extraction — configurable package size, no single unbounded SELECT, no timeout, no work process saturation, no Basis intervention required.

Every compressed file is individually tracked. If the job abends at file 134, restart from file 130 or any prior point. Delivery uses upsert logic — records already delivered are safely overwritten with identical data. No duplicates. Nothing is lost.

Depends on table size, column count, package size, and hardware. On a decade-old single-instance AWS server, DataXover extracted 30 million records across three concurrent tables in under 15 minutes. S/4HANA benchmarks on current AWS infrastructure are in progress — results published when available.

Yes — explicitly designed for this. Run during your maintenance window, pause, pick up the next night. Progress is never lost between runs.

The object automatically transitions to CDC. DataXover captures a timestamp at the start of seeding. When the last file is delivered, CDC picks up from that timestamp. No changes during the seeding window are lost. No manual switchover required.

Yes. Extraction and delivery run concurrently. The execution engine creates the landing table from the first file and processes subsequent files as inserts. Your destination starts receiving data before SAP-side extraction finishes.

DataXover CDC uses SAP change documents — CDHDR and CDPOS. SAP's native application-layer audit trail. Creates, updates, and deletes — exactly as SAP recorded them at the moment the business transaction posted.

Your Basis team enables change document tracking via SCDO — standard SAP functionality, no customization required.

Database-level CDC reads transaction logs outside the SAP application layer. It can tell you a row changed. It cannot tell you what business event caused it, who initiated it, or what it means in SAP context. SAP's business logic lives in ABAP — not in database logs. DataXover reads what SAP wrote.

Configurable. No platform-imposed minimum. Run every 5 minutes, every 15 minutes, hourly — whatever fits your use case and system capacity.

Yes — where SAP records them. Change document tracking captures deletes on objects where SAP writes change documents for deletion events. For objects using logical deletion (LOEKZ, LVORM, and similar deletion flags), the flag change is captured as an update — consistent with SAP's own data model. Hard deletes on tables without change documents require SCDO enablement first.

Yes. The engine handles deduplication on the destination side automatically.

Yes. All communication between the SAP Application Suite and the SaaS coordination layer is outbound HTTPS. Data files upload to cloud object storage via time-limited presigned URLs.

No. The SAP system initiates all connections via outbound HTTPS. Nothing reaches inbound into SAP.

Target database credentials are managed in the SaaS coordination layer — not stored in SAP configuration tables. Encryption keys and HMAC keys are managed through AWS KMS, retrieved via API at extraction time, used in memory, and never persisted to the SAP system. Anyone with SE16 access cannot read your keys — they are not there.

Only what you configure. Nothing extracts without an active, approved profile. OneScope computes the precise dataset inside SAP before extraction runs.

Yes — six protection modes per field, enforced inside SAP at extraction time. The destination receives data already in its protected state. No pipeline window where raw sensitive values exist outside SAP.

Yes. Every extraction, every profile activation, every consent, every termination logged with timestamp and user.

The platform provides compliance-gated data movement control for any data flow — domestic, international, or B2B. Compliance instruments (certificates, attestations, agreements) are managed externally and referenced through Packs — ordered collections of instrument references. All instruments in a Pack must be valid for data to flow. Two gates enforce this: a configuration-time gate blocks extraction setup until a compliance-authorized user assigns appropriate Packs, and a runtime gate validates instrument status before every extraction.

Both. The system is transfer-type agnostic. Tenant configuration determines which flows require compliance gating. A domestic transfer between two business units can be gated the same way an international transfer is. The compliance module applies wherever the tenant enables it.

The runtime gate catches it. Before every extraction, the ERP Application Suite calls the SaaS Coordination Layer with the profile's assigned Pack identifiers. The SaaS evaluates current instrument status against tenant expiration policy and grace period configuration, returning one of three verdicts: proceed, warn, or block. If an instrument has expired beyond the configured grace period, extraction is blocked automatically. No manual intervention required.

Only compliance-authorized users. When a destination is assigned to a profile, the profile enters a compliance queue on a dedicated, role-gated screen. The compliance user reviews Packs matched by the SaaS Coordination Layer based on country pair and metadata tags, then assigns the appropriate Packs. This is separated from profile authoring and Basis technical approval — different roles, different screens, different authorization objects.

Assign the Bypass Pack. Pack 0 contains zero instruments and represents a controlled, auditable declaration that no compliance coverage is required for this flow. It is mutually exclusive with all other Packs on a given profile — you either have compliance instruments assigned or a documented bypass, never both and never neither. The bypass is logged the same way any other Pack assignment is.

Both systems. Every data file carries a compliance metadata object — Pack identifiers, verdict, action, and validation timestamp — in its accompanying metadata record within the ERP Application Suite. The same metadata is stamped on the SaaS upload record. Point-in-time proof of compliance status exists in both systems without requiring a live cross-system query. An auditor can verify what compliance coverage was in place for any specific data file at the time it was extracted.

DataXover does not maintain an authorization-based table restriction list. Table selection is governed through the profile review workflow — QA content review and Basis technical approval — where your own team evaluates whether the proposed extraction is appropriate before it activates. The audit trail records every profile, every reviewer, every approval, and every activation. Accountability is complete and traceable.

Currently tested and supported: Snowflake, PostgreSQL, SQL Server, MySQL, Oracle, Amazon Aurora (RDS). Additional destinations via JDBC adapter.

The execution engine creates the landing table from the first file delivered. Schema must be configured by the customer or ISV. Table creation is handled automatically.

SAP-to-target type conversion handled automatically. No known edge cases — standard SAP type mapping handles all cases cleanly.

Yes. Each data provider receives a dedicated schema. Schema names configured by the ISV in the destination setup. Complete isolation between tenants.

A lightweight process that sits on the same network as your target database. Receives work items from the SaaS coordination layer, retrieves data files from cloud object storage, and loads them into the target database. Handles connection pooling, parallel bulk operations, and concurrent job coordination.

Wherever your target database is — on-premises, in your cloud environment, or in a partner's infrastructure.

The execution engine is intentionally lightweight — it has been validated on decade-old infrastructure. Minimum requirements are modest; exact specs provided during onboarding.

No. The engine never communicates directly with SAP. It receives processed data files from cloud object storage only.

Three steps: install the transport, deploy the engine, configure profiles. No months-long implementation project. No custom ABAP development.

A technically prepared customer can go from initial setup to data flowing the same day. From SaaS account creation through transport installation, connectivity configuration, and first profile activation — under an hour for an experienced SAP team.

Job status, extraction history, file delivery status, and error logs visible through the Admin Console transaction. Standard SAP background job monitoring (SM37) works as expected. The SaaS portal provides a cross-system view for organizations running multiple SAP landscapes.

Job logs the error with detail, reports failure to the SaaS coordination layer, and stops. Next scheduled run attempts from last successful watermark (CDC) or last completed file (seeding). No silent failures.

Alerting is currently dashboard-based in both the SaaS portal and SAP Admin Console. Email and SMS notifications are on the roadmap.

Minimal. ABAP transport updated via standard SAP transport import when new versions release. Engine updates handled server-side. Profile configuration is ongoing as your extraction requirements evolve — but the platform itself requires little maintenance once running.