Skip to Content
Technical Articles
Author's profile photo Showkath Ali Naseem

SAP BTP Integration with Microsoft Azure

Introduction

 

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. 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(https://developer.microsoft.com/en-us/graph/blogs/upcoming-changes-to-exchange-web-services-ews-api-for-office-365/)

 

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

 

https://docs.microsoft.com/en-us/azure/active-directory/develop/authentication-flows-app-scenarios

Get access on behalf of a signed-in user

Get access without a 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  https://docs.microsoft.com/en-us/graph/auth-register-app-v2

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

Destination:

Name= name of connection

Type = HTTP

URL = https://graph.microsoft.com/

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 = https://login.microsoftonline.com/<tenantid> /oauth2/v2.0/token

Additional Properties

scope

https://graph.microsoft.com/.default

Screenshot

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”);

 

 Advantages

 

  • 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

 

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 https://login.microsoftonline.com (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 : https://blogs.sap.com/2018/10/08/using-the-destination-service-in-the-cloud-foundry-environment/

 

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

Assigned tags

      Be the first to leave a comment
      You must be Logged on to comment or reply to a post.