What Is an SAP Data Product, and How Does It Fit a Data Mesh?
Josue Ramirez
Last updated: August 2026
What is an SAP data product
An SAP data product is a business object modeled as a complete, queryable unit: a sales order with its line items, a billing document with its accounting entries. It is named in business terms rather than by table, it declares its own join topology, and it assigns a role to every field: measure, dimension, identifier, or timestamp.
The four key points:
- One business object corresponds to one data product. A sales order is a single data product, not the two tables it happens to occupy.
- The same concept carries four names depending on who is speaking: business object in SAP, entity in event driven architecture, node in graph modeling, and data product in the data discipline.
- A data product declares its schema and its joins, so a consumer never needs to know which tables the source system used.
- A table extract carries columns. A data product carries meaning. That difference is what makes a mesh possible.
Why are raw SAP tables not a data product?
A table is a storage decision. A data product is a contract. VBAK holds a sales order header and VBAP holds its items, which means the thing a business user calls "a sales order" does not exist as a single queryable unit anywhere in the source system.
The consumer has to reassemble it correctly, every time. That reassembly is where the knowledge lives, and it is precisely what a table extract leaves behind: the join between header and item, the fact that a currency field is not just a number, the fact that a date field is stored as a character string.
A data product moves that knowledge out of the consumer's head and into the definition. The consumer asks for a sales order and receives a sales order.
The join topology of one data product, declared once so no consumer has to rebuild it.
How does SAP data reach the mesh in the first place?
Onibex OneConnect captures changes in SAP ECC and SAP S/4HANA through application-layer business events (RAP, BOR, BTE, PPF), pushed outbound over an HTTP RFC destination of Type G to the Smart Gateway, and streamed to Apache Kafka, Confluent Cloud, Databricks, Snowflake, and other targets, with topics and schema registry entries created on the fly and schema evolution supported. Nothing is read from the database layer. Nothing is pulled.
The capture point matters for a mesh, and not only for latency. An event that fires in the application layer knows what the business did. A row mutation only knows that a row changed.
That distinction surfaces the first time a consumer asks why a value moved. A business event carries the intent that produced the change, because it fires where the intent is known. A row-level change record carries the after-image and nothing else.
What is the difference between a data product and a table replica?
A replica reproduces the source system's structure in another database. A data product publishes a business concept with a contract. A mesh needs the second one, because a mesh is defined by what its nodes promise to consumers.
| Dimension | Table replica | SAP data product |
|---|---|---|
| Unit of publication | One table | One business object with all its nodes |
| Naming | Source system table and field names | Business terms |
| Join knowledge | Lives in the consumer | Declared in the definition |
| Field semantics | Column type only | Declared role: measure, dimension, identifier, timestamp |
| Schema change | Consumer breaks or adapts | Schema evolution supported at the registry |
| Ownership | Whoever built the pipeline | The data product owner |
The third row is the one that decides projects. When join knowledge lives in the consumer, every new consumer relearns it, and two consumers eventually disagree about what revenue means.
Which SAP business objects are already modeled?
The Onibex Marketplace lists 159 pre-modeled SAP data products as of August 2026, across 11 business modules. Each one ships with its entity and field definitions, declaring source tables, join keys, join types and the business name of every field. The distribution reflects where transactional volume actually sits in an ERP rather than an even spread.
| SAP module | Data products |
|---|---|
| Sales and Distribution | 39 |
| Enterprise Structure | 26 |
| Materials Management | 23 |
| Extended Warehouse Management | 19 |
| Finance | 18 |
| Plant Maintenance | 13 |
| Production Planning | 10 |
| Controlling | 5 |
| Quality Management | 4 |
| Human Resources | 1 |
| Transportation Management | 1 |
They are built two ways: 97 from tables and 60 from CDS views. That choice is not cosmetic. A data product built from tables sees what the database stores. A data product built from a CDS view inherits the semantics SAP already declared in that view, including its associations and annotations, which means less to redeclare and a tighter coupling to the view's lifecycle.
The practical read: a standard business object is already modeled, and the modeling effort concentrates on custom objects and Z tables, which no catalogue can cover in advance.
Frequently asked questions
What is an SAP data product?
An SAP data product is a business object modeled as a complete, queryable unit, named in business terms, declaring its own join topology and a role for every field. One business object corresponds to one data product, so a sales order is one product rather than the two tables it occupies.
Can you build a data mesh on SAP without modifying the SAP system?
Yes. Capture happens at the application layer through business events pushed outbound over an RFC destination of Type G, so nothing reads the database layer and nothing modifies the SAP core.
How many SAP data products come pre-modeled?
The Onibex Marketplace lists 159 data products as of August 2026, spread across 11 SAP business modules, with Sales and Distribution the largest group at 39. They are built either from tables or from CDS views.
Should a data product be built from tables or from CDS views?
A data product built from tables reflects what the database stores. One built from a CDS view inherits the semantics SAP already declared there, including associations and annotations, which reduces what has to be redeclared and ties the product to that view's lifecycle.
What OneConnect does not do
OneConnect does not read the SAP database layer and it does not poll tables. Capture happens through application-layer business events, so a change that never raises an event is not captured.
It does not model custom objects for you. The 159 pre-modeled data products cover standard business objects; a heavily customized Z table needs a definition written for it.
It does not resolve business meaning that the source system never recorded. A field stored as a character string arrives as a character string, and the semantics have to be declared in the data product rather than inferred by whoever queries it later.
About Onibex
Onibex is an SAP Silver Partner and Confluent Gold Partner building real-time SAP data hyperconnectivity for the enterprise. Its flagship platform, Onibex OneConnect, streams SAP ECC and SAP S/4HANA business events to Apache Kafka, Confluent Cloud, Databricks, Snowflake, and other destinations in real time. Onibex also maintains ASK (Agentic Semantic Knowledge), an open semantic-layer standard that grounds AI agents in governed, business-ready SAP data. Onibex is headquartered in The Woodlands, Texas.
Technical reference: the data product reference architecture and the full configuration steps are documented in oneconnect-docs.
Related reading: What Is Account Receivable Visibility, and How Do You Keep It Current in Real Time?