Monday, June 25, 2018

D365 Application Insights – Overview

There’s a good chance you’ve heard of Azure Application Insights, but if you’re in the CRM/D365 business there’s a good chance you stopped looking after not too long when you ran across either of these 2 things:
  1. The sample integration which was highlights between Application Insights and Dynamics 365 doesn’t provide a lot of value.
  2. Nearly all the .NET examples rely on an external assembly reference making it’s use in plug-in impossible.
If you were using it you were probably pushing your logging through an Azure Function or some other web service to take advantage of that pre-built assembly. But what they don’t advertise is that telemetry can be logged using simple HTTP requests. That bit of knowledge, some time spent examining the Application Insights JS code on GitHub, and some trial and error make it pretty clear how you can craft your own logging requests and take better advantage of the existing JS implementation to track some data that proves more useful than knowing how many users are still on Internet Explorer 7.

First though, why use Application Insights and not what’s already in D365? Really the only thing there is the plug-in trace log and this has its own shortcomings. No milliseconds, can’t create a record directly so you’d have to push anything from JavaScript through an action / plug-in, etc. Sure, we could model everything that Application Insights has in D365 as entities but then you’d be incurring all that extra overhead instead of offloading it elsewhere. Granted you would have the ability to use workflows for alerting and dashboards and other visualizations but is logging into the same system you are monitoring really a good idea?

Application Insights is a pretty capable logging platform. There are plenty of built in analytics and the ability to connect to Power BI to work with the data in just about any way you want, so long as you’ve captured some useful data. In our case that is data specific to D365. There are several pre-defined types of telemetry data that can be collected but all of them allow custom properties or dimensions as they are also known to be tracked as well. So that opens up the possibility of knowing which user, entity, form, etc. was involved in a log entry. The alerting capabilities give you more than just simply being able to send an email when there is an error but to be a little smarter about it by doing things like analyzing the number of failures over a period of time and only then notifying someone if a threshold is exceeded. Data is kept for 90 days so you can look at things like performance over time. If 90 days isn’t enough there is a continuous export feature to move the data to a different data store. It’s also cheap. $2.30 per month that includes 5GB of data, which is a lot of text. Those things are just scratching the surface, there is so much more beyond what I've described.

Types of telemetry

  • Dependencies – outbound calls to web services, SQL, or whatever
  • Exceptions – errors
  • Traces – messages typically for informational purposes
  • Events – application interactions
  • Metrics – numeric (single or aggregate) measurements
  • Page Views – duration a user stayed on a web page
  • +Others

Custom Dimensions

As I mentioned, additional data can be included along with any log entry in the form of key/value pairs. The values here can be strings, booleans, dates, or numbers.  So now when working with data inside the tools Application Insights provides, it can be queried or acted on just like any of the standard fields.

Custom Measurements

Much like custom dimensions, log entries can also include a set of measurements in the form of key/value pairs. The difference here is that the values must be numeric.

How To Start Logging

There isn’t any magic happening, you only need 3 things to get going.

Once you’ve got these things it’s just a matter of making the HTTP requests. It’s designed to be used from JavaScript so there are no CORS issues to contend with. No authentication to deal with, incoming telemetry is routed to the correct instance based on the Instrumentation Key.
I took what I learned and wrapped it up into a few different packages to facilitate logging:
  • D365AppInsights.Js – JavaScript & TypeScript libraries to log directly from front-end code
  • D365AppInsights – C# source code which can be added to a plug-in or custom workflow projects
  • D365Applnsights Actions – Actions with plug-ins that which can be used from just about anywhere
  • D365Applnsights Workflows – Custom steps to add logging to workflows

All the code is up on GitHub so I’m not going to post it here.

https://github.com/jlattimer/D365AppInsights.Js
https://github.com/jlattimer/D365AppInsights

In the next few posts I’ll dive a little deeper into each of the items.
If you’re in a hurry to use any of this or if I get busy and can’t get to the next post soon I think I’ve down at least a fair job of documenting things on the wiki pages on the respective GitHub sites.

NuGet C# source package
https://www.nuget.org/packages/JLattimer.D365AppInsights/
NuGet JavaScript/TypeScript source package
https://www.nuget.org/packages/JLattimer.D365AppInsights.Js/
Manages solutions for the prebuilt actions and workflow steps
https://github.com/jlattimer/D365AppInsights/releases