Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
Showing results for 
Search instead for 
Did you mean: 
Product and Topic Expert
Product and Topic Expert


Note : With this blogpost approach, You no need to  Add Azure AD as Identity Provider in the 
SAP BTP, Cloud Foundry environment account i.e Integrate Microsoft Azure AD with SAP BTP, Cloud Foundry environment

This blog post covers Usecase how easily( i.e with very less development effort)  & efficiently Interact with Windows 10, and Enterprise Mobility and Security services in Microsoft 365 products using Microsoft Graph in your business application running SAP Business technlogy Platform (BTP) in scenario without immediate interaction with a user i.e call Microsoft Graph with not on behalf of a user , this Blog post approach you use , when user authorization not required to access resources i.e it is like a technical user/service user approach without the presence of a signed-in user. These types of applications are often referred to as daemons or service accounts. These apps call Microsoft Graph with their own identity and not on behalf of a user. In many cases, these are background services or daemons that run on a server without the presence of a signed-in user. With this blogpost approach we can avoid lot of Boilerplate code Integration of MS Azure & SAP Business technlogy Platform (BTP) to get an authentication token from Azure AD using the OAuth 2.0 client credentials grant flow

Your business application has requirements like sending acknowledge/confirmation email, monitor an application anonymous mailbox, Creating/Updating a calendar event, creating an teams ,MS-Teams online meeting , an email service runs overnight, your company migrated all users to Office 365 (Microsoft 365)

The preferred (new) way for interacting with Microsoft 365 programmatically is by using the Microsoft Graph

You can read here news about deprecation of older techniques(


Microsoft Graph enables you to integrate & interact with the best of Microsoft 365 products, Windows 10, and Enterprise Mobility and Security services in Microsoft 365, using REST APIs and client libraries.

Microsoft Graph exposes REST APIs and client libraries to access data on the following Microsoft cloud services:

  • Microsoft 365 core services: Bookings, Calendar, Delve, Excel, Microsoft 365 compliance eDiscovery, Microsoft Search, OneDrive, OneNote, Outlook/Exchange, People (Outlook contacts), Planner, SharePoint, Teams, To Do, Workplace Analytics.

  • The Microsoft identity platform supports different authentication types based on your business application architectures requirements

You can read here Microsoft recommendations for these app architectures:

WebApp, Mobile Apps, Desktop Apps, Web Apps, Daemon apps, Server-side apps


To Get access on behalf of a signed-in user (SSO) 

Please follow my other blogpost

Get access without a user(Technical User)


Tokens can also be acquired by apps running on devices that don't have a browser or are running on the Internet of Things (IoT)

You can read here Authentication and authorization basics for Microsoft Graph

Follow Best Practise for consent and authorization in your application:

As a developer, you decide which permissions to request for Microsoft Graph, What is type of application & then request to App in Azure AD .

Usually your organization Azure Admin will take care of creating app & giving scopes are per your application architecture requirements)


Solution – Efficient Approach

1. Azure Admin responsibilities


Ask your organization Azure Account Admin to Register your application  & Configure permissions for Microsoft Graph on your application  in Azure portal as mentioned in

Generally every company would have one Azure Admin & process defined to take care of App         Registration in Azure AD, Configure Graph API Scopes for your application Usecase so follow your organization process


2. SAP BTP Subaccount Admin/Space Admin responsibilities


SAP BTP provides the Destination Service, using which your application can reach to any other cloud service or system or SAP S/4HANA Cloud tenant. In our case we are going to use Destination Service to connect to  Microsoft 365  via Microsoft Graph

Ask your SAP BTP Subaccount Admin /Space Admin to create destination as described in this blog post


Name= name of connection

Type = HTTP


Type = Internet

Authentication = OAuth2ClientCredentials

                      <Chose as per your business application architecture>

Client ID =<Ask your Azure AD Admin>

Client Secret = <Ask your Azure AD Admin>

Token Service URL =<tenantid>; /oauth2/v2.0/token

Additional Properties



Your Azure App Configuration details acquired from your Azure Admin (Pre-Requisites-1 )






3. As a Developer


