Dynamics 365 Business Central, Azure Functions and telemetries: best practices

Last week at DynamicsMinds conference, after my session about Azure Functions I’ve received an interesting question: in a context of a Dynamics 365 Business Central project, when using Azure Functions for handling integration tasks for this project, what are the best practices for handling functions telemetries? Should we send telemetry data to dedicated Application Insights instances or not?

The scenarios are essentially the following:

Scenario 1: Dynamics 365 Business Central is connected to an Application Insights instance and the Azure Functions app are connected to another dedicated Application Insights instance:

Scenario 2: Dynamics 365 Business Central and Azure Functions apps share the same Application Insights instance:

Both scenarios are absolutely valid. But in my opinion there’s a key aspect to evaluate for a Dynamics 365 Business Central project perspective: if you want to monitor what happens in a business scenario where you have:

Business processes handled in AL internally to Dynamics 365 Business Central
Business processes that calls Azure Functions for performing integration tasks of for executing custom code in the cloud
Scheduled tasks that calls Azure Functions
Azure Functions that reads/writes data to Dynamics 365 Business Central or starts business tasks inside the ERP

then the Scenario 2 is what I prefer and what I recommend. In this scenario you can have all telemetries of your business processes shared to the same Application Insights instance and you can monitor an entire process using a single telemetry store, simply by using KQL or the standard Microsoft Power BI app for telemetry.

When using Azure Functions with Application Insights, it’s also important to remember that I always recommend to inject also custom signals from the Azure Function code. This permits you to query the customEvents table and then retrieve all your custom logs (extremely useful for troubleshooting a business process):

There’s a Functions-specific version of the Application Insights SDK that you can use to send custom telemetry data from your functions to Application Insights: Microsoft.Azure.WebJobs.Logging.ApplicationInsights.

The following code shows how you can do that:

You can also use the TrackException method to log exceptions (recommended).

When you connect an Azure Function to Application Insights, you can also query the requests table to inspect the incoming requests to your function apps:

requests
| where timestamp > ago(30m) 
| summarize count() by cloud_RoleInstance, bin(timestamp, 1m)

This is often very useful for troubleshooting.

Application Insights generates also an application map of collected dependency data if your Azure Functions are using different services. The Application Map feature helps you spot performance bottlenecks or failure hotspots across all components of your distributed application. Each node on the map represents an application component or its dependencies and has health KPI and alerts status. You can select any component to get more detailed diagnostics, such as Application Insights events.

Here is for example the application map of one of my Azure Function that saves blobs data to an Azure Blob Storage container:

Please remember that if you’re creating Azure Functions with the new Isolated model (more on that at BC Techdays if you’re interested) you need to use the dotnet add package Microsoft.ApplicationInsights.WorkerService and then add the service configuration in the Program.cs file:

Monitoring the full components of a cloud architecture is extremely important. Telemetry in Dynamics 365 Business Central is a must to activate, but remember that also the other parts of your architecture should be included in the monitoring practice. In this way you can for example create a single dashboard including data from all your cloud services (Business Central, Azure Functions and more) and then improve your monitoring experience (here is an example of one of my dashboards, showing data coming from Azure Functions together with data coming from Dynamics 365 Business Central):