The SAP EWM Extraction Guide

The first fork here is not a tool, it is a deployment. Ask which EWM you have before you evaluate a single connector, because the answer changes what the extraction target physically is.

Embedded EWM runs inside the S/4HANA system, on the same database. The warehouse tables this reference documents sit beside the ERP tables you already extract — the same client column, the same estate, the same tooling, the same landing pipeline. There is no separate system to connect to; extracting EWM is a table-selection exercise on a source you have already solved.

Decentralized EWMis its own S/4HANA system with its own database, connected to the ERP over interfaces. Nothing about it is exotic — the same path families apply — but they must be pointed at the EWM system, they need their own connection, credentials, and Basis conversation, and the master data flowing between the two systems creates a source-of-truth question your lakehouse has to answer deliberately. SAP's own deployment-options article (opens in new tab) is the plainest statement of the two postures.

Everything below forks on that row. The two middle sections take the deployments one at a time; the CDS, CDC, and landing sections apply to both.

If EWM is embedded, you do not have an EWM extraction problem — you have an S/4HANA extraction problem with a longer table list. The path families, their trade-offs, and the June 2026 ODP-RFC block that reshaped them are documented once, on the SAP extraction guide: Business Data Cloud and BDC Connect, Datasphere premium outbound, ODP and SAP Note 3255746, and table-level CDC. Same estate, same tools, same Note 3255746 exposure — the mechanics are not restated here, and if you are choosing a path, start there.

Three things are EWM-specific once the path is chosen. First, table selection: this catalog is the pick list. The warehouse layer is not covered by the ERP tables an inventory or deliveries extract already lands, and the joins that make it analytically useful — bins to structure, tasks to orders, stock to the product bridge — are documented table by table here.

Second, namespaced object names at the replication tool. EWM table names carry a leading namespace — /SCWM/LAGP is a legal SAP table name and an illegal identifier in most targets. Replication tools differ in how they handle that: some rename cleanly, some reject the object, some mangle the name in a way you only discover downstream. Test your tool against one namespaced table before you commit a design around it, and settle the landing convention up front (see namespaced names in a lakehouse).

Third, the sharper version of the same problem: a handful of COLUMNS carry namespaces too. The inbound and outbound processing item tables in this catalog have a warehouse-number column named /SCWM/WHNO — a slash inside a column name, which many tools rename and some quietly drop. Check your landed schema against the field lists here rather than assuming a column arrived because the table did.

A decentralized warehouse is a separate S/4HANA system, so point the same path families at that system rather than at the ERP. Everything on the SAP guide still applies; what changes is that you now run two extraction estates and have to reconcile them.

Master data is where that reconciliation starts. Materials are distributed from the ERP system to EWM over ALE IDocs (the classic MATMAS message), and business partners over the Data Replication Framework (DRF). This is worth stating plainly because an older assumption still circulates: it is notCIF. The Core Interface belongs to the legacy SCM-stack deployment; S/4HANA-based decentralized EWM uses the ALE and DRF mechanics described in SAP's Integration of SAP ERP or SAP S/4HANA with Decentralized EWM in SAP S/4HANA (opens in new tab) guide.

The analytic consequence is direct: the same product exists in both systems, and so does the same delivery, in two different shapes. Decide per entity which system is your lakehouse's source of truth and extract it once — products and partners from the ERP side, warehouse execution from EWM is the usual answer — rather than landing both and discovering the duplicate at reporting time.

Once the data has landed, /SCDL/DB_REFDOCis how an EWM document ties back to the ERP document number it came from: it carries the reference document category and the readable reference number beside the EWM document's GUID. It is the join that makes a two-system warehouse story reconcile, and it is one more reason to filter on the reference category before you join — the table serves every reference type at once.

SAP ships released CDS views over EWM data — roughly seventy of them, catalogued under CDS Views for Extended Warehouse Management (opens in new tab). A released view is a stable, SAP-maintained shape over the raw tables, which makes it attractive as an extraction surface: the joins and the semantics are SAP's problem rather than yours. The five closest to supply chain analytics:

