A purpose-built extraction layer for SAP S/4HANA — direct HANA SQL, CDS view consumption, OData services, BAPI/RFC bridges. Works on on-prem S/4HANA, RISE with SAP Cloud Private Edition, and S/4HANA Cloud Public Edition. Parquet output, parallel by default, audit-logged for SOX, HGB, BaFin.
Reading data out of S/4HANA is harder than it looks. Source-system constraints, schema complexity, and SAP licensing nuance all push back.
Most data-extraction tools come from a generic 'database connector' tradition — they assume JDBC access, simple SELECTs, and freedom to scale parallelism without source-system constraints. That falls over fast on SAP. RISE with SAP and S/4HANA Cloud forbid direct database access entirely. Even on-prem S/4HANA carries HANA in-memory cost-per-read implications that make naive extraction expensive. CDS views require knowing the right view (there are thousands), at the right level of denormalisation. OData services require understanding SAP Gateway throttling. BAPI/RFC calls require knowing which function module to call for which business object.
Syntra ETL's SAP S/4HANA data extraction tool ships with all of this pre-built. The right interface is auto-selected per object based on what your environment exposes; partition keys are pre-configured per delivered table; rate-limit handling is built in for RISE/Cloud; sensitive-data masking is configurable per field. The tool runs as a sidecar to S/4HANA, not embedded in the ABAP stack — no transports, no developer key, no Basis-team change-control overhead.
Outputs land in cloud object storage as Parquet by default, partitioned by business-meaningful keys (fiscal year + period for finance; year + plant for materials; year + sales org for sales). Downstream consumers — Athena, BigQuery, Snowflake, Spark, Oracle Fusion via FBDI — read partition-pruned subsets without scanning the whole archive.
No discovery sprint to figure out which tables to read. The catalog of delivered objects is pre-built and version-tracked against the current S/4HANA release.
ACDOCA universal journal, BKPF/BSEG legacy journal, T001 company codes, SKA1/SKAT GL master, CSKS cost centres, CEPC profit centres, ANLA/ANLB asset master + values, KOMV pricing conditions.
LFA1/LFB1/LFM1 vendor master, KNA1/KNB1/KNVV customer master, BSIK/BSAK open and cleared AP items, BSID/BSAD open and cleared AR items, PAYR payments, FEBKO/FEBEP bank statements.
MARA/MARC/MARD material master, MBEW valuation, MCHB batch stock, MSEG inventory movements, EKKO/EKPO purchase orders, EBAN/EBKN purchase requisitions, T001W plants.
VBAK/VBAP sales orders, VBRK/VBRP billing, LIKP/LIPS deliveries, KONV pricing conditions, VBEP schedule lines, VBFA document flow.
AFKO/AFPO production orders, MAPL/PLPO routings, STKO/STPO BOMs, EQUI equipment, IFLOT functional locations, IFLO maintenance plans, QMEL notifications.
HRP1000/HRP1001 organisational management, PA0001/PA0008/PA0014 personnel administration master, PCL2 payroll cluster — typically only on customers with SAP HCM still on S/4HANA, rare given SuccessFactors migration.
Configure once, schedule, monitor. The same flow used by Syntra ETL customers for migration, archival, and ongoing data warehousing.
Tool inspects the S/4HANA environment: tests HANA DB connectivity, queries CDS view catalog, probes OData service endpoints, lists Z*/Y* custom tables in TADIR. Output: a list of extractable objects with the best available interface per object.
Pick objects to extract, set partition keys (typically auto-selected from the recommended defaults), set parallelism (default 8 workers per object), set output destination (cloud bucket + path pattern), set retention and masking rules.
SAP basis or BTP admin provisions the required user (HANA DB user with SELECT on customer schemas, or CDS view consumer role, or OData service authorisation). Sample auth profiles documented for each access pattern.
Run extraction with row-count cap (e.g. 10,000 rows per object) to validate connectivity, schema, masking, and downstream partition layout. Catches misconfiguration before a multi-hour full extract starts.
Full extract runs to completion. Progress streamed to a job dashboard. On failure, restart picks up from the last completed partition — no wasted work.
Per-partition manifest (row count, sum totals, hash signature) generated. Signed audit log issued. Output ready for downstream consumption (FBDI generation, archival, warehousing).
Extracting 4 billion rows of BSEG is different from extracting 4 million.
Direct HANA SQL: 100K–500K rows/sec per worker, scaling near-linearly to 16 workers. CDS views: 30K–100K rows/sec per worker (gateway-mediated). OData: 5K–20K rows/sec per worker (REST overhead).
Per-partition checkpointing. On failure (network blip, HANA backup window, transient auth issue) the next run picks up at the failed partition. No re-extraction of already-completed work.
Per-field masking rules (SSN, bank account, salary, customer PII) applied during extract before data ever lands in Parquet. Optional pseudonymisation for non-production downstreams.
After initial bulk extract, scheduled incremental runs use CDPOS/CDHDR change documents, ACDOCA timestamp watermarks, or SLT replication output to capture only new/changed rows.
Every extraction operation logged with user, timestamp, object, row count, sum, hash. Immutable storage. SOX / German HGB §147 / BaFin grade evidence.
Dashboard shows progress, throughput, rows/sec, errors, retries. Alerts on SLA breach, partition skew, or unexpected source-side schema drift (column added/removed).
An SAP S/4HANA data extraction tool reads data out of the S/4HANA stack — through HANA SQL, CDS views, OData services, or BAPI/RFC — and writes it to a destination (typically cloud object storage, a data warehouse, or downstream applications) without disrupting the source system. Alternatives include SAP Data Services (BODS — heavy, ABAP-stack-dependent), SAP Datasphere / SAC Live Data (good for cloud reporting but not bulk extraction), SLT (real-time but operationally complex), and home-grown ABAP downloads (brittle, slow, no governance). Syntra ETL is a purpose-built extraction layer with pre-configured table-and-view definitions for every delivered S/4HANA object, parallelism out of the box, Parquet output, and zero ABAP-stack footprint.
All four: direct HANA SQL (highest throughput, requires HANA DB user on on-prem or BTP-private S/4HANA), CDS views (the strategic SAP-blessed access layer for RISE and Cloud editions where DB access is locked down — thousands of pre-built I_* and C_* views), OData services (cloud-RESTful access via SAP Gateway, ideal for incremental and event-driven extraction), and BAPI/RFC (legacy access where CDS coverage gaps exist or for specific function-module driven extractions like HR-PA). For each table or business object, Syntra ETL automatically picks the highest-throughput available interface for your environment, with config override if you have policy reasons to prefer one over another.
S/4HANA Cloud Public Edition allows no direct HANA database access — extraction must use the SAP Cloud APIs. Syntra ETL targets the published CDS view catalog (I_* and C_* views are documented in the SAP API Business Hub) and the OData services exposed through SAP Gateway. For RISE with SAP Cloud Private Edition, the situation is similar but with more flexibility: some customers have CDS view access, some have OData-only, very few have HANA DB access. Syntra ETL auto-detects the available interfaces during the discovery phase and configures the extraction layer accordingly. Throughput is lower than direct HANA SQL but completely production-viable for migration, archival, and analytical use cases.
Yes. Custom tables (Z*/Y* tables in the ABAP dictionary, registered in TADIR) are auto-discovered during the inventory phase and added to the extractable-object catalog. CDS view extensions (custom views, view extensions on standard SAP views, ABAP Cloud CAP services) are similarly discovered via the CDS catalog metadata. Extraction config for custom objects is generated automatically — Syntra ETL reads the data-dictionary definition (column names, datatypes, key fields), constructs the extraction SQL or OData query, and stages output to Parquet with the schema preserved. Custom objects participate in the same reconciliation, hashing, and audit-log workflow as delivered tables.
Default output is Parquet — columnar, compressed, schema-embedded, optimal for downstream query (Athena, BigQuery, Snowflake, Spark) and for long-term archival storage. Optional outputs include CSV for legacy consumers, JSON for document-store destinations, and direct loading into Oracle Fusion via FBDI/HDL/REST for migration use cases. The Parquet output is partitioned by configurable keys (typically fiscal year + period + company code for FI tables; year + plant for MM tables; year + sales org for SD tables) so downstream consumers get partition-pruning performance automatically.
Each extractable object has a natural partition key (RBUKRS company code for ACDOCA, BUKRS for BKPF, MANDT + WERKS for MARC, etc.). The extraction engine splits the source range across N parallel workers, each pulling a non-overlapping partition, hashing rows as they're read, and writing to its own Parquet shard. The reconciliation engine then validates that all shards together cover the expected range (no gaps, no overlaps) and that row-count and sum-total invariants hold. Typical parallelism is 4–16 workers per object; throughput scales close to linearly until either the HANA source becomes the bottleneck or the output object store does. For RISE/Cloud where API rate limits exist, parallelism is auto-throttled to respect SAP's published thresholds.
Configurably, no. Three controls limit impact: (1) read-only HANA user or CDS-view-read-only authorisation, so no write contention is possible; (2) configurable concurrency limits and statement timeouts so HANA workload management can prioritise online users; (3) optional scheduling against a HANA system-replication secondary (HSR-active or HSR-readable) for zero impact on the primary. For RISE-hosted S/4HANA where customer Basis access is restricted, throttling is managed via API rate limits and time-window scheduling. Customers routinely run multi-terabyte extracts during business hours with no detectable impact on online TPS.
Every extraction operation produces a signed audit log: timestamp, source system, object extracted, row count, sum totals, hash of result-set, identity of the requesting user/service. Logs are immutable, retained per configurable retention policy, and exportable as evidence packs. For SOX, the audit log proves data lineage from S/4HANA to downstream system. For German HGB/AO §147 retention, the extraction log proves the archive was a true and complete copy at extraction time. For BaFin in regulated financial services, the audit log proves no unauthorised modifications were possible during extraction. Auditors typically sign off on the extraction process itself after seeing one full run-through, then sample-test subsequent runs.
30-minute call. We'll show the extractor connecting to your S/4HANA environment (on-prem, RISE, or Cloud), running a smoke-test extraction, and producing Parquet output ready for downstream consumption.