In the previous post, Graph on SAP Integration Suite – A Beginners Guide we had touched the most basic scenario of setting up Graph on SAP Integration Suite. We had looked at Mirrored Entities for Sales Order Details with Customer Info extracted using a Single API Call.

If you have read through SAP’s documentation on Graph , especially this section : Unified Entities, you would have realised that Graph provides you ability to connect to APIs from Multiple Systems both SAP and non SAP and get data from multiple systems in a Single API call. While Mirrored Entities deals with 1 System , Unified Entities deals with multiple Systems.

Scenario in Scope

We will explore the same use case as SAP have explained in their documentation. Imagine a Customer / Enterprise landscape where you have a SAP S/4HANA (Public Cloud in my case) and a SAP Cloud for Customer C4C System. As you can imagine Product / Materials are replicated in both these systems. As SAP C4C is also used for After Market Services, lets assume that some fields of the Product are maintained in C4C ( like Warranty Period ) and some are maintained in S/4. What if you wanted to Query the data of both these systems in a Single API call?

In a typical Cloud Integration world on SAP Integration Suite, you will build a API/ Integration Flow that will initially do a GET on the API from S/4Hana Cloud using the Product Master ODATA API and then perform an additional API call to enrich your data using the C4C Product Collection API.

SAP Graph helps you avoid multiple lookups / API calls. SAP Graph lets you create Unified Entities where data / APIs across multiple systems can be unified in a Single API Call.

Scenario for Unified Entities using SPA Graph on Integration Suite


You have followed Part 1 and

  • Enabled Graph on SAP Integration Suite.
  • Creating a Mirrored Graph on SAP Integration Suite
  • Set up Service Instances / Service Keys, and invoked your Business Data Graph as a ODATA API.

Create Destinations on BTP

Create Destination S4_Product

Like we did in Part 1, we will now create Destination for the Product API on S/4Hana Cloud. We have chosen the Authentication mode as Basic Authentication in this Destination as we will use this Graph for System to System Integration.

Create Destination S4_Product for the S/4Hana Product API

Create Destination C4C

Unlike S/4Hana Cloud, C4C exposes all its APIs on a single endpoint /sap/c4c/odata/v1/c4codataapi and hence create a generic destination on BTP for C4C.

Create a Destination C4C for C4C on your SAP BTP SubAccount

Create a New Business Data Graph

We will now create a new Business Data Graph on SAP Integration Suite called s4h-c4c-product.

Create a Business Data Graph called s4h-c4c-product

In this BDG we will select the Data Sources as the 2 Destinations we created in previous section, S4_Product and C4C.

Select the Data Sources as C4C and S4_Product corresponding to the destinations created in previous sections

Let the Model Extension be none.

Skip the Extension

Have a Look at the JSON in the next screen and say Create. You will notice that the leading systems are identified as s4 and c4c automatically. All the APIs have been exposed using Graph.

Leading Systems have been identified as C4C and S4 Automatically.

Test Your Graph using Graph Navigator

Navigate to Graph Navigator and select your BDG just created – s4h-c4c-product.

Test your Graph using Graph Navigator on Integration Suite.

Navigate to the namespace sap.graph of your BDG and you will notice the Product and the association that is now built to _c4c and _s4

Try out your Graph by selecting Try Out and $expand _c4c and _s4

Ideally, you would expect the _c4c section in the image above to show you the C4C Data with the same Product ID :11 in our case. But why is C4C null? Even though the Graph has executed successfully, the Graph has not been able to pull the data from C4C.

Key Mapping on SAP Graph to the rescue

SAP’s documentation explains this here : Enterprise Landscapes and here : Configuration Strategies Key Mapping with a very good examples. In the SAP documentation you can see 2 sections for Key Mapping , a normal mapping of External ID for Individual Customer of C4C to S4 Business Partner and a Translation of Key Mapping for Products.

If you are not the one for theory, thats fine, lets just fix our Graph to have this key mapping. Add the below JSON snippet into your Business Data Graph Configuration in the locatingPolicy section

Note : We make a assumption here that ProductID field of C4C has the same value as your SAP S/4 Product i.e., C4C and S/4 use the same ProductID. If you have a case where they use different ProductID then you can also use ExternalID for the Key Mapping as shown in SAP help documentation.

In my case, we have the same ProductID in C4C and S/4 and hence we use the key Mapping using ProductID of C4C to Product of S/4. Note: C4C has the field “ProductID” and S/4 has the field “Product” as you will see in the JSON below.

"keyMapping": [
                "foreignKey": {
                    "dataSource": "c4c",
                    "entityName": "sap.c4c.ProductCollection",
                    "attributes": [
                "references": {
                    "dataSource": "s4",
                    "entityName": "sap.s4.A_Product",
                    "attributes": [
                "cues": []

Navigate to your Business Data Graph Configuration in SAP Graph, and click on Edit.

Edit your BDG to add the KeyMapping JSON

Add the JSON snippet provided above for keyMapping into the locatingPolicy and then click on Apply Changes and then when prompted click on Update

keyMapping for C4C and S4 ProductID

Test Again

Test Using Graph Navigator

Test your Graph again using Graph Navigator, and you will now notice that the _c4c is also populated with the keyMapping now allowing you to Query the data from both S/4 and C4C in a single API call.

The data that is extracted now has both the _c4c and and _s4 populated as the keyMapping was successful. In addition, the ProductID from C4C and Product from S/4 have the same values and hence my key Mapping got the required data.

The data that is extracted now has both the _c4c and and _s4 populated as the keyMapping was successful. In addition, the ProductID from C4C and Product from S4 have the same values and hence my key Mapping got the required dat

If you have different Product ID in C4C vs S4 you can also use External ID for Key Mapping.

Testing using Postman

Query namespace sap.graph with $expand of unified entities with key Mapping

Mutations and Custom Entities

We have looked at Unified Entities and got a simple use case for Unified Entities operational and working. So far we have looked at a ODATA GET.

What about other operations? Does SAP Graph support POST, PUT and DELETE? Yes – that is supported and that is what is called Mutations in Graph. SAP Graph supports mutations for both Mirrored and Unified Entities. And we will look at the in a subsequent post.

We have so far exposed all our data sets from SAP back end systems into our Graph API. But what if we did not want all these fields exposed? Can we restrict the fields? Can we rename the fields? Of course that is doable , through what SAP Graph calls Custom Entities. Again a topic for later post but with the teaser here!

Final Thoughts

Setting up Graph is extremely straight forward for something as complex as setting up Unified Entities. You can have data that is exposed across multiple systems made available in a single API call as long as you have the Key Mapping set up in your Business Data Graph.

SAP’s Graph On Integration Suite is an extension to existing SAP Graph on BTP Solution and hence most blogs / posts relevant to SAP BTP Graph are also relevant to SAP Integration Suite Graph. If you want to learn further and read more, I would suggest the links in the references. There already are some really good content available from SAP and SAP community for the old SAP BTP Graph Solution that is still relevant for SAP Graph on Integration Suite. In subsequent posts we will also look at SAP Graph Mutations and Custom Entities.