• I_EWM_WarehouseTask_2 (opens in new tab) — warehouse tasks
• I_EWM_WarehouseOrder_2 (opens in new tab) — warehouse orders
• I_EWM_PhysStockProd (opens in new tab) — physical stock by product
• I_EWM_AvailableStock (opens in new tab) — available stock
• I_EWM_InbDeliveryHeader (opens in new tab) — inbound delivery headers

All five are dimension-shaped — stable entity views over one document or stock object. The catalog also carries an analytic layer the list above does not represent: cube and query views over warehouse tasks, warehouse orders, waves, inbound delivery items, outbound delivery orders, storage bins, and storage bin activity areas — aggregation-shaped, and one step closer to a dashboard than the dimension views are. Released views for the outbound delivery order header and item also appear there, closing the CDS-side gap against the /SCDL/DB_PROCH_O / /SCDL/DB_PROCI_O table pair this reference documents. Both caveats below carry across to that layer unchanged — an aggregated view inherits the scope of whatever it aggregates.

One dimension pair is worth singling out: I_EWM_WhseReqStatusValue (opens in new tab) and its text companion enumerate the warehouse-request status values and their descriptions at runtime — the first credible enumeration surface for the /SCDL status family this reference deliberately describes rather than decodes. It is a runtime object, not a published value list, so treat it as the place to query the codes in your own system rather than a decode table to copy.

Two caveats, both load-bearing before you build on any of them.

Scope. Per SAP KBA 3434190 (opens in new tab), the released warehouse-task view carries only tasks that have a warehouse process type — and there are no released views for manufacturing-order, material-document, or handling-unit warehouse documents. That is not a rounding error in a throughput number: a warehouse that moves stock through those document types will report a task count lower than the floor actually worked. Reconcile the view against the raw tables before you publish from it.

