Skip to Content
Technical Articles
Author's profile photo Chaim Bendelac

Part 1: Introduction to SAP Graph

INFO: This blog is part of a tutorial series for the standalone SAP Graph service on SAP BTP. Recently, SAP released a version of Graph in SAP Integration Suite with better user experience and functional enhancements (see this blog for details: ).


SAP Graph is the new unified and consolidated API for SAP-managed data. Developers use SAP Graph to build applications that access a connected business data graph of SAP-managed data, regardless of where this data resides.

This is the first part in a developer tutorial on SAP Graph, the API for SAP’s Integrated Intelligent Suite. For an up-to-date overview and publication schedule for the full tutorial series, check the SAP Graph Multi-Part Tutorial: Information Map.

In this multi-part tutorial, we will take you from learning about what SAP Graph entails, all the way to becoming a developer who is proficient in using SAP Graph as an entry point to all business data and insight in the SAP Intelligent enterprise, regardless of where this data resides.


SAP Graph was productively released for early adopters in December of 2021. We offer dedicated support for early adopters of this innovative solution. Contact us at if you are interested.

With this out of the way, let’s talk about what SAP Graph wants to accomplish.

SAP is famous for its ERP software, but today SAP customers have increasingly more complex requirements and are managing intricate and hybrid on-premise and cloud solutions. Customers want to become Intelligent Enterprises. To support their journey, SAP has augmented its ERP-centric business suite with substantial additional functions through the acquisition of cloud solutions like SAP SuccessFactors, SAP Concur and SAP Ariba. SAP’s Intelligent Suite portfolio now supports all key business processes and span all enterprise functions, but this expanded role and diversity of solutions has introduced some complexity. Many of SAP suite’s products have their own stack: overlapping data models, different APIs and heterogenous infrastructures, and this complexity is not always well hidden from SAP’s customers.

From the perspective of a software developer, this means that accessing SAP-managed data has become more complex. Data may be federated across hybrid networks of on-premise and cloud systems with different security protocols, replication processes and multiple master data copies. You don’t only have to worry about the data you are interested in, you have to know which copy you need, where that data exactly is located, and how to deal with connecting to these different customer systems. Different products have different connection protocols, security requirements and APIs, and those APIs expose data using different and inconsistent data models. Developing SAP extension apps requires mastering a broad set of skills for even the simplest data queries, and the applications you develop are sensitive to the smallest product and landscape configuration changes.

This is the problem that SAP Graph addresses.

SAP Graph is a new unified API for SAP. It addresses this run-away API complexity and integration challenge by providing developers a single connected and unified view of all their business data, consolidating the data models of data sources like SAP S/4HANA, SAP Sales Cloud and SAP SuccessFactors into one, unified and connected, data model, reprsenting all the data in a landscape. We call this the Business Data Graph.

A data graph is a connected graph, with data entities serving as the nodes of the graph and edges that represent relationships (which we call associations) between those entities. The nodes of the Business Data Graph are the common enterprise business objects, like Customer, Supplier, Product, Sales and Purchase Order, General Ledger, etc.

As a developer, you face a dilemma. The concept of a Product or a Customer is common to many of the business systems that make up a landscape. Which of these definitions should you use? Where in the landscape is this data managed? SAP Graph resolves this dilemma by introducing unified entities that provide the most common attributes of a business model for easy consumption, and connect to the corresponding system-specific business objects for a full 360° view of the business object. You get to eat your cake and have it too: use the unified entities for simple use-cases, and easily access over 1,500 additional system-specific entities for advanced usage.

To illustrate these aspects of the data business graph, it is best if we start with a simple example taken from the enterprise world of sales. A salesperson entered a quote on behalf of a customer.

This quote is represented by a unified SalesQuote entity. The quote has an association to a Customer entity. The quote also has multiple items, each of which refer to a Product entity, which in turn has multiple associations to other entities, like Division. This is illustrated below:


Each entity has many additional attributes, such as a key (called id in unified entities), and various other attributes, which can be flat, arrays, or more complex structured compositions of other attributes. For instance, items is an array of a structured type.

With SAP Graph you navigate to and access the data you need, regardless of where this data resides. SAP Graph abstracts the physical landscape and the details of the different product stacks and offers you a simple view of the SAP-managed data, which you can access through a single API, spanning all key use cases. SAP Graph accesses the data in the customer-configured landscape on your users’ behalf, technically acting as middleware. SAP Graph itself doesn’t store or cache any data.


The above illustration shows your app accessing quote, product, customer and supplier data – but the app cannot tell if this is data is accessed from an on premise SAP S/4 HANA system, SAP Sales Cloud or another system, like SAP Ariba. This will be determined by the specific landscape configuration that SAP Graph accesses on behalf of the app user. As a developer, you are exempted from knowing these system details, or how to access data in these heterogenous systems. More importantly, your application will be portable across multiple and diverse landscapes without changes to your code.

But what if your app requires detailed attribute information that is not modeled in the unified entity? For instance, your app may be interested in Product inventory information, that is unique to data sources of type S/4HANA. No problem! Simply navigate over the _s4 association to access the required information, like the CountryOfOrigin of the product, or navigate further the product storage.


SAP Graph currently supports the OData v4 protocol to access the business data graph. OData (Open Data) is a widely used OASIS standard that defines a set of best practices for using RESTful data APIs. SAP Graph support for GraphQL, another popular data-access API, is planned in the future.

As we shall see, OData RESTful APIs are easy to consume. OData requests operate on resources, the data, and extends this with query options, that let you shape the response to queries. The resources of SAP Graph are the entities of the business data graph.

Exploring SAP Graph on the SAP Graph Navigator

