Tag Archives: WebAPI

Read Office 365 Message Centre using Office 365 Management API

Published / by AK / Leave a Comment

I started my career as a web developer. Since then it is one of the best decision I have ever taken. Web has been evolving and because of it, low code platforms like Microsoft Flow makes our life a lot easier. In this post, I am going to show you how to read messages from Office 365 Message Centre using its API.

Office 365 Management API is well documented at https://docs.microsoft.com/en-us/office/office-365-management-api/office-365-management-apis-overview

Since it is web api, Microsoft Flow can easily make HTTP request and parse the response. To do it, let’s register an app in Azure Portal first. As we are going to use it from Microsoft Flow, you need to create Web App / Api type application. Another point is to grant the correct permission to the app. Its permission should be set as below.

Permissions to read messages

Permissions to read messages

Ensure you click Grant Permissions after choosing correct permissions. Otherwise, the authroisation will fail.

After this, the rest is quite straight forward. I have created the following Flow. In general, it will

  1. read the last message time from my Google sheet
  2. check the value of last message time. It sets the correct StartTime condition in HTTP step so we won’t be retrieving same messages over and over again.
  3. parse the data and insert into my Google sheet
Message Centre Flow

Message Centre Flow

HTTP request step is setup as below. It is quite straightforward. Please note we need to filter StartTime properly.

Office 365 Management API HTTP Request

Office 365 Management API HTTP Request

Once the Flow is executed, all messages are nicely inserted into my Google sheet.

Messages in Google Sheet

Messages in Google Sheet

This is all because of the power of Web. Of course, Microsoft Flow makes things easier. That’s all for now.

Passing current login user of Microsoft Dynamics CRM Portal to external web app

Published / by AK / Leave a Comment

You can get the detail of current login user in liquid template va user liquid object. There is another way you can get the current login user via XHR call.

Microsoft CRM Portal has built-in API to generate JWT of current login user. The API is at https://<crm portal url>/_services/auth/token and returns JWT. This JWT is nothing but a JSON object encrypted using RS256 algorithm. So, anyone can decode it. Other words, anyone can encode it also.

You sometimes need to pass the current login user information to external web app. Since it takes very little effort to generate a JWT and pass it to your external website, it is very easy to bypass the security. Therefore, you will definitely want to verify the authenticity of generated token too ensure the token is generated from trusted source (in this case, your CRM portal).

The beauty with JWT is you can verify the signature of token using public key. If you are not familiar with PKI, the process generally involves the source or CRM portal which generates a token using its private key (which is already handled in CRM portal), and the target or your external web app which verifies the authenticity of the token using public key. To do this, get  the public key of your CRM portal at https://<crm portal url>/_services/auth/publickey.

The order of the whole process is

  1. Pass JWT token as a parameter in a web request/link to your external web app
  2. In your external web app, get public key from CRM portal and verify the signature of the JWT contained in web request

That’s easy, simple and neat. Right?

Next time, we will have a look at Azure AD B2C configuration to authenticate users, which requires more configurations and adds a little bit of complexity.

Accessing Dynamics 365 WebAPI as an application user without using ADAL

Published / by AK / Leave a Comment

Microsoft has recently posted the documentation for using Postman with Dynamics 365 WebAPI at https://docs.microsoft.com/en-us/dynamics365/customer-engagement/developer/webapi/use-postman-web-api. This prompts you to login into the application using your credentials to generate a bearer token which is passed to Dynamics 365 WebAPI when a request is made.

However, we, sometimes, need to use an application user to access WebAPI, either for integration testing purpose or for implementing automations. Microsoft has documented server-to-server (S2S) authentication using Azure Active Directory Authentication Libraries (ADAL) at https://docs.microsoft.com/en-us/dynamics365/customer-engagement/developer/walkthrough-multi-tenant-server-server-authentication.

Although I am a developer, I strongly believe we can (should) write a program only when a process can be manually done. Therefore, tools like Fiddler, SoapUI, Postman are essential tools to me when it comes to testing WebAPIs.

Now, I will show you how we can generate an access token using an application user in Postman, assuming you have already created an application user. If you need detail steps to create an application user, please follow instructions at https://docs.microsoft.com/en-us/dynamics365/customer-engagement/developer/walkthrough-multi-tenant-server-server-authentication.

In Postman, let’s create a few Postman environment variables.

  • TenantId – to store GUID of Azure Directory ID
  • D365Url – to store the URL of Dynamics 365 instance
  • D365AppId – to store Azure Application Id
  • D365AppSecret – to store Application secret
  • D365Bearer Token – to store generated access token
Environment variables

Environment variables

Then, let’s create a new POST request to https://login.microsoftonline.com/{{TenantId}}/oauth2/token with following data.

Token request

Token request

Now, send a request and it should return an access token (assuming an application user has been correctly setup).

Access Token

Access Token

Now, we need to store the access token to our Postman environment variable called D365BearerToken so that we can re-use it accessing Dynamics 365 WebAPIs. To do this, we need to write a simple script under Tests area.

Writing tests

Writing tests

Pretty easy, right? Now, let’s create another GET request to retrieve the version number of Dynamics 365 instance. The request’s authorization type should be set to ‘Bearer Token’ and its token value should refer to our Postman environment variable D365BearerToken.

Retrieve version

Retrieve version

Now, you can test any WebAPI calls using an application user without relying on ADAL.

What’s next?

Using the same approach, you are not limited to Dynamics 365 ODataQuery in Flow/LogicApps. You can now call any Dynamics 365 Messages using the same approach and perform various tasks.