Use the SAP Cloud SDK  which can reduce your effort when developing an application on SAP Business Technology Platform by building on best practices delivered by the SAP Cloud SDK. The SAP Cloud SDK provides Java libraries, JavaScript libraries, project templates, and a continuous delivery toolkit.

SAP Cloud SDK comes with two variants—one for Java and one for JavaScript/Type-Script—and provides libraries, project templates, and a continuous delivery pipeline that you can use immediately.

Dependent on your application architecture choose either

Cloud SDK for Java

Cloud SDK for JavaScript (Node.js)


  • With the SAP Cloud SDK, you can get the result in a single line of code by using the Destination Accessor class of the SDK that gives you an instance of the SAP BTP destination service


HttpClient httpClient = HttpClientAccessor.getHttpClient(DestinationAccessor.getDestination(connectionName).asHttp());


Here connection Name is Destination Name you can get from your BTP CF Space Admin/Subaccount Admin


  • Then to call a Microsoft Graph API resource

Your resource URL will include the resource you are interacting with in the request, such as me, usergroupdrive, and site & to access additional resources, like me/messages or me/drive, me/sendMail


HttpDestination destination = DestinationAccessor.getDestination(connectionName).asHttp();

HttpUriRequest request = new HttpGet(destination.getUri()+"v1.0/Users/{id}/sendMail");




  • Reduced lot of Boilerplate code required for Integration

  • As code becomes less then less maintenance cost

  • Seamless Integration

  • Totally Security:

  • Allow to change configure in different environments (DEV, QA,PROD) for different SCP accounts without touching your code

  • In Built Quality

  • Less Total Cost Ownership (TCO) will become less if MS 365 Azure integration is requirement for one more than one application then every application needs to perform manual steps stated in “Manual Approach Section”

  • Re-Usability

  • Less Technical Debt

  • High Scalability

  • Note : With this blogpost approach  ,you no need to  Add Azure AD as Identity Provider in the SAP BTP, Cloud Foundry environment account to Integrate Microsoft Azure AD with SAP BTP, Cloud Foundry environment


In this document I also would like to briefly write about other approach as a Developer we have to take care below Manual Steps. In this Manual approach we have to take care lot of low-level integration & boot strapping.



Manual Approach:

To use Microsoft Graph to read and write resources on behalf of a user, your app must get an access token from the Microsoft identity platform and attach the token to requests that it sends to Microsoft Graph


  1. POST HTTP Call to (oauth2/v2.0/token) to get an access token

  2. To achieve Step1 in Java application generally we either use org.springframework.web.client.RestTemplate & store Azure Configuration in Yaml file

  3. That is, to call an external system, you construct the HTTP request manually by adding the respective headers and security information manually.

  4. Parse Token Response & read Access Token

  5. Then to call a Microsoft Graph API Azure you attach the access token as a Bearer token to the Authorization header in an HTTP request


Note: Here as a security best practise we should not hardcoded-url

In general, applications shouldn’t be hardwired to resources (like text files or database systems), but be rather coupled loosely to them. Backing services are the best practice to couple resources to applications running in Cloud Foundry environments. Therefore, SAP encapsulates the necessary business logic and the persistence layer for those tasks and makes it easy to consume as a backing service (Destination service).

Reference :


Or To securely store Azure configuration in Database we must write code to store & retrieve in Database, Similarly if we choose  Configuration in Azure Pass vault also we must write code/ With this blog approach we can avoid lot of Boilerplate code



To use the destination service, you must carry out the following steps:


  1. Retrieve login credentials from environment variables stored in the destination service.

  2. Using these login credentials, generate a JSON web token (JWT) through the SAP BTP user account and authentication (UAA). Add this JSON web token to the HTTP request header for authentication.

  3. Formulate the service endpoint you wish to call and send the HTTP request.

  4. to call an Microsoft 365 you construct the HTTP request manually by adding the respective headers and security information manually

  5. you also need to perform all tasks related to the handling of the HTTP request such as building the request URL

  6. Establishing the connection

  7. Handling the response and parsing it.


Notes & References:

Microsoft Azure is enterprise cloud platform. Microsoft 365 which is a software as a service (SaaS) product, Microsoft 365 uses Azure Active Directory (Azure AD) to manage user identities behind the scenes. Your Microsoft 365 subscription includes a free Azure AD subscription