Check out the latest Business Central updates!Learn about the key capabilities and features of Dynamics 365 Business Central and experience some of the new features.
Download overview guide | Watch Business Central video
2019 release wave 2 Discover the latest updates and new features to Dynamics 365 planned through March 2020
Release overview guides and videos Release Plan | Preview 2020 Release Wave 1 Timeline
Ace your Dynamics 365 deployment with packaged services delivered by expert consultants. | Explore service offerings
Connect with the ISV success team on the latest roadmap, developer tool for AppSource certification, and ISV community engagements | ISV self-service portal
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance TechTalks | Customer Engagement TechTalks | Upcoming TechTalks
In this blog post, I will talk about a rather crucial topic when you are in the cloud: Telemetry.
Monitoring is not a new concept. When your code is deployed and run at your customer site, there are often needs to monitor what is going on. You might for example need to monitor your application to catch a crash that only reproduces on your customer system. You might also want to know if your code is getting slow. It goes beyond debugging and troubleshooting: does your customer actually uses that extra feature they asked and if so, how often?
In the on prem world, the traditional way to collect this kind of data from your application is by using logging information in a file somewhere on your system and retrieve it for later analysis. But you cannot do that for your Business Central extension deployed in the cloud as I am sure you know, file access is not permitted. Moreover, logging data for each separate system does not give you an aggregate picture. Wouldn’t it be nice for example to know if you have other customers experience the same crash that this one customer reported or to get some statistics on how many of your customers are using a particular feature?
In Telemetry, the prefix ‘tele’ means large distance, so Telemetry = measuring from a distance. Today, modern cloud software is using extensively telemetry in all sort of applications. For example, streaming services such as Netflix or Spotify monitor your usage in order to give you recommendations but also pay copyright fees to content providers. In the automotive industry, leading manufacturers are gathering real-time data from the external sensors of the car and what actions the driver takes in order to feed their AI models and improve their self-driving algorithms.
How could we do that for our BC extensions? As you might expect, in the large collection of Azure services, we can find some technology to help.
Application Insights is a great Azure service that allows you to record various telemetry events emitted by your cloud application. It provides advanced dashboards and visualizations of your telemetry data, and I’ll show you a few example below. You can find an overview of Application Insights here.
For example, if you calling TrackPageView with the name of your page, the Application Insights dashboard shows you that within a few seconds, users have looked at the customer page, the item card page and the customer list.
For each event, you can see the timestamp and the name of the page.
Your app can also send metric data, which are numerical values. This could be for example how many times a user performs a specific action or how long time it takes to run a certain part of your code or any other numerical value of relevance.
In the Application Insights portal, through a powerful point-and-click interface you can build nice graphs to visualize these metrics like this one:
Before we get to that, let’s start by creating the AppInsights service.
This is rather straight forward. In the Azure portal, click on ‘Create a resource’ and search for ‘Application Insights’ and click the ‘Create’ button.
Pick a name for the service, choose ‘General’ for the application type, select a subscription if you have more than one and a resource group and a location in a region near you.
Once you click create, after a few minutes, the Application Insights service is deployed. Click on the service to see the details. What you will need from there is the Instrumentation Key.
This instrumentation key is how you will be able to reference the service from your AL code, so copy it somewhere for later.
But this no API for AL and as you know, .net interop is not possible from an AL extension that you want to publish in the cloud. So we’ll go ahead and create our own Application Insight API for AL.
Here is the trick, no matter which of this platform SDK you use, what really happens under the hood is a REST call. And as Esben in his blog post “How to make friends in the Cloud”, making Web Services calls in AL is very easy.
All Application Insights events are logged to the service by issuing a POST to the URL https://dc.services.visualstudio.com/v2/track. The information of the event is sent in the body of the request in JSON format.
Here are how the JSON should look like for the various type of event.
And finally, for TrackException
Now let see, how we can build these JSON packages in AL. As you can see there are some similarities between these packages, so we can write the code in a generic way passing the variables such as the timestamp and the event baseType as parameters. So, using some JSONObject variables we can build the header:
Then assuming we have the properties and the metrics in some AL dictionaries data types
Finally, once we have built the JSON package, we can issue the REST call using the HttpClient, HttpHeaders, and HttpContent AL API:
So, the complete code for the generic method looks like this:
Now to complete our SDK, we just need to add the specific methods calling this core procedure with the appropriate parameters:
Download the code
Also the Application Insights API has more to offer, this sample implement four of the most relevant methods, but following the same pattern, you can extend this SDK to use more of the capabilities that Application Insights offers.
The complete sample code is available here in the BCTech GitHub repository. It is packaged in a small extension that also includes a test page, where you can emit the various type of telemetry events that the SDK implements. Feel free to download it and use it to instrument your own extension.
Telemetry is a fantastic tool to monitor, troubleshoot, and gain usage insights on your code. Once you start using it, you will feel that you have been living in the dark and you will wonder how you could live without it.
@MBJ, the example code in this post work just as well on-premises. You could potentially also write a version of this in C/Side, as in the end, it all comes down to REST calls. The calls are issued from the server though and at this point, there is no way to log from the client side.
@Richard, you are correct. The way the sample of this post is implemented, REST calls do not run in the background. @David, the documentation refers to the SDK, which does implement a background queuing mechanism. When I wrote this post, I chose to focus on the telemetry and logging aspects and l purposely left out the complexities of background execution. In the future, we might implement more advanced asynch mechanism in AL. If we do, I will revisit this blog or write a new one, so stay tuned :-).
Business Central Web Server instances run on ASP.NET Core and the file Microsoft.ApplicationInsights.AspNetCore.dll is located in the Web Client folder.
How does Microsoft make use of ApplicationInsights from the Web Client and will it be possible to add my own InstrumentationKey on-premise?
@David, I think that's only the case if you use the Application Insights SDK, if you use the REST endpoint you still need to send the event data to that endpoint.
Business Applications communities