Analyzing Incoming Web Services Request Telemetry

INTRODUCED IN: Business Central 2020 release wave 1

Web services telemetry gathers data about SOAP, OData, and REST API requests to the service. It provides information like the request's endpoint, time to complete, HTTP status codes, and more.

General dimensions

The following table explains the general dimensions included in an incoming Web Services Call trace. The table lists the dimensions that are specific to Business Central.

General dimensions (version 16.0 and earlier)

In versions 16.0 and earlier, the general dimensions look like this:

Custom dimensions

The following table explains the custom dimensions included in a Web Services Call telemetry event.

For a full KQL example of all dimensions in web services telemetry, see Sample KQL code.

¹This dimension isn't relevant for $metadata calls, like https://localhost:7048/BC/ODataV4/$metadata, so it won't be in the trace.

²From telemetrySchemaVersion 0.6 and onwards, this value also includes the CompanyOpen operation.

³This dimension was introduced in Business Central 2023 release wave 1, version 22.0.

⁴This HTTP status code was introduced in Business Central 2023 release wave 1, version 22.2.

HTTP status codes

When you call a web service endpoint, either a Business Central API or from AL using Httpclient datatype, you get an HTTP status code as part of the response. All HTTP status codes that start with 4 (sometimes also written 4xx) are classified as client errors and it is your responsibility to react on these errors and fix them in your code.

In the following table, we list some common 4xx HTTP status codes and suggestions to how to fix them:

HTTP headers

For privacy and security reasons, the Business Central maintains a list of HTTP headers that are allowed to be emitted to telemetry.

The following HTTP headers are emitted to telemetry (if set in the request):

• Accept
• Accept-Charset
• Accept-Encoding
• Accept-Language
• Allow
• client-request-id
• Connection
• Content-Encoding
• Content-Language
• Content-Length
• Content-Type
• Data-Access-Intent
• Expect
• If-Match
• isolation
• odata-isolation
• OData-MaxVersion
• OData-Version
• postman-token
• Prefer
• request-id
• return-client-request-id
• Transfer-Encoding
• User-Agent
• x-forwarded-host
• x-forwarded-path
• x-forwarded-port
• x-forwarded-proto

Who is calling web services endpoints?

When calling Business Central web services, you can inject information about the caller into telemetry for REST API and OData calls.

• Setting the HTTP header UserAgent logs requests with the httpHeaders dimension.

• Setting the HTTP header client-request-id, logs requests with the httpHeaders dimension and it also sets the "OperationId"/ClientActivity in Application Insights.

This capability means you can use telemetry to see who's calling Business Central REST APIs and OData web services. It also lets you correlate to telemetry from other web services, if you use Azure Application Insights to instrument them.

Who owns the code behind a web services endpoint?

You can use the custom dimensions alObjectId, alObjectName, and alObjectType to identify the object behind the endpoint. To see which app/extension that the object belongs to, use the custom dimensions extensionId, extensionName, extensionVersion, and extensionPublisher.

This KQL code illustrates how you can find the owner of the code behind and endpoint and what code was running. Such information might be useful, should you need to contact the publisher of an app/extension.

// Incoming Web Service Requests - object and extension information
traces
| where timestamp > ago(1d) // change as needed
| where customDimensions has "RT0008"
| where customDimensions.eventId == "RT0008"
| project timestamp
// in which extension/app
, extensionId = customDimensions.extensionId
, extensionName = customDimensions.extensionName
, extensionVersion = customDimensions.extensionVersion
, extensionPublisher = customDimensions.extensionPublisher
, whoWroteTheCode = case(
    customDimensions.endpoint startswith "MS/", 'Microsoft' // metadata calls and calls to company endpoints do not have data in extension* dimensions
  , customDimensions.extensionPublisher
)
// in which object
, alObjectId = customDimensions.alObjectId
, alObjectName = customDimensions.alObjectName
, alObjectType = customDimensions.alObjectType

For a full KQL example of all dimensions in web services telemetry, see Sample KQL code.

What type of web services are called (REST API, OData, or SOAP)?

The custom dimension category hold information about the type of endpoint (REST API, OData, or SOAP) being called.

This KQL code illustrates how you can find which endpoints are being called and which types of endpoints are being used. Such information might be useful, should you want to modernize your use of web services to use REST APIs, which is recommended over using SOAP web services or OData web services based on pages.

// Incoming Web Service Requests - endpoint information
traces
| where timestamp > ago(1d) // change as needed
| where customDimensions has "RT0008"
| where customDimensions.eventId == "RT0008"
| project timestamp
// endpoint information
, category = customDimensions.category // API, ODataV3, ODataV4, or SOAP
, endpoint = customDimensions.endpoint // URI

For a full KQL example of all dimensions in web services telemetry, see Sample KQL code.

Analyze web service call performance using telemetry

As a developer, you use the data to learn about conditions that you can change to improve performance. The following table provides some examples:

For more performance guidelines, see Web service performance

This KQL code illustrates how you can find the performance characteristics of different endpoints.

// Incoming Web Service Requests - performance information
traces
| where timestamp > ago(1d) // change as needed
| where customDimensions has "RT0008"
| where customDimensions.eventId == "RT0008"
| project timestamp
// endpoint information
, category = customDimensions.category // API, ODataV3, ODataV4, or SOAP
, endpoint = customDimensions.endpoint // URI
// performance data (time is in milliseconds)
, requestQueueTimeMS = toreal(totimespan(customDimensions.requestQueueTime))/10000
, executionTimeInMS = toreal(totimespan(customDimensions.serverExecutionTime))/10000 
, requestTotalTimeMS = ( toreal(totimespan(customDimensions.totalTime))+toreal(totimespan(customDimensions.requestQueueTime)) )/10000

