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: https://blogs.sap.com/2023/02/22/announcing-graph-in-sap-integration-suite ).
Hello!
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 sap.graph@sap.com 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.
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.
Hello!
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 sap.graph@sap.com 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 graph.sap
Contact us at sap.graph@sap.com
- SAP Managed Tags:
15 Comments
