The SAP Extraction Guide

Two events reshaped this landscape, so start with them. First, the SAP–Databricks partnership: announced February 13, 2025 under SAP Business Data Cloud, with BDC Connect for Databricks reaching general availability on October 6, 2025 — zero-copy Delta Sharing of SAP data products into any Unity Catalog workspace on AWS, Azure, or GCP. Second, SAP Note 3255746: SAP's position that the ODP-RFC interface is exclusively for SAP-to-SAP transfer became a technical block on the June 9, 2026 patch day — breaking the ODP-RFC-based connectors most SAP extraction estates were built on.

That leaves five path families worth evaluating. Which one fits comes down to four questions: whether you already have BDC or Datasphere in the estate, whether you need raw tables at your chosen grain or curated data products, how fresh the data must be, and what you're willing to license.

As of August 2026 there is no first-party Databricks Lakeflow Connect connector for SAP raw tables — Databricks' first-party SAP path is BDC Connect, covered next. Everything below is vendor-neutral: the goal is to know what each path actually lands so you can evaluate against your estate, not to sell any of them.

Two similarly named things shipped from the partnership, and it pays to keep them apart. SAP Databricks is an embedded, SAP-sold Databricks capability that runs inside the Business Data Cloud tenant itself. BDC Connect for Databricks is the one this guide cares about: a bi-directional, live, zero-copy Delta Sharing connection between a BDC tenant and your own Databricks workspace — the data stays in place on either side and is shared, not copied. Prerequisites are a BDC subscription and a Unity Catalog-enabled workspace; the Databricks BDC Connect documentation and the SAP Architecture Center reference cover the setup from each side.

The honest caveat: what arrives are curated data products, not raw tables at your chosen grain. Coverage is the SAP-defined catalog — browsable in the SAP Business Data Cloud catalog — and a data product is a governed, semantically modeled shape SAP chose, not the transaction-grain material movements or order lines this reference documents table by table. For finance and standard-shaped analytics that's often exactly right; for detailed supply chain facts it complements rather than replaces the raw-table paths below. If you have BDC, treat BDC Connect as the first path to evaluate — and expect to pair it with a table-grain path for the facts the catalog doesn't cover.

Replication flows with premium outbound integrationare SAP's own way to push table-grain data out of S/4HANA or ECC, through Datasphere, into an object store you control — ADLS Gen2, S3, or GCS. The flow handles initial load plus delta capture, and lands files you then register or Auto-Load into bronze like any other cloud-storage source. Landed files are Parquet or CSV depending on configuration; whether a native Delta output is available for your target is release-dependent, so check the current Datasphere release notes rather than assuming either way.

Name the cost model plainly, because it surprises people: premium outbound is capacity-metered. Per SAP's premium outbound documentation, outbound volume is metered in blocks of 20 GB, paid for in Datasphere capacity units — so a full historical load of a large transaction table is a real, budgetable cost, not a rounding error. SAP has adjusted the capacity-unit price per block over time; verify current rates before you size a backfill.

The fit: estates already invested in Datasphere or BDC that need table-grain replication with delta handling and would rather pay SAP metering than stand up a third-party tool. If you have neither, weigh this path's subscription prerequisite against the CDC tools below before committing.

Operational Data Provisioning (ODP) is the framework a decade of SAP extraction was built on: BW extractors and CDS views expose delta-capable feeds through an operational delta queue, and a subscriber replays inserts, updates, and deletes from it. ODP has two transports — ODP-RFC, the fast binary protocol nearly every third-party connector used, and ODP over OData, the API SAP releases for third parties.

SAP Note 3255746 states that the RFC modules of the ODP Data Replication API are designed exclusively for data transfer between SAP applications — use by customer or third-party applications is not permitted. On the June 9, 2026 patch day that position became technical enforcement: a security patch validates incoming ODP-RFC calls against allowed subscriber types and actively blocks unauthorized callers. There is a time-limited fallback — SAP Note 3731818, published the same day, provides an opt-out report that lets the blocked calls continue at your own risk — but it expires in December 2026, and SAP has said a follow-up note will permanently disable it. As of August 2026 no extension has been announced. Treat the opt-out as migration runway, not a plan.

What this broke, concretely: Azure Data Factory's SAP CDC connector, which rides ODP-RFC — Microsoft has pointed toward ODP over OData and Fabric-based alternatives such as Mirroring for SAP Datasphere; Fivetran's ODP-based SAP connectors, with OData-based replacements in progress; Qlik Replicate's SAP ODP endpoint and Talend's ODP components, per Qlik's own advisory; and Informatica's ODP-based connectors. In every case, check the vendor's current migration guidance rather than this page — it is the fastest-moving content here.

