One of the things we get asked about rather often at Office365Mon.Com and AzureServiceMon.Com is how to do custom alerts and other workflow scenarios when an outage or some other interesting thing happens – maybe the version of your SharePoint Online tenant changes, you aren’t getting any search results in your tenant, etc. We’ve had a webhook feature for some time that was designed specifically to allow customers to address these one-off custom scenarios, but previously have always talked about it as writing some custom code and web site to process it. Now, based on yet another great suggestion from one of our truly brilliant customers, we’ve put together some information on how you can do all of that without writing any code at all! Instead we’re going to use the graphical workflow designer in Microsoft Flow.
NOTE: If you want to see a video of this whole process, check out our YouTube recording of this here: https://www.youtube.com/watch?v=GoK8LiTMd7o.
To begin with, go to the Microsoft Flow site here: https://flow.microsoft.com. Click on My Flows to see the Flows you have and/or design new ones:
Once you get into your flows, we’ll click on Create from blank to create our new Flow:
When you create a new Flow, we’re going to look for an Http Request connector. The webhook fires as a simple HTTP request with some JSON. To begin, click on Search Connectors:
Search for “http request” and click on Request – When an HTTP Request is received in the search results:
The next thing that’s going to happen is that it will ask you for the schema of the JSON that’s going to be sent over in the Http request. We’ve put that together for you, but it is subject to change over time as we add new monitoring features. We’ll never break any existing schema, but we may add to it. As of today you can copy and paste the following JSON schema into the JSON Schema edit box; alternatively you may want to download from our web site at https://office365mon.com/webhookschema.txt because the formatting in the blog will likely get you all messed up:
{
“type”: “object”,
“properties”: {
“SubscriptionId”: {
“type”: “string”
},
“CompanyName”: {
“type”: “string”
},
“WebhookNotificationType”: {
“type”: “number”
},
“NotificationOutageInfo”: {
“type”: “object”,
“properties”: {
“Resource”: {
“type”: “string”
},
“ResourceType”: {
“type”: “number”
},
“OutageNotificationType”: {
“type”: “number”
},
“DistributedProbeHostName”: {
“type”: “string”
}
}
},
“NotificationServiceStatusInfo”: {
“type”: “object”,
“properties”: {
“ServiceName”: {
“type”: “string”
},
“FeatureName”: {
“type”: “string”
},
“CurrentStatus”: {
“type”: “string”
},
“PreviousStatus”: {
“type”: “string”
}
}
},
“NotificationQueryInfo”: {
“type”: “object”,
“properties”: {
“Resource”: {
“type”: “string”
},
“NumResults”: {
“type”: “number”
},
“Results”: {
“type”: “string”
}
}
},
“NotificationLongRunningProbeInfo”: {
“type”: “object”,
“properties”: {
“DistributedProbeHostName”: {
“type”: “string”
},
“Duration”: {
“type”: “number”
},
“Threshold”: {
“type”: “number”
}
}
},
“NotificationVersionInfo”: {
“type”: “object”,
“properties”: {
“OldVersion”: {
“type”: “string”
},
“NewVersion”: {
“type”: “string”
},
“ResourceType”: {
“type”: “number”
},
“ResourceAddress”: {
“type”: “string”
}
}
},
“NotificationOfflineHostInfo”: {
“type”: “object”,
“properties”: {
“DistributedProbeHostName”: {
“type”: “string”
},
“LastProbeTime”: {
“type”: “string”
},
“MaxOfflineTime”: {
“type”: “number”
}
}
},
“NotificationMailTransportInfo”: {
“type”: “object”,
“properties”: {
“TimeSent”: {
“type”: “string”
},
“MinutesToDeliver”: {
“type”: “number”
},
“DelayInformationType”: {
“type”: “number”
}
}
},
“NotificationMonitoredListInfo”: {
“type”: “object”,
“properties”: {
“ListName”: {
“type”: “string”
},
“SiteAddress”: {
“type”: “string”
},
“MaxListSize”: {
“type”: “number”
},
“ActualListSize”: {
“type”: “number”
},
“MaxRenderTime”: {
“type”: “number”
},
“ActualRenderTime”: {
“type”: “number”
}
}
},
“NotificationAzureMetricAlertInfo”: {
“type”: “object”,
“properties”: {
“ResourceName”: {
“type”: “string”
},
“ResourceId”: {
“type”: “string”
},
“AzureSubscriptionId”: {
“type”: “string”
},
“MetricFriendlyPropertyName”: {
“type”: “string”
},
“MetricInternalPropertyName”: {
“type”: “string”
},
“MetricValue”: {
“type”: “number”
},
“MetricAlertValue”: {
“type”: “number”
}
}
}
}
}
Once you’ve pasted the JSON schema in, we can now focus on this scenario using the data provided in the webhook. We want to route an email message to a different group depending upon which type of resource triggers an outage notification. To start that part of the Flow, click the New step button, then click Add a Condition:
In the Condition widget, click in the Choose A Value field and select the WebhookNotificationType field from the JSON schema:
For this scenario – to route messages to different groups when an outage occurs – create the condition for when WebhookNotificationType equals 1, which is an outage:
In the If Yes widget, click the “…More” link and select the Add Condition. This is how we’ll select which type of resource created the outage notification, and send an email to the appropriate group in our organization:
In the Condition 2 widget, select ResourceType from the JSON schema fields. It’s worth noting that the schema displayed below doesn’t distinguish between which data type the fields belong to. For example, if you look at the JSON schema provided, you’ll see that both the NotificationOutageInfo and NotificationVersionInfo objects have a ResourceType property. While I didn’t see a clear way to distinguish between them when using Flow’s designer, you can always export the Flow when you’re done. It includes the fully-qualified property names so you can ensure you selected the right object. For this particular scenario, I recommend just selecting the first item in the list when it appears more than once. That’s because the schema describes the fields for outage info first. Here’s what the Flow designer looks like as you add this condition:
Now you can set the value according to how you want to route outage messages. For example, a ResourceType of 0 equals SharePoint Online, a ResourceType of 1 equals Exchange Online, and so on. The entire list of possible ResourceType values is documented in our Subscription Management SDK, which you can download from https://www.office365mon.com/Office365Mon_Subscription_Management_API.pdf. Here’s the completed condition for the case when the outage notification is for SharePoint Online:
Now you can add an action to send a message to the appropriate group when it is a SharePoint Online outage. To do that, begin by clicking the Add an action link:
Click the Send an email action:
Now you can fill out all the details of the email that should be sent when a SharePoint Online outage occurs:
When you’re creating the content for the email, you can plug in values from the JSON that is sent over. Here we’ll add the name of the Office365Mon subscription that triggered this notification; the subscription name is kept in the Company Name field:
In the body of the email, we’ll include all the details that are sent over in the JSON. They may not all have values – for example DistributedProbeHostName will be empty if the outage notification is coming from one of our cloud probes instead of one of our Distributed Probe agents – but they will all have some kind of value no matter what, even if it is blank.
Here’s an example of the completed email:
Once that’s filled out, we can click the “…More” link at the bottom again, and create another branch for an Exchange Online outage, etc.:
We can keep going this way until we’ve covered all our scenarios. For any other cases where we don’t have a specific group to route to, on the last condition we can have the “If no” condition send an email to a general support alias.
When you’re done, click the Create flow link at the top to save your changes.
Once the flow is saved, you will finally get the Url that the Flow will be “listening” on for webhooks. You need to copy this Url into the webhook property of each Office365Mon or AzureServiceMon subscription you want to use it on. To find the Url, click the widget for the Http Request trigger at the top that was used to start this Flow:
When you do that, you’ll see the HTTP POST URL property, which is the Url that the JSON from the webhook will go to; copy it and paste into your Office365Mon subscription:
Now at Office365Mon or AzureServiceMon, you can paste in the Url. For Office365Mon.Com go to https://www.office365mon.com/Signup/SignIn; for AzureServiceMon go to https://azureservicemon.com/Configure/AzureCore. Scroll down to the Notification Info section and plug the Url into the Webhook Address field:
After you click the Update button it will be saved and we’ll start sending data over to the Flow whenever a notification fires. You can still have other email addresses to which we’ll send out notifications – it’s totally up to you. You can (and should) also click the Test button, and we’ll send a quick webhook and let you know if it arrived successfully or not.
Once you’ve done that, go back to the Flow designer tab in your browser and click the Done link to finish up your Flow:
After you do that, you can see all the instances where your Flow was invoked, i.e. when Office365Mon or AzureServiceMon sent over a notification for things like an Azure availability monitoring issue, an Azure metric monitoring alert, a SharePoint Online version change, Exchange Online outage, etc, etc, etc.
If you click on any of them, you can see how they were processed. The first on at the bottom was added when I clicked the Test button for the webhook in the Office365Mon site. The WebhookNotificationType for it was 0, so none of the conditions for firing our Flow were met. The second one though fired when there was a SharePoint Online outage starting. By drilling into it we can see the details of how the Flow was processed:
When you look at the “Send an email” widget at the bottom, you can see the values that came over from the JSON as they were plugged into the email template we created.
That’s it – that’s the whole process. Not a single line of code was written. After you spend a few minutes getting used to Flow, it will literally only take you a few minutes to write workflows like this. It gives you a very powerful way to connect important Azure availability monitoring and Office 365 monitoring data into any kind of workflow that’s important to your business.
I hope you all find this useful. Again, many thanks to the awesome customer of ours that suggested this approach. As always, start out at https://azureservicemon.com or https://office365mon.com and create a new monitoring subscription, and then the rest is all downhill.
From Sunny Phoenix,
Steve
Share-n-Dipity 