Quantcast
Viewing all articles
Browse latest Browse all 463

Monitoring Dynamics 365 CE service health and messages using the Microsoft Office 365 Service Communications API

Hi Everyone!

Recently I had a conversation with a customer regarding options to monitor Microsoft Dynamics 365 CE service health. In their particular case they needed greater visibility than the Office 365 Admin Center or Office 365 Mobile application provided. I find great value in both of these and as a Dynamics 365 Service Administrator they are very useful. However in some cases users may not have the appropriate role within Office 365 to access these messages and become dependent on someone who does.

Doing a bit of research I stumbled upon the Office 365 Service Communications API. Reviewing this I found that there are two separate endpoints with their own authorization mechanisms, service contracts, etc. resulting in the Office 365 Service Communications API and the preview version of the Office 365 Service Communications API.

The major thing I've seen through my work consuming both of the APIs is one requires an Office 365 Service Administrator or a partner role acting on behalf of (AOBO) for authentication while the other uses OAuth. This means one will use a username and password similar to logging into Office 365 while the other will use a client id and client secret. Discuss this with your application security team to determine what options you have here but I'd suggest the preview endpoint with OAuth per the recommendation given on the original API reference. This article does a good job detailing the steps needed to register your application with Azure Active Directory. In terms of data and events available I have not seen any big difference in the two versions of the API so from here on I will explain the preview API but if you are still interested in the original API I'd suggest reviewing this sample MVC application.

Once you have your authorization token you can now append to any request to the Office 365 Service Communications API. The API is formatted to take a tenant identifier (tenant GUID or tenant name e.g. contoso.onmicrosoft.com) and the operation desired:

https://manage.office.com/api/v1.0/{tenant_identifier}/ServiceComms/{operation}

Here's a sample request for my sandbox tenant:

Request:

GET https://manage.office.com/api/v1.0/contoso.onmicrosoft.com/ServiceComms/Services

Authorization: Bearer <authorization bearer token>

Host: manage.office.com

As you can see your request can be as simple as a GET with the authorization header provided and correct URL. The Services response gives you the current services of all of the Office 365 Applications in the tenant that we can query for additional information. Since this post is focused on Dynamics 365 let's add a filter to the CurrentStatus API call for only Dynamics 365 status:

Request:

GET https://manage.office.com/api/v1.0/contoso.onmicrosoft.com/ServiceComms/CurrentStatus?$filter=Workload%20eq%20'DynamicsCRM'

Authorization: Bearer <authorization bearer token>

Host: manage.office.com

Response Body:

{

"@odata.context":"https://office365servicecomms-prod.cloudapp.net/api/v1.0/contoso.onmicrosoft.com/$metadata#CurrentStatus","value":[

{

"FeatureStatus":[

{

"FeatureDisplayName":"Sign In","FeatureName":"signin","FeatureServiceStatus":"ServiceOperational","FeatureServiceStatusDisplayName":"Normal service"

},{

"FeatureDisplayName":"Sign up and administration","FeatureName":"admin","FeatureServiceStatus":"ServiceOperational","FeatureServiceStatusDisplayName":"Normal service"

},{

"FeatureDisplayName":"Organization access","FeatureName":"orgaccess","FeatureServiceStatus":"ServiceOperational","FeatureServiceStatusDisplayName":"Normal service"

},{

"FeatureDisplayName":"Organization performance","FeatureName":"orgperf","FeatureServiceStatus":"ServiceOperational","FeatureServiceStatusDisplayName":"Normal service"

},{

"FeatureDisplayName":"Components/Features","FeatureName":"crmcomponents","FeatureServiceStatus":"ServiceRestored","FeatureServiceStatusDisplayName":"Service restored"

}

],"Id":"DynamicsCRM","IncidentIds":[

"CR134863"

],"Status":"ServiceRestored","StatusDisplayName":"Service restored","StatusTime":"2018-04-26T19:09:29.3038421Z","Workload":"DynamicsCRM","WorkloadDisplayName":"Dynamics 365"

}

]

}

 

Reviewing this response object I can see the current status of Dynamics 365 and features such as Sign In, Organization Access, Components/Features, etc. by referencing the FeatureServiceStatusDisplayName property. In this response we can see that the current status of Dynamics 365 is 'Service Restored' and the specific feature affected is 'Component / Features'.

If we want to gain some historical perspective on how long this feature may have been affected we can use the HistoricalStatus as shown:

Request:

GET https://manage.office.com/api/v1.0/contoso.onmicrosoft.com/ServiceComms/HistoricalStatus?$filter=Workload%20eq%20'DynamicsCRM'

Authorization: Bearer <authorization bearer token>

For the sake of the length of this article I'll exclude the response but within the response you'll see a smiliar contract as the CurrentStatus response showing the status of the Dynamics 365 features over a period of time including a Message Center identifier which can be used for our final method call today, GetMessages. GetMessages returns the title, description, message text, impact date, affected tenants, message id, etc. This method is highly beneficial in many ways: I can review messages for current outages, I can review messages for planned maintenance, I can filter messages based on a combination of message identifiers, features, area of interest, time frame, etc.

Here's a reference of sample requests to help you filter by specific criteria:

Requests:

Filter by Id:

https://manage.office.com/api/v1.0/contoso.onmicrosoft.com/ServiceComms/Messages?$filter=Id%20eq%20'CR133521'

Filter by Message Center:

https://manage.office.com/api/v1.0/contoso.onmicrosoft.com/ServiceComms/Messages?$filter=MessageType%20eq%20Microsoft.Office365ServiceComms.ExposedContracts.MessageType'MessageCenter'

Incidents:

https://manage.office.com/api/v1.0/contoso.onmicrosoft.com/ServiceComms/Messages?$filter=MessageType%20eq%20Microsoft.Office365ServiceComms.ExposedContracts.MessageType'Incident'

Planned Maintenance:

https://manage.office.com/api/v1.0/contoso.onmicrosoft.com/ServiceComms/Messages?$filter=MessageType%20eq%20Microsoft.Office365ServiceComms.ExposedContracts.MessageType'PlannedMaintenance'

Filter By Start Time and End Time:

https://manage.office.com/api/v1.0/contoso.onmicrosoft.com/ServiceComms/Messages?$filter=StartTime%20ge%202018-04-23T00:00:00Z&EndTime%20le%202018-04-28T00:00:00Z

Filter by Workload:

https://manage.office.com/api/v1.0/contoso.onmicrosoft.com/ServiceComms/Messages?$filter=Workload%20eq%20'DynamicsCRM'

At this point you have an API to give you the current status of Dynamics 365 and its features, information on how long a potential degradation may have impacted your tenant and the ability to plan for planned updates and maintenance performed on the application. Look ahead for my next blog post detailing how to schedule a workflow to consume the API and send an email reporting current status and messages to a single user or a distribution list using Microsoft Flow!

References:

Get started with Office 365 Management APIs

About Office 365 Admin Roles

Office 365 Service Communications API Overview

Office 365 Service Communications API Sample Code

Office 365 Service Communications API Overview (preview)

Thanks and happy coding!

Ali Youssefi

 


Viewing all articles
Browse latest Browse all 463

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>