Hello, and welcome to the first in a tutorials series about the Graph functionality of API Management, a main capability of the SAP Integration Suite. In this series, we will take you from learning about what Graph is, to creating your own business data graphs with custom model extensions, all the way to becoming a developer who is proficient in using Graph as an access point to your business data, regardless of where this data resides.
For an overview of other parts of this series, check out the Information Map.
With Graph, you create an abstraction of business objects (aka entities) available in your landscape of business systems, in the form of a business data graph. The business data graph exposes the data of these business objects through a single, unified API. Application developers use powerful OData v4 or GraphQL commands to access only the data required to build the application and do not need to concern themselves with the complexities of the underlying data source systems.
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 Graph addresses.
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, representing 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? Graph addresses 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 have your cake and eat 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 business data 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 Graph you navigate to and access the data you need, regardless of where this data resides. 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. Graph accesses the data in the customer-configured landscape on your users’ behalf, technically acting as middleware. 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 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 via the to_ProductStorage association.
The unified entities introduced here are actually examples of a much more powerful capability of Graph: the ability to create your own custom entities and model extensions, effectively allowing you to create your own landscape and data abstraction. We will discuss how to create your own custom entities and model extensions in a subsequent blog in this series.
Graph currently supports the OData v4 and GraphQL 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.
As we shall see, OData and GraphQL APIs are easy and powerful 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 Graph are the entities of the business data graph. GrphQL offer a similar experience, with a more intuitive syntax.
Exploring Graph using the Graph Navigator
The Graph of SAP systems is documented by the Graph Navigator on SAP Business Accelerator Hub. Go ahead and follow the link to the Graph Navigator to explore the the full graph of SAP systems. The index, on the left of the application, shows you over 1,500 entities grouped by data source. The first group of entities, in the sap.graph namespace, 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 associations, _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 Graph Navigator to get a sense of what the full SAP-based business data graph looks like.
With this quick introduction out of the way, follow us to the next part of the blog series where we set up Graph in SAP Integration Suite.
________________________________________________________________
Chaim Bendelac, Chief Product Manager – API Management and Graph
Visit Graph on the SAP Community
- SAP Managed Tags:
