Microsoft Dynamics 365 Business Central October Wave 2 Release Technical Overview

One of the strengths of Business Central as a product are the constant improvements being made. 

Microsoft issues new major releases twice a year, with new features and updates. Here, we will be reviewing the main technical and development related features planned for Business Central in the October 2020 release.

Data audit system fields are added to every table

One of the common data auditing customisations made is to track data changes in specific tables, e.g. who and when a record is modified/created. Implementing this functionality requires coding and adding new fields to these tables. With the new Business Central release, this will become a standard feature.

Four new system fields will be added to all Business Central tables:

• SystemLastModifiedOn
• SystemLastModifiedBy
• SystemCreatedBy
• SystemCreatedOn

The platform will populate the content of these fields when a record is created or modified. It will not be possible for a developer or user to control these values that are saved to the database.

On-demand joining of companion tables

Another common customisation made in Business Central is to extend the base application tables. Implementation of this is usually achieved by creating a base table extension object. However, this can cause severe performance issues for the large dataset tables (such as G/L Entry), with multiple extensions extending the same base app table.

A new update in the October release will ensure that the data stack inside the Business Central server will not always join all data from table extensions, which will increase performance in the system.

Attach to user session when debugging in sandbox

Currently, when debugging code with the Visual Studio AL debugger you can only debug the session of the user running the debugger which makes it harder to troubleshoot issues that are dependent on users and user permissions. A new and long awaited feature in the release will enable the attaching of an active user session on the sandbox allowing developers to debug active sessions.

Developers can emit telemetry to Application Insights from AL code

App developers can now instrument their code both for their own use and to make it possible for reselling partners to troubleshoot potential issues. A new AL function Session.LogMessage will be added to emit a telemetry message. 

Function signature: 

Session.LogMessage( EventID : String, Message: String, DataClassification: DataClassification, Scope: ExtensionPublisher|All, Verbosity: Verbosity, Dimensions: Dictionary of [String, String] )

If the Verbosity level is set to Normal and DataClassification is set to SystemMetadata, then the platform will emit telemetry. The value of the Scope parameter determines where the telemetry will be sent. If set to ExtensionPublisher, telemetry is only sent to the Application Insights account specified in the app.json file. If set to All, telemetry is also sent to the Application Insights account specified in the Business Central Admin Center.

Extension publishers can get telemetry in Azure Application Insights

Extension publishers can get telemetry about issues in their extension before partners and customers report it. We can now add an instrumentation key for Azure Application Insights in the app.json file for an extension. When events such as those in the following list below happen in codeunit that are part of the extension, then this signal will be sent to the Azure Application Insights account that has the supplied instrumentation key :

• Long-running SQL queries
• Report execution
• Extension updates
• Update errors due to exceptions thrown in upgrade code in the extension
• Web service requests

Performance Regression and Application Benchmark tools

Performance testing in Business Central has been a concern for larger customers, especially when it hasn’t been easy to test and confirm that a production environment can withstand planned data loads. With the Application Benchmark Tool, partners can simulate such loads and gain confidence in Business Central’s ability to support specific customer loads.

Common Data Service virtual entities

Microsoft is heavily investing into the Applications Solutions ecosystem where different products can integrate more easily with each other. A new feature to consume virtual entities from Business Central in the Common Data Service will be delivered as part of the October release. Power Apps will be able to leverage Business Central virtual entities directly, as if they were native Common Data Service entities. Virtual entities will be based on API pages in Business Central, which can be created by developers.

Changes to the action bar in dialogs

Dialog type pages with a pair of OK and Cancel buttons, e.g. advanced lookups (such as when a user chooses Select from a full list in a lookup drop-down list) or pages that are launched by code using the RunModalmethod (where the return value is referenced by that code), will not display additional actions. This should simplify the UI and not distract users when they are trying to use a lookup to find something.

Service-to-service authentication for Automation APIs

Service-to-service authentication will be supported for Automation APIs in Business Central. For supporting Automation scenarios in Business Central, an application permission scope is added, called Automation.ReadWrite.All. 

This will allow service-to-service authentication, having external services connect as an application without impersonating normal users. Using OAuth Client Credentials flow, an app token with Automation.ReadWrite.All scope can then be used to access Business Central. 

Apps need to be registered in Business Central and the OAuth consent flow has to be completed before Business Central can be accessed.

Restoring environments to a point in time in the past

Currently, when a production database needs to be restored, a new support ticket must be raised with Microsoft. With the new release, Business Central admin users will be able to restore any environment (sandbox or production) to a certain point in time up to 30 days in the past. The number of restore attempts will be limited to 10 attempts per environment, per month. This database restore feature will provide more flexibility and control for partners to manage their systems.