You’ve heard about the SAP Graph announcement at SAP TechEd Las Vegas 2019. Well there’s also Microsoft Graph which is awesome and very similar (philosophically + technically) and not only is it super useful, but I’m going to give you a working example / tutorial with Microsoft Graph so you can get to know it, and, as a by-product, understand how SAP Graph will work for you too.
So, why do I blog about Microsoft Graph? Yep, I’m a Developer Advocate and I’m with SAP. So at first sight, there’s no actual overlap between Microsoft Graph and my primary task, advocating for developers in the SAP ecosphere. But there is without any doubt an overlap. Microsoft Graph API can propagate data which is super often related to data in SAP systems. Conversations in Microsoft Outlook about Purchase Orders (handled in your SAP System), Invoice Files on Microsoft Sharepoint to actual Invoices (handled in your SAP System) – just to outline two common circumstances.
What does that bring to SAP developers? Combining SAP data and Microsoft Office365 data leveraging their APIs makes sense. Why? To rapidly ease work routines of employees/end customers or speed up business processes is a significant reason. I hope I can shed some light on this assertion.
What is Microsoft Graph?
At its heart, Microsoft Graph is an API. That API can simply be used to access data in Microsoft Office365. First of all: Yes, the name may be misleading at first sight. It has nothing to do with actual graphs, nor with GraphQL (Graph Query Language, blog post by DJ Adams ). Rather, it is a one-stop-shop to access data of a variety of Microsoft Office365 tools or Azure functionalities. Technically one would probably call it API Gateway. The term Graph here is more related to navigating through Entities and Objects in the Microsoft Office365 and Azure enterprise. Because Microsoft has embraced the OData Procotol as SAP does, data returned by the Microsoft Graph API can be seamlessly consumed by SAPUI5/Fiori.
I want to give you a concrete and comprehensible example that you can build yourself afterward.
Your S/4HANA system lists purchase orders with all kinds of approval features. At the same time, there are conversations in Microsoft Outlook between your colleagues or possible external ones about exactly these said purchase orders. For example, the recipient’s shipping address has changed and this has been communicated again by e-mail. Normally, the processor of the purchase order would either not search for it in their mails or would have to perform the following steps manually:
1) Open Purchase Orders UI in S/4HANA
2) Copy purchase order information from SAP UI, for example, Order ID.
3) Open Microsoft Outlook 365 (other UI/Look&Feel, another Tab, etc.)
4) Search manually for Order ID in Outlook
5) Compare the information in SAP UI (other UI/Look&Feel, another tab, etc.)
Steps 2-4 may be repeated as often as required. You can do it, but you don’t have to. There are less time-consuming ways. Because with the Microsoft Graph API the integration of Microsoft Office365 tools is seamlessly possible.
So, following the approach to keep the core clean, we leverage the API behind the already mentioned purchase orders list in your S/4HANA system to fetch the data on the SAP Cloud Platform. That doesn’t necessarily have to be a S/4HANA Cloud system, as long there’s an OData service provided – on-premises or in the cloud is entirely irrelevant thanks to the SAP Cloud Connector.
A SAPUI5 application hosted on the SAP Cloud Platform takes the Purchase Order OData service (SAP API Business Hub example) and lists the purchase orders, as usual, leveraging simple SAPUI5 components.
The identified mails are then displayed in the same SAPUI5 app. Only displayed, not replicated. The information remains in the original system. The Microsoft Graph API also works in realtime, so no delays are to be expected. So you have all the information at a glance without having to bother searching manually in different browser windows/tabs and possibly losing track of it.
This is just a very basic reproducible example to showcase how a certain scenario could look like. A more realistic scenario: When somebody clicks on a purchase order, in addition to the detailed view, values of predefined attributes are automatically used to search not only in Microsoft Outlook but also access information in Microsoft Sharepoint and Microsoft Planner and displayed in the same overview – without further action by the user.
So: You have some initial thoughts but don’t know how and where to get started? Then try our tutorial, in which you can easily rebuild the scenario described above:
How about security?
First Things First: Only you have access to your data. The Microsoft Graph API acts on behalf of your user and not with a general technical user. This means that only you can access your data. And user xyz only accesses the data of xyz – all of that realized through the well known OAuth 2.0 authentication method. Without digressing too much:
SAP Cloud Platform Cloud Foundry is also using OAuth2 as the authentication method. In most cases, if there’s an Microsoft Office365 subscription you would also already have a configured Azure Active Directory in place, you can use it either as the primary Identity Provider in the SAP Cloud Platform Identity Authentication Service. Thus you get all the benefits from Azure AD not only in SAP Cloud Platform and its applications but e.g. also in connected SAP SaaS solutions. The above example would then work with a single login mechanism. Authenticate against SAP Cloud Platform and it’s secured SAPUI5 application AND Microsoft Graph (with your user!) at the same time. Just to give you a glimpse about how Security and Azure AD in conjunction with SAP Cloud Platform works.
How to set Azure AD as an Identity Provider in an SAP Cloud Platform Cloud Foundry subaccount is described in this tutorial: https://developers.sap.com/tutorials/cp-azure-ad-saml.html
Microsoft Graph, SAP Graph?
Yeah, sometimes confusing, but: Even though Microsoft Graph and SAP Graph are following the same goals and same approach, there are two different environments. Two different vendors. Both of them focus on giving easy access to data spread across different services and backends.
graph.sap: “SAP Graph is the easy-to-use API for the data of the Intelligent Enterprise from SAP. It provides an intuitive programming model that you can use to easily build new extensions and applications using SAP data.”
You should hopefully now be able to differentiate between SAP Graph and Microsoft Graph if you were following this blog thoroughly. Otherwise, Jan Schaffner (Head of Central Engineering at SAP) will give you some more insights here: SAP TechEd Live interview.
- Microsoft Graph API gives access to a variety of Microsoft Office365 data
- Microsoft Graph API comes for free
- Microsoft Graph API works in realtime
- Microsoft Graph API <3 OData <3 SAPUI5
- Combination of SAP + Microsoft Office365 data is incredibly powerful!
If you want to get started, there are a couple of links beside the already mentioned tutorial which I’d like to highly recommend:
- Microsoft Graph overview: https://docs.microsoft.com/en-us/graph/
all sort of information (SDKs, Blogs, etc.)
- Microsoft Graph Explorer: https://developer.microsoft.com/en-us/graph/graph-explorer
similar experience as the SAP API Business Hub, sandbox to jumpstart without any user