Part 1: Introduction to SAP Graph
SAP Graph is the new unified and consolidated API for SAP-managed data. Developers use SAP Graph to build applications that access a 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 is currently in beta. We want you to be an early adopter of this innovative solution and to provide feedback, but you will not yet be able to use SAP Graph productively. See disclaimers.
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. 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 (based on SAP’s ODM model) 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 and ODM, 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 SAP API Business Hub
The SAP Graph API is documented on SAP API Business Hub. We have also preconfigured a free business data graph with access to an SAP-managed landscape with sandbox data. We refer to this business data graph as the sandbox. You can use it to interactively explore the API and data-set. The sandbox data set supports over 1,000 entities, but only a few are currently documented (more to come). In a later part of this tutorial we will discuss how to configure your own SAP Graph tenant, to access your own corporate data.
When you follow SAP API Business Hub, you will see a number of tiles. Each tile represents a unified entity. Click on one of them, for instance, click on the IndividualCustomer:
You can now do several things: read the SAP Graph documentation, check out the API Reference for this entity, study the Schema View, or get sample data by clicking the Try out button.
To use the Try out feature, you must log in with an SAP community login. You can set the parameters to the query, to change and control the result. For instance, we can set $top to 2, to fetch the first two quotes:
Now click Run to see the results. In a future blog, we will talk more about the OData protocol.
Scroll the data, and note again, that you as the developer did not have to specify where the data came from… that is the task and magic of SAP Graph.
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 http://explore.graph.sap/
Contact us at firstname.lastname@example.org