For a full KQL example of all dimensions in web services telemetry, see Sample KQL code.

Analyze web service call stability using telemetry

Business Central telemetry on web service calls have two important dimensions to troubleshoot failed web service calls:

• The custom dimension httpStatusCode
• The custom dimension failureReason

For more guidelines on web service call stability, see Troubleshoot web service errors

The custom dimension httpStatusCode

The custom dimension httpStatusCode is key to understanding unsuccessful web service calls. Any call with an HTTP status code in the 4xx range should be investigated because these calls are likely failing due to a misconfiguration on the web service client (the caller).

Business Central online and on-premises are configured with various limits on web service requests. For example, there's a request timeout and a maximum connections limit. For online, you can't change these limits, but it's helpful to know what the limits are. See Current API Limits. For on-premises, you change the limits on the Business Central Server instance. See Configuring Business Central Server. Web service calls that exceed the timeout limit result in a 408 - Request Timeout. These calls are recorded in Application Insights with a totalTime that is equal to the timeout threshold.

For more guidelines on HTTP status codes, see HTTP status codes.

The custom dimension failureReason

The custom dimension failureReason is used to troubleshoot further, mostly error conditions happening in the AL code behind the web service endpoint.

For more information on error codes for the various exceptions that are logged in the custom dimension failureReason, please see Troubleshooting OData/API calls.

Sample KQL code for analyzing failures in web service calls

This KQL code can help you see combinations of httpStatusCode and failureReason in your web service call telemetry:

traces
| where timestamp > ago(60d) // adjust as needed
| where customDimensions has 'RT0008'
| where customDimensions.httpStatusCode <> 200
| where customDimensions.category <> 'SOAP' // no httpStatusCode or failureReason logged for SOAP calls
| project failureReason = tostring( customDimensions.failureReason )
, httpStatusCode = tostring(customDimensions.httpStatusCode)
| where isnotempty( httpStatusCode )
| distinct httpStatusCode, failureReason

For a full KQL example of all dimensions in web services telemetry, see Sample KQL code.

Sample KQL code

This KQL code unfolds all information from the custom dimensions in your web service call telemetry. Use the code sample as a starting point for you analysis and comment out sections for details that you don'tt need.

// Incoming Web Service Requests
traces
| where timestamp > ago(60d) // change if your retention policy is different than the default
| where customDimensions has "RT0008"
| where customDimensions.eventId == "RT0008"
// use this line and comment out the two lines on RT0008 above if you have data prior to version 16.1 
// | where operation_Name == "Web Services Call" // in a later version of the schema, this field will not be used 
//      or customDimensions.eventId == "RT0008" // starting from version 16.1, the eventId is used to identity signal types
| project timestamp
// in which environment did it happen
, aadTenantId = customDimensions.aadTenantId
, environmentName = customDimensions.environmentName
, environmentType = customDimensions.environmentType
// in which extension/app
, extensionId = customDimensions.extensionId
, extensionName = customDimensions.extensionName
, extensionVersion = customDimensions.extensionVersion
, extensionPublisher = customDimensions.extensionPublisher
, whoWroteTheCode = case(
    customDimensions.endpoint startswith "MS/", 'Microsoft' // metadata calls and calls to company endpoints do not have data in extension* dimensions
  , customDimensions.extensionPublisher
)
// in which object
, alObjectId = customDimensions.alObjectId
, alObjectName = customDimensions.alObjectName
, alObjectType = customDimensions.alObjectType
// endpoint information
, category = customDimensions.category // API, ODataV3, ODataV4, or SOAP
, endpoint = customDimensions.endpoint // URI
// how was the endpoint called?
, httpHeaders = customDimensions.httpHeaders // httpHeaders available from 16.3
, httpMethod = customDimensions.httpMethod   // httpMethod available from 16.3
// diagnostics data (how did it go?)
, httpStatusCode = customDimensions.httpStatusCode // httpStatusCode available from 16.3
, diagnosticsMessage = customDimensions.diagnosticsMessage // Not logged for SOAP calls. diagnosticsMessage available from 22.0
, failureReason = customDimensions.failureReason // Not logged for SOAP calls. failureReason available from 22.0
// performance data
// the datatype for executionTime and requestQueueTime is timespan so need to convert to milliseconds
, executionTime = customDimensions.serverExecutionTime
, requestQueueTime = customDimensions.requestQueueTime // This dimension was introduced in Business Central 2023 release wave 1, version 22.0.
, requestQueueTimeMS = toreal(totimespan(customDimensions.requestQueueTime))/10000
, executionTimeInMS = toreal(totimespan(customDimensions.serverExecutionTime))/10000 
, requestTotalTimeMS = ( toreal(totimespan(customDimensions.totalTime))+toreal(totimespan(customDimensions.requestQueueTime)) )/10000
// these extend lines illustrate how to extract data from the httpHeaders dimension
| extend httpHeadersTmp =  tostring( httpHeaders)
| extend httpHeadersJSON = parse_json(httpHeadersTmp)
| extend msUserAgent = tostring( httpHeadersJSON.['ms-dyn-useragent'] )
| extend httpAuthorization = tostring( httpHeadersJSON.['Authorization'] ) // Authorization header (truncated) available from 17.3

To make it easier to get started using Azure Application Insights with Business Central, samples of KQL code are available in the Business Central BCTech repository on GitHub.

If you want to analyze web service call telemetry from the usage of the Microsoft connector (Power BI, Power Apps, ...), then the query MicrosoftConnectorUsage.kql might be useful.

See also

Web service performance
Troubleshoot web service errors
Web services overview
Telemetry overview