SAP BDC data products, and what makes one real
As of 2026-08-14
A data product in SAP Business Data Cloud is not a table somebody has access to. It is a published dataset with five things attached: a versioned schema contract, a service level stated in measurable terms, an explicit roster of authorised consumers, a named governance owner, and lineage back to the sources that produced it. That distinction — a table you can query against a product you formally subscribe to — is what separates a 2020-era warehouse from a 2026-era platform, and it is what an auditor notices first.
The five things that make it a product
The schema contract defines column names, types, semantic types, allowed null patterns and key relationships, and it is versioned: a breaking change bumps the major version and triggers a deprecation notice rather than silently altering what consumers depend on.
The service level states, in numbers, how fresh, complete and accurate the data is expected to be — measured and reported continuously rather than written once in a design document. An aspirational figure never tested under load is the most common defect, and it surfaces during the first breach investigation.
The consumer roster names which teams may read it; undocumented ad-hoc reads are refused by design, which is what makes a later schema decision tractable. The governance owner is a single accountable person or team reviewing the contract on a cadence. And lineage traces sources and transformation path inside the catalogue, so where a number came from takes seconds rather than a multi-day archaeology exercise.
Why the contract model changes behaviour
Without products, every consuming team builds its own version of Customer, Product or Sales Order, each interpreted slightly differently. When a source schema changes, some break silently and produce wrong numbers nobody notices, while others break loudly. The platform's real output becomes disagreement.
With a product in place, the producer commits to the published contract, consumers subscribe rather than querying underlying tables, and schema evolution follows announce, grace period, release.
The part that gets undersold is what it does for the producer. As long as the contract holds, they can refactor everything underneath — rename internal tables, change transformation logic, move the physical layout — without breaking a consumer. That is the leverage an explicit interface always buys.
The delivered catalogue
More than 300 SAP data products are live, spanning finance — billing and payments, cash flow, compensation — supply chain, human resources, service, spend management and industry-specific sets, with a stated target of 500-plus by Q2 2026, roughly 200 net new over two quarters.
Each carries a typed schema, business-meaningful measures, lineage back to the source system and governance metadata. A consumer — an agent, a story, a semantic model — queries a product as a first-class object rather than writing joins against raw source tables.
The pace is the signal worth tracking: every net-new product is capability delivered without a project, which is why the quarterly release notes deserve the attention a BW consultant once gave delivered content shipments. It is also why the check before committing a use case takes five minutes — confirm the domain exists in the live catalogue, not against the target.
Decision table: packaged, custom, or raw
A standard domain is in scope and the requirement maps to the delivered measure set. Take the packaged product: SAP absorbs schema updates, lineage corrections and certification, and a team can query within days of provisioning.
The business logic genuinely diverges — proprietary calculation, non-standard allocation, multi-system blending, an industry definition not yet delivered. Build the custom model and accept full ownership of maintenance. When a source upgrade changes the table structure, a custom model breaks silently until someone investigates a report deviation; a packaged product does not.
Initial exploration, or an operational requirement no product covers. Replicate raw tables, deliberately and temporarily — raw replication buys flexibility and zero semantic layer, so every consuming team re-implements the same joins, conversions and definitions.
A one-off table feeding a single dashboard owned by one team. Do not formalise it. The contract overhead only pays off when a dataset is cross-cutting or long-lived enough for drift to be a risk.
Publishing, and where BW estates enter
Products are authored through a studio surface bundling five panels: schema designer with sample-value preview, service-level editor turning commitments into measurable signals, lineage visualiser, access-rule binder that previews data as a specific calling user, and a test runner covering schema, service level and regression against the prior version. The workflow runs draft, review, publish, iterate, major bump — and the review step, where consumer representatives validate against real use cases, is the one skipped under pressure and the commonest cause of rework. Minor bumps cover additive changes; removing or narrowing a column is a major bump and triggers a ninety-day deprecation cycle.
For existing BW estates the data product layer is also the migration target. The generator reads InfoProviders and emits products preserving the semantic layer, with lineage and governance metadata; custom ABAP transformations, complex unions and hierarchy versioning surface as conversion warnings rather than silent approximations. It reproduces faithfully — which means it will carry a flawed calculation across intact.
What we cannot assert
We publish no per-product service-level figures: freshness and completeness targets are set per product and per customer, and quoting an example as though it were a delivered guarantee would misrepresent a contract we have not read.
Frequently asked
What is the difference between a data product and a table?
A table is something you have access to. A data product carries a versioned schema contract, a measured service level for freshness, completeness and accuracy, an explicit consumer roster, a named owner and traced lineage. Consumers subscribe rather than querying underlying tables, and undocumented ad-hoc reads are refused by design.
How many SAP data products are available?
More than 300 are live across finance, spend, supply chain, HR, service and industry verticals, with a stated target of 500-plus by Q2 2026. Check the live catalogue for the domain your use case needs before committing — the target is a commitment, not the current state.
What happens when a schema changes?
Additive changes such as a new column or a widened type are minor version bumps with no disruption to subscribers. Removing or narrowing a column is a major bump, which triggers a ninety-day deprecation cycle so consumers have a fixed migration runway rather than an unannounced break.
Should every dataset become a data product?
No, and treating it as mandatory is its own mistake. A one-off table feeding a single dashboard owned by one team does not need a contract. Formalise a dataset when it is genuinely cross-cutting, consumed by more than one team, or long-lived enough that schema drift becomes a real risk.
What this page is built on
- Data Products (C010)
- SAP Data Products — The 300+ Catalogue (target 500+ by Q2 2026) (C269)
- Data Product Studio (C011)
- SAP BW Data Product Generator — The BW Modernization Path (C270)