The permitted transport comes with a performance reality: in Microsoft's own engineering guidance on the ADF connector, ODP over OData is roughly 10x slower than ODP-RFC — which is why simply re-pointing a high-volume pipeline at OData is rarely the answer, and why the table-level CDC paths in the next section matter.

The table-level paths don't ride ODP-RFC, which is why they came through June 2026 intact. SLT— SAP Landscape Transformation Replication Server — is SAP's trigger-based replication: an SAP-licensed product, squarely permitted as SAP-to-SAP transfer, and commonly deployed as the SAP-side front end that third-party pipelines land from. Note that replicating to non-SAP targets generally requires a full SLT license rather than the runtime edition bundled with other SAP products — one for the licensing section below.

Third-party tools read tables directly or through released interfaces: Fivetran in its non-ODP modes, Qlik Replicate in log- or trigger-based modes, SNP Glue, and Theobald Xtract Universal— whose Table, Table CDC, DeltaQ, OHS, BAPI, and Query components sit outside the ODP-RFC block per Theobald's own compliance guidance — plus the broader family of ABAP add-on tools installed in-system.

The vendor-neutral rule: evaluate on delta capture, delete capture, and cluster/pool-table handling, not logos. A tool that only does full loads rebuilds your biggest tables nightly; one that misses deletes leaves bronze counting documents SAP no longer has; one that can't unpack cluster tables can't read the parts of ECC that still use them. All of these paths land raw tables — which is exactly what analytics wants, and exactly what makes the licensing section below worth reading.

Whichever path you take, the landing convention is the same: point a Unity Catalog external location at the container your extracts arrive in, register the landed data, and expose it as a bronze schema — the raw, source-aligned layer you build silver and gold on. The <catalog>.<schema> placeholders in every boilerplate snippet on this site are meant to point at exactly that bronze layer.

The safe incremental load is two steps. First dedup each incoming batch to one row per primary key, keeping the latest change by your feed's watermark. Then MERGE into bronze, translating the delete signal into a physical DELETE so removed documents actually leave the table. What those columns are called depends on the path: ODP feeds carry ODQ_CHANGEMODE, SLT adds an operation flag, and most third-party tools write their own _operation / _extracted_at columns — there is no universal name, so the skeleton below leaves both as placeholders. It targets MSEG keyed on MANDT, MBLNR, MJAHR, ZEILE.

-- Incremental upsert from a staged extraction batch into a bronze Delta table.
-- The watermark and delete-signal columns depend on your extraction path:
-- ODP feeds carry ODQ_CHANGEMODE, SLT adds an operation flag, and most
-- third-party tools write their own _operation / _extracted_at columns —
-- substitute yours for the placeholders below. Dedup on the material-document
-- key keeping the latest row, then MERGE — turning the delete signal into a
-- physical DELETE so removed documents actually leave bronze.
MERGE INTO <catalog>.<schema>.MSEG AS tgt
USING (
  SELECT * FROM (
    SELECT *, ROW_NUMBER() OVER (
      PARTITION BY MANDT, MBLNR, MJAHR, ZEILE
      ORDER BY <watermark_column> DESC
    ) AS rn
    FROM <catalog>.<staging_schema>.MSEG
  ) WHERE rn = 1
) AS src
ON  tgt.MANDT = src.MANDT
AND tgt.MBLNR = src.MBLNR
AND tgt.MJAHR = src.MJAHR
AND tgt.ZEILE = src.ZEILE
WHEN MATCHED AND src.<delete_flag> = true  THEN DELETE
WHEN MATCHED AND src.<delete_flag> = false THEN UPDATE SET *
WHEN NOT MATCHED AND src.<delete_flag> = false THEN INSERT *

The mechanics above are generic; the traps are per-domain, and the modeling guides document them in their Extraction & CDC reality sections. Two examples worth internalizing before your first S/4HANA extract: material documents moved from MKPF/MSEG into the single MATDOC table — the classic names still answer reads through compatibility views, but a CDC feed should follow the physical table — and the stock quantities in MARD and MCHB are no longer persisted in S/4HANA, so replicating those physical tables freezes the numbers (see the inventory guide). The other three cover deliveries like LIKP being updated and deleted in place (deliveries), status flips on JEST that snapshot-diff loads miss (production orders), and late-arriving usage decisions that keep already-reported acceptance rates moving (quality). The financial single source of truth, ACDOCA, is append-heavy and high-volume — size your watermarking for it.

Three things to flag — flagged, not advised. First, SAP treats interface usage rights as contractual, not just technical: Note 3255746 is the clearest recent example of an interface that worked for years being declared out of bounds and then enforced. Second, raw table replication can intersect SAP licensing concepts — indirect or digital access among them — in ways that depend entirely on your contract, not on the tooling. Third, the rule this guide actually endorses: involve whoever owns your SAP license before standing up a new extraction path. This page documents mechanics; it is not legal or licensing advice.