The SAP Graph API is documented in the new SAP Graph Navigator. Go ahead and follow the link to the SAP Graph Navigator application to explore the API. The index, on the left of the application, shows you over 1,500 entities grouped by data source. The first group of entities are the unified entities. Here is an example of a unified entity, the sap.graph/WorkAssignment. 


Unified entities have a key, called id. You can see other attributes, like workforcePerson, the identifier of the person whose assignment this is. You can also see an association (a link) to the details of this person, another entity unsurprisingly called sap.graph/WorkforcePerson. Another interesting attribute is jobInfo. This is a composition, in this case of composition of many”, which you can think of as an array of this structure. Click on the little > arrow to see what it looks like, or study the example on the right, where you can see an array of one instance.
Finally, it is worth pointing out two more interesting assocations,  _cxsales and _hcm. These are links to the respective system-specific entities, sap.cxsales/EmployeeCollection and sap.hcm/EmpEmployment. They enable developers to augment the information available in the unified entity with system-specific attributes, and make the business data graph a connected and navigable graph of the entire enterprise landscape. Go ahead, click around the SAP Graph Navigator to get a sense of what the graph looks like.

With this quick introduction out of the way, follow us to part 2 of this tutorial, in which we will write our first SAP Graph based application.

Chaim Bendelac, Chief Product Manager – SAP Graph

Visit the SAP Graph website at

Contact us at




Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Syambabu Allu
      Syambabu Allu

      Hi Chaim,

      Thanks for sharing detailed Blog on SAP Graph.

      Looking forward to see more blogs on SAP Graph.

      When it will be GA to customers.

      Thank you,


      Author's profile photo Chaim Bendelac
      Chaim Bendelac
      Blog Post Author

      Thank you! Keep an eye on this space. More blogs are planned and will follow. We aim to release SAP Graph at the end of this year.




      Author's profile photo Manjunath GUDISI
      Manjunath GUDISI

      Dear Chaim - which systems is SAP Graph connected to? so that, it fetching the customer quotes when we call$top=2 ? 

      Do we have any control on systems connections. Forex: A customer had S/4HANA and C/4HANA systems, now they want to get customer quotes from Service cloud, and S/4HANA.

      Thank you, Manju

      Author's profile photo Chaim Bendelac
      Chaim Bendelac
      Blog Post Author

      Hello Manju,

      Thank you for your interestr.

      The sandbox in SAP API Business Hub evidently contains mock data, and is not a real customer system with customer data. A customer can use the SAP Graph service to fetch data from its own systems and system tenants, by configuring their own SAP Graph business data graph with full control over system connections and preferences. This is described in the SAP Graph documentation, and will be the subject of an upcoming tutorial as well.

      Author's profile photo Erik Hoven
      Erik Hoven

      Hi Chaim,

      Thanx for info regarding SAP Graph.

      "...SAP Graph is the new unified and consolidated API for SAP-managed data."


      Only SAP-managed data ? Not other legacy system ?


      Author's profile photo Chaim Bendelac
      Chaim Bendelac
      Blog Post Author

      Hi Erik, what we mean by SAP-managed is "enterprise data managed in SAP applications".




      Author's profile photo Dusan Stojkovic
      Dusan Stojkovic

      Hello Chaim.

      In many places I read SAP Graph uses One Domain Model where wording is given as it represents an API layer that exposes One Domain Model externally.

      In your text One Domain Model is not mentioned. I would also say Business Data Graph is different than One Domain because of things like:
      1) Objects like A_PurchaseOrder exist in SAP Graphs (s4) and SAP API Business Hub (S/4HANA system), but not in the One Domain Model

      2) Seems the Business Data Graph does not cover all source systems that One Domain Model does. I see SAP Graph still supports only S/4, C4C and SuccessFactors.

      Please provide your input on this.
      Thank you very much for the time !

      Author's profile photo Chaim Bendelac
      Chaim Bendelac
      Blog Post Author

      Hello Dusan,

      The "One Domain Model" (ODM) is an internal methodology to ensure that the different SAP applications will be able to exchange master data information, as an "out of the box" integration. ODM is currently used exclusively as an internal data exchange protocol within MDI - a relatively recent, and still somewhat restricted, integration service from SAP ( As you may have noticed, ODM is no longer a public specification.

      SAP Graph provides a different value: it creates a fully connected data graph of the data in a landscape. APIs to data graphs enable developers to more easily navigate the business data, understand the semantic relations between the different entities (business objects) and create more powerful and portable queries. More and more developers are looking into GraphQL (a language invented at Facebook, and now increasingly popular) as a way to significantly "upgrade" from simple REST APIs. SAP Graph's API and data graphs are compliant with the design principles of ODM.

      Hope this clarifies!

      Author's profile photo Gregor Wolf
      Gregor Wolf

      Hi Chaim,

      but the ODM is also published What I can't understand is that the ODM CostCenter Entity:

      has different fields compared to the SAP Graph CostCenter:

      Also have you noticed that still has a "Beta" badge for SAP Graph?

      Best Regards

      Author's profile photo Chaim Bendelac
      Chaim Bendelac
      Blog Post Author

      Hi Gregor,

      I know. The ODM pages on API Business Hub are no longer up to date.

      SAP Graph was recently consolidated into the API management solution of SAP INtegration Suite. We have made very good progress, and now also support GraphQL as an alternative to OData v4. Graph is currently (Q1 2023) in managed beta mode with a number of customers. Anyone with an interest in beta-testing the new Graph solution within API Management is welcome to contact or myself.



      Author's profile photo Gregor Wolf
      Gregor Wolf

      Hi Chaim,

      regarding your comment

      The ODM pages on API Business Hub are no longer up to date.

      When will the ODM pages be updated or will they be completely removed?