@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.

@David That's great, think I missed that part :) Thanks!

Great article Vincent. In answer to Richard Robberse: According to the docs the Application insights tracking calls are non-blocking, and are batched and sent in a separate thread. So there is no need to do this with a table.

@Morten: The code sample will also work on-premise. Potentially you could also do the same thing from C/Side. In the end it all comes down to REST calls.

@Richard: The code is available on the BCTech GitHub repository. It would be great to have it evolved to a community managed SDK. Feel free to submit pull requests :-).

Ill suggest Microsoft to enable Application Insights support for the Dynamics NAV Service Tier on-premise. Great value of information to have before migration to the cloud.

Great post Vincent and thanks for sharing :)

Wouldn't it be better to buffer those events in a table and let a background task take care of the processing to make sure that users are never blocked by event tracking?

What about making this into a real SDK that could be managed by the community?