28. July 2026 · AI
How to Build SAP Data Products: From Source System to Reusable Data Asset
Your group runs S/4HANA in the cloud. Alongside it sit two ECC systems, a BW, and a handful of third-party applications nobody intends to retire. In SAP Business Data Cloud you see cleanly packaged data products – but only for the systems SAP connects natively. Everything else is on the outside looking in. The question that follows is not "what is a data product?" It is: how do I get my own data into the same shape?
That is what this guide covers.
Status of this guide: 28 July 2026
SAP Data Product Studio is not generally available as of writing. The procedure described here rests primarily on a public SAP expert session from March 2026, in which a pre-release build from a development tenant was demonstrated. SAP explicitly stated that scope, naming and timelines are subject to change.
Conflicting availability dates: SAP TechEd 2025 communicated a first-half-2026 window; in the March 2026 session SAP named the third quarter of 2026. The date has already slipped once. Check the SAP Road Map Explorer before you plan anything – not this article.
What you can build today is covered in section 4 and in the roadmap table near the end.
The goal in one sentence
You take data from a system SAP Business Data Cloud does not natively know – ECC, BW, a third-party application – and publish it as a versioned, catalogued data product consumable via Delta Sharing, indistinguishable to downstream consumers from an SAP-managed one.
1. What makes something a data product
The most common mistake happens before the first click: a table gets exposed and called a data product. It isn't one. SAP names five properties, and every one of them is work.
It is a semantically coherent set of data. Not a table, but a group of objects that belong together in business terms – master data with its texts and hierarchies in one, transactional data in another. Scoping is a design decision, not a technical one.
It is reusable. Small enough to serve several contexts. Large enough to stand on its own. Those two requirements pull in opposite directions, and reconciling them is the actual modelling work.
It is well described. In two senses: a business description that lets a business user browsing the catalogue recognise whether this is the right dataset for their report. And sound semantics – field types, currency indicators, aggregation behaviour, associations between entities. Descriptive text alone does not qualify.
It is easy to consume. Through a defined endpoint – Delta Sharing in SAP's case. That carries a commitment many underestimate: you are promising a stable interface. Once published, a data product cannot be changed at will. More on that under versioning.
It is discoverable. Through the catalogue in SAP Business Data Cloud. What cannot be found there does not exist as far as the organisation is concerned.
Delta Sharing is an open protocol for data exchange without duplication: the consumer reads the data where it lives rather than replicating it.
2. Do you actually need a custom data product?
Five criteria. If fewer than three are a yes, build a view in SAP Datasphere and spare yourself the governance overhead.
- More than one consumer. A data product only pays back when at least two independent consumers use it. With one, you have built an elaborately wrapped point-to-point delivery.
- Consumers outside your modelling tool. Databricks, a BTP application, an AI scenario, another business unit. If everything stays inside Datasphere, Datasphere is enough.
- You want to commit to stability. You want to fix a structure and route changes through controlled versions.
- Discoverability is a real problem. There is enough data around that people have to search.
- Clear business ownership exists. Somebody owns this thing. Without a nameable owner, a data product reliably decays into an orphaned table with a certificate attached.
3. Prerequisites
- You have an SAP Business Data Cloud subscription. Consuming BDC data products through the standard path requires it – including when your HANA Cloud runs in BTP rather than BDC, where a destination link is added on top.
- You have an SAP Datasphere tenant that is part of a BDC formation. The Datasphere object store is where customer-managed data products live; the Foundation Services object store is SAP-managed and not intended for yours.
- You have a space with object store capability in Datasphere, and the rights to create local tables on file there.
- Your source systems are reachable through Datasphere – as a connection, via replication flow, over SQL. You do not rebuild these connections; you reuse what exists.
- There is named business ownership for the dataset. A person or a maintained distribution list, not an unattended shared mailbox.
- For promotion through the landscape: multiple formations, or at least separate tenants for development, test and production.
4. The map: four tools, three of them go somewhere else
Several SAP tools carry "data product" in their name or their description. The confusion is real and has cost projects weeks.
| Tool | What it does | What it is not for |
|---|---|---|
| Data Product Generator (in BW) | Takes an InfoProvider, pushes the data into the Datasphere object store, creates the local tables on file, sets up the replication subscription and groups the objects | Despite the name it does not produce a finished data product – the wrapper is missing. And it is a BW feature, so it only serves BW sources |
| Data Sharing Cockpit (in Datasphere) | Originally built for SQL-based sharing between Datasphere tenants; since extended to create Delta Sharing-based data products | This is the interim path until Data Product Studio ships. Version management and transport work only through workarounds; derived data products with lineage are not in scope |
| Data Composer | Merges records from multiple systems at data level toward a golden record – a union, not a join. It comes from the customer data platform space | It is not a successor to, or a rename of, Data Product Studio. It does emit a data product at the end, but it is tied to a line-of-business product and is not part of the BDC baseline |
| Data Product Studio | The tool that is coming: data-product-first, hosted in the BDC Cockpit, designed to be runtime-independent, with version management and transport across the landscape | Not generally available as of July 2026 |
What this means in practice: if you have to deliver now, build through the Data Sharing Cockpit – but build so the later switch is cheap. Concretely: fix your scoping and semantics now the way you would in the Studio, and document versioning as a discipline even though the tool does not yet enforce it.
A second path exists for results produced in SAP Databricks. You store the result as a Delta table, create a Delta share in Catalog Explorer with SAP Business Data Cloud as the recipient, and supply two metadata files – an ORD file describing resources and capabilities, and a CSN file defining the structure. Only then does the shared dataset become a data product.
5. Step by step
The sequence below describes the Data Product Studio path, because it shows the target architecture. Steps 1 through 4 apply unchanged to today's Data Sharing Cockpit route – only steps 8 and 9 fall away there.
Step 1: Connect the source to Datasphere and land the data
What you do: Connect your source system – ECC, BW, third-party – to SAP Datasphere and replicate the required tables into the object store. From BW, the Data Product Generator handles this; for every other source you use existing connections and replication flows.
How you know it worked: Your object store space contains local tables on file with the expected record counts, and replication completes without errors.
Most common failure: Looking for the connection inside Data Product Studio. It isn't there. The Studio does not build source connectivity – it consumes what Datasphere already has. All integration work happens upstream.
Step 2: Structure spaces to preserve lineage
What you do: Create one object store space per source system rather than a single catch-all space. SAP has signalled dedicated spaces for data product creation; independent of that, separating by source system is the right call today.
How you know it worked: You can tell from a space alone which system its data came from.
Most common failure: One shared space for two ECC clients. After that, the data product no longer reveals which figure came from which system, and the lineage that governance and later derived products depend on is gone. Untangling it afterwards means touching every downstream object.
Step 3: Decide the scope
What you do: Determine which entities belong in one data product. Rule of thumb: master data with its texts and hierarchies forms one unit, transactional data another. Joining happens at the consumer, not inside the product.
How you know it worked: You can state what the data product is for in a single sentence, without using "and".
Most common failure: Scoping follows source structure instead of the business question. A data product that exists because these five tables happened to share a schema will not be reused by anyone.
This is the point of no return. From here on, any change to scope means a new major version, with everything that entails.
Step 4: Enrich semantics and description
What you do: Check field types, set currency and unit indicators, define aggregation behaviour, separate measures from dimensions, define associations between entities. Then the business description: what is in it, which question it answers, and what it is explicitly not for.
How you know it worked: Someone unfamiliar with the source system can decide from the catalogue entry alone whether this is the right dataset.
Most common failure: Treating the description as a mandatory field and filling it with the table name. That ends discoverability – and discoverability is one of the five constituting properties, not a nice-to-have.
Step 5: Select source objects in the Studio
What you do: From the BDC Cockpit, switch to Data Product Studio via the app switcher, create a new data product, pick the Datasphere tenant, then the space, then the tables.
How you know it worked: The selected entities appear with their semantics intact – dimension and fact tables are recognisable as such, measures and aggregations carried over.
Most common failure: Expecting the Studio to crawl the data. It does not – it asks the catalogue which objects are available. A table that exists but is not registered in the catalogue will not appear in the picker.
Step 6: Define the output structure
What you do: In the first release: nothing. Source maps to target one-to-one. Filters and projections are planned; genuine transformations are not, initially.
How you know it worked: Output structure matches input structure.
Most common failure: Expecting to model in the Studio. Data Product Studio does not replace SAP Datasphere. Every transformation – joins, calculations, cleansing – happens beforehand in Datasphere through transformation and replication flows. The Studio wraps the result. Reverse that, and you are building in the wrong place.
Step 7: Metadata and publication attributes
What you do: Business name, description, protocol (Delta Sharing initially), domain, owning person or distribution list, category – options include business objects, analytical and other – plus the line-of-business assignment.
How you know it worked: The filters you will later need to find this thing in the catalogue are populated.
Most common failure: Dismissing categories and line-of-business fields as SAP-internal classification and leaving them empty. They are the filter dimensions in the catalogue – the same ones you know from the Business Accelerator Hub. Your own data products do not appear there, but the filtering logic in the internal catalogue is the same.
Step 8: Assign runtime systems
What you do: For each environment – development, test, production – define which Datasphere space supplies the local tables there.
How you know it worked: Every target environment has an assignment.
Most common failure: Assuming the selection from step 5 applies everywhere. It applies to development. Miss this and you have a data product that cannot be transported – and you find out at the latest possible moment.
Step 9: Set the version and publish
What you do: Assign a version and set a state. Major, minor and patch versions are planned, along with states from saved through a test deployment to active and deprecated.
The rule behind this is the single most important one in the whole procedure:
- Minor and patch = compatible change. An added column, a sharpened description. Existing consumers receive it on deployment without acting.
- Major = breaking change. A removed column, a changed key. Both major versions then run in parallel – to the downstream services they are two distinct data products. Consumers switch deliberately.
How you know it worked: A consumer can rely on the structure without knowing your change process.
Most common failure: Shipping a breaking change as a minor version because it technically passes. That breaks the very promise that makes a data product a product – and the damage lands on systems you do not know about.
Step 10: Grant access through the catalogue
What you do: Consumers find the data product in the BDC catalogue, request access, install it in their environment and bind the Delta Sharing endpoint – Datasphere, Databricks, a BTP application.
How you know it worked: A consumer you never spoke to finds the product and can request access.
Most common failure: Conflating deployment with installation. Deployment means the data product exists in a formation. Installation means a consumer obtained it through the catalogue. "Where is it deployed" does not answer "who is using it".
6. Interface data products – the part worth your attention
This capability gets underrated because it sounds technically dull. An interface data product is a data product with no source and no transformation – it defines the output structure only. It is an interface contract, not a dataset.
The value shows up on implementation. SAP ships an interface data product for certain applications. You create your own data product against that interface: the output structure is locked – fields, columns, data types are fixed – and your job is to get your data into that shape. Satisfy the interface and the SAP application runs on your data.
The scenario that makes the difference: you are on the way to S/4HANA but not there yet. An SAP application you want to adopt expects S/4HANA data products. Through an interface data product you bring your ECC data into exactly that structure – the application runs even though the source system is a different one. And everything you build on top survives: once migration completes, you swap the data product for the genuine S/4HANA one. The layers above notice nothing.
Anyone facing a multi-year transformation should understand this mechanism before redesigning their analytics landscape. It determines whether the next two years of work survive the system change.
SAP describes three stages: first, implementing SAP-supplied interfaces; later, using any existing data product as an interface template; finally, defining your own interfaces. That third stage targets group structures – headquarters defines a structure, regions or subsidiaries deliver against it, and data exchange no longer needs bilateral negotiation. Only the first stage is announced for the initial release.
7. Pitfalls
Modelling ends up in the wrong tool. Symptom: people hunt for join, calculation or cleansing functions in the Studio. Cause: the Studio is a packaging tool, not a modelling tool – at least at launch. Avoid by: completing all transformations in Datasphere before opening the Studio.
Views used as the source instead of local tables. Symptom: a Datasphere view is meant to back a data product directly. Cause: the customer-managed path sits on the object store, meaning local tables on file. Avoid by: materialising the view result into the object store through a transformation flow. Otherwise you push compute into every single consumer read.
A catch-all space destroys lineage. Symptom: two source systems share one object store space. Cause: the space carries the source-system identity. Avoid by: one space per source system, from day one.
Breaking change shipped as a minor version. Symptom: a column disappears and the version goes from 1.2 to 1.3. Cause: the check is technical instead of contractual. Avoid by: a hard rule – every deletion and every key change is a major version, no judgement calls.
Deployment mistaken for installation. Symptom: usage reporting shows activity but nobody in the business recognises the product. Cause: deployment into a formation is not the same as acquisition through the catalogue. Avoid by: tracking both metrics separately.
Missing catalogue metadata. Symptom: a table exists in the object store but does not appear for selection in the Studio. Cause: the Studio works against the catalogue, not against the data. Avoid by: treating catalogue registration as a precondition, not a side effect.
No named owner. Symptom: six months in, nobody can say whether the data is still correct. Cause: the owner field was filled with an unattended shared mailbox. Avoid by: naming a person or a maintained list – and anchoring ownership in the business, not in IT.
Missing runtime assignment blocks transport. Symptom: the data product cannot be promoted to test. Cause: no source space was assigned for test and production. Avoid by: completing assignments for every environment at creation time.
Wrong assumptions about tool scope. Symptom: weeks disappear into the question of whether Data Composer supersedes Data Product Studio. Cause: similar naming, entirely different purpose. Avoid by: keeping the table in section 4 as a project reference.
8. Available today versus announced
| Capability | Status July 2026 | Note |
|---|---|---|
| Landing third-party data in the Datasphere object store | Available | Through existing connections and replication flows |
| Moving BW data into the object store | Available | Data Product Generator; produces the precursor, not the data product |
| Creating a Delta Sharing-based data product | Available | Through Data Sharing Cockpit in Datasphere, as an interim path |
| Pushing SAP Databricks results back | Available | Delta table, Delta share to BDC, plus ORD and CSN files |
| Data Product Studio in the BDC Cockpit | Announced | Date statements conflict (see status box) |
| Version management with major, minor and patch | Announced | State model still under revision as of the session |
| Transport across development, test and production | Announced | Depends on hosting in the BDC Cockpit |
| Implementing SAP-supplied interface data products | Announced, first release | |
| Defining your own interface data products | Announced, later stage | |
| Derived data products from existing data products | Announced, later stage | Also stored in the object store |
| Mixing SAP-managed and custom-managed data products | Announced, no date | |
| Transformations inside the Studio | Beyond the first release | One-to-one mapping first, filters and projections planned |
| Domain concept for ownership | Announced, dependent on the governance roadmap |
9. Checklist
Before building
- ☐ At least two independent consumers identified
- ☐ Business owner named and on board
- ☐ BDC subscription and Datasphere tenant inside a formation
- ☐ Object store space created per source system
- ☐ Scope expressible in one sentence without "and"
While building
- ☐ All transformations completed in Datasphere, result materialised
- ☐ Semantics set: field types, currency, aggregation, associations
- ☐ Business description written – including what the product is not for
- ☐ Category and line of business populated
- ☐ Runtime assignments recorded for every environment
Before publishing
- ☐ Versioning rule written down and known in the team
- ☐ Catalogue entry reviewed by someone unfamiliar with the source system
- ☐ Deployment and installation metrics defined separately
- ☐ If an S/4HANA migration is running: checked whether an interface data product is the better cut
10. Frequently asked questions
Does Data Product Studio make modelling in SAP Datasphere obsolete? No. Datasphere remains the modelling tool – views, analytic models, exception aggregations, input parameters, planning. The Studio operates at table level on the object store. Even if modelling capabilities arrive there later, they will stay at that level.
Are derived data products also stored in the object store? Yes.
Do I need a BDC subscription if I build agentic scenarios in BTP with HANA Cloud? For consuming SAP-managed data products from BDC, yes. If HANA Cloud runs in BTP rather than BDC, a destination link is added through which the data product is actively shared.
Do I have to model an ontology or knowledge graph for AI agents? Per SAP's description, the required metadata structure is built in the background and consumed by the agents. Whether customers get access to it, or can create their own, was an open question at the time of the session.
Was the Studio renamed to "Data Composer"? No. Data Composer merges records into a golden record, originates in a different product area and is tied to a line-of-business product. It emits a data product at the end – that does not make it the same tool.
Can I move data products between formations? You deploy them into the target formation. Within a formation the source comes from Datasphere, and exposure runs through the foundation service.
Can I hand a data product over as a file? Data product definition files are planned, including download and upload, and the Studio is designed API-first. For partners providing products as templates that is the simplest route; broader distribution mechanisms are being worked on separately.
Sources
- SAP Live Expert Session on Data Product Studio in SAP Business Data Cloud, March 2026 – https://www.youtube.com/watch?v=g00Zw5UV7Tw (transcript reviewed 28 July 2026)
- SAP Learning: Sharing data back to SAP Business Data Cloud – https://learning.sap.com/courses/introducing-the-open-data-ecosystem-for-sap-business-data-cloud/sharing-data-back-to-sap-business-data-cloud (accessed 28 July 2026)
- SAP News Center: Accelerate the Autonomous Enterprise with SAP Business Data Cloud, May 2026 – https://news.sap.com/2026/05/sap-bdc-accelerate-autonomous-enterprise/ (accessed 28 July 2026)
- SAP Architecture Center: Data Products in SAP Business Data Cloud – https://architecture.learning.sap.com/docs/ref-arch/f5b6b597a6/1 (page returned no readable content when accessed on 28 July 2026; listed as further reading, not used as evidence)
Confidence in the load-bearing statements
| Statement | Source | Confidence |
|---|---|---|
| Five constituting properties of a data product | 1 | High |
| Customer-managed data products sit on the Datasphere object store | 1 | High |
| Data Product Generator does not produce a finished data product | 1 | High |
| Data Sharing Cockpit as the interim path with Delta Sharing creation | 1 | High |
| Versioning rule: major for breaking changes, parallel operation | 1 | High |
| Interface data products and the three stages | 1 | High |
| First release limited to one-to-one mapping without transformations | 1 | Medium – explicitly flagged as planning status |
| Databricks return path via Delta share plus ORD and CSN files | 2 | High |
| Data Product Studio availability window | 1, plus a conflicting figure from TechEd 2025 communications | Low – statements conflict, and neither date could be confirmed in a directly retrievable primary source |
| Categories business objects, analytical, other | 1 | Medium – stated with reservation in the session |
| Version state model | 1 | Low – under revision at the time of the session per SAP |
Sascha Theismann helps enterprises execute measurable digital transformation – from AI and automation governance to enterprise architecture in the SAP landscape.