Extraction suitability. SAP does not publicly state that these views carry the extraction annotation. Delta extraction of a CDS view over ODP-based OData requires the view to be annotated @Analytics.dataExtraction.enabled with delta.changeDataCapture maintained (SAP's own documentation of the mechanic (opens in new tab)). “Released” and “extractable” are different properties. Check the annotation in your own system — through the view's metadata, not through a blog — before a pipeline design depends on it. And note the throughput reality on that transport, plus what Note 3255746 did to the alternative, in the SAP guide's ODP section.

The pragmatic read: released views are a good semantic layer and a useful cross-check, and the raw tables remain the complete answer at warehouse-task grain. Most estates that get this right land the raw tables and use the views to validate what they built.

This is the section to read twice, because it is where an EWM extract goes wrong in a way that looks right.

Open warehouse tasks live in /SCWM/ORDIM_O. On confirmation, the task is written to /SCWM/ORDIM_C and no longer appears in the open table. SAP's support wiki on the EWM warehouse-task tables (opens in new tab) names the pair with exactly that split — confirmed in one, open in the other — the DataSource for confirmed warehouse tasks (opens in new tab) sources from the confirmed table, and warehouse-task archiving (opens in new tab) reads the confirmed, HU-item movement, and log tables — task history is archived from the confirmed side, not the open one.

Three consequences for your pipeline.

One: a CDC pipeline that misses deletes is actively wrong, not merely stale. A watermark pull on a creation timestamp can never learn that a row left the open table. Bronze then shows every task ever created as still open — an open-task backlog that only grows, a “work in progress” number that is really a cumulative created count. That is worse than missing data, because it renders plausibly on a dashboard. Delete capture is a requirement on this table, which in practice means log-based CDC or a replication tool that emits delete operations.

Two: mirror-the-source is still the right bronze convention. Honoring the delete does not lose history, because the row is not gone from the system — the confirmed task is in the confirmed table and cancellations are logged in /SCWM/ORDIM_L. Bronze should look like the source; the full task story is the UNION ALL the table pages generate for you (see confirming a warehouse task deletes it). Resist the temptation to keep deleted rows alive in bronze with a soft-delete flag: you would be inventing a shape the source does not have, and double-counting the moment you union it with the confirmed table.

Three: replicate all three task tables together. Open, confirmed, and log are one story in three tables. Landing the open table alone gives you a backlog with no throughput; landing open and confirmed without the log quietly reclassifies cancelled work as still open. Put them in the same replication set with the same schedule, or your union will have holes that shift depending on which table ran last.

Two secondary caveats worth sizing for. /SCWM/AQUA and /SCWM/RSRC are current-state tables — available stock and resource assignment respectively — so under CDC they generate heavy update churn rather than append volume, and a naive “rows per day” sizing estimate will be badly wrong in both directions. And the delivery documents in the /SCDL layer are updated in place as they progress through their status ladder, so the same rule applies there: the change feed is where the process history is, not the table.

Start with the rename, because every snippet on this reference assumes it. A namespaced SAP table name is not a legal Databricks identifier, so the bronze convention here is: strip the leading slash, swap the remaining slashes for underscores, lowercase — /SCWM/ORDIM_O lands as scwm_ordim_o, /SCDL/DB_REFDOC as scdl_db_refdoc. Adjust to your own landing convention if you already have one, but pick it once: the generated SQL on every table page reads that form. Namespaced columns keep their names and get backtick-quoted (`/SCWM/WHNO`) — see the quirks section for both halves of the rule.

The safe incremental load is the same two steps as anywhere else: 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. What the watermark and delete columns are called depends on your tool, so they stay placeholders below. The skeleton targets the open warehouse-task table keyed on MANDT, LGNUM, TANUM.

-- Incremental upsert from a staged CDC batch into the bronze copy of the OPEN
-- warehouse-task table. The watermark and delete-signal columns depend on your
-- replication tool: SLT adds an operation flag, and most log-based CDC tools
-- write their own _operation / _extracted_at columns - substitute yours for the
-- placeholders below.
--
-- THE DELETE BRANCH IS LOAD-BEARING ON THIS TABLE. A row that leaves
-- /SCWM/ORDIM_O is a confirmed or cancelled task, not a lost one: the confirmed
-- row lands in scwm_ordim_c (whose key carries one column more, TAPOS) and
-- cancellations are logged in scwm_ordim_l. Open + confirmed analysis is the
-- UNION ALL on the table page - never a row kept alive here.
MERGE INTO <catalog>.<schema>.scwm_ordim_o AS tgt
USING (
  SELECT * FROM (
    SELECT *, ROW_NUMBER() OVER (
      PARTITION BY MANDT, LGNUM, TANUM
      ORDER BY <watermark_column> DESC
    ) AS rn
    FROM <catalog>.<staging_schema>.scwm_ordim_o
  ) WHERE rn = 1
) AS src
ON  tgt.MANDT = src.MANDT
AND tgt.LGNUM = src.LGNUM
AND tgt.TANUM = src.TANUM
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 confirmed table takes the same skeleton with one more key column, TAPOS, in both the PARTITION BY and the ON clause. And if the DELETE branch above looks aggressive, re-read the ORDIM_O problem — dropping it is precisely how bronze ends up reporting a warehouse that never finishes any work.

Two flags, flagged rather than advised. SAP treats interface usage rights as contractual, not merely technical — an interface that has worked for years can be declared out of bounds and then enforced. And a decentralized EWM system is separately licensed, with its own contract surface: a second system to extract from is also a second set of usage terms to check, not an extension of the ERP's.

The canonical treatment of both — including what Note 3255746 demonstrates about enforcement, and where raw-table replication intersects indirect-access concepts — lives on the SAP guide's licensing section. The rule this page endorses is the same one: involve whoever owns your SAP license before standing up a new extraction path. This is not legal or licensing advice.