What’s new in AL 2022 Wave 1 – Hacker Edition

This has become a tradition on the channel, when Microsoft released a new version of Business Central, I take a look behind the scenes to see what’s added to the AL language, check it out:

https://youtu.be/TLXjX-o_THU

In this “Hacker Edition” video, Erik digs into the internals of the AL compiler DLLs to discover what’s actually changed in AL for Business Central 2022 Wave 1 (version 20). Since the AL compiler is written in .NET and isn’t obfuscated, it’s possible to decompile and diff the assemblies to see exactly what’s new — even things that might not be prominently featured in the official release notes.

Version Numbering: A Quick Aside

Before diving into the changes, Erik clarifies the sometimes confusing version numbering. When Microsoft introduced the AL platform, they started an internal version counter that effectively began at zero with NAV 2018. So what we call Business Central version 20 (or “2022 Wave 1”) is internally tagged as version 9. The “wave” naming convention means that everything released between April 1st and October 1st falls under this umbrella — not everything ships in the initial 20.0 release.

Looking Back: What Happened in Version 19 After the Initial Release?

Before examining version 20, Erik checks what changed in the minor releases of version 19 (2021 Wave 2). The findings are telling:

  • 19.1: A large list of additions, but virtually all of them were new overloads for TestField across different field types that accept the new ErrorInfo structure.
  • 19.2 through 19.5: Nothing changed in the AL language itself.

This confirms a pattern: Microsoft makes the bulk of AL language changes in the .0 and .1 releases of each major version, with subsequent minor versions focusing on other areas.

New Attributes in Version 20

Isolated Events

A new Isolated attribute has been introduced for events. When an event subscriber is marked as isolated, it runs in its own transaction. If the subscriber fails, it doesn’t bring down the calling code. The event executes independently of the scenario it’s called from. Erik notes that this is still running within the same session — it’s not spawning a separate background task — but the isolation provides fault tolerance for event subscribers.

InherentPermissions

A new InherentPermissions attribute can be applied to procedures. This allows you to assign specific permissions to a procedure, with the constraint that you can only grant permissions to objects within the same extension. This is part of the broader permissions improvements in this wave.

Report Layouts: The Biggest Change

The most significant area of change in version 20 is undoubtedly report layouts. This encompasses several related features:

Excel Layout Support

Reports can now use Excel-based layouts. New properties and parameters related to ExcelLayout and ReportExcelLayout have been added to the object parser, meaning you can define Excel layouts directly in your AL report objects.

Multiple Layouts Per Report

Reports can now define multiple layouts within a single report object. Previously, a report was tied to a single layout; now you can specify several, giving users more flexibility in how they render and consume report output.

Report Layout Types

The system now recognizes several report layout types as system options:

  • RDLC — the traditional SQL Server Reporting Services layout
  • Word — Microsoft Word-based layouts
  • Excel — the new Excel-based layout option
  • Custom — described in the auto-generated documentation as “a report layout of a user-defined type”

The Custom type is particularly intriguing. Erik discovered it in the source code and notes that Microsoft has started auto-generating documentation from the compiler source, so this option appears in the docs — but its exact use case for user-defined layout types remains unclear.

New Report Functions

Several new built-in functions support the enhanced layout system:

  • ValidateAndPrepareLayout — validates whether a provided report layout is compatible with a specified report and performs required modifications so it can be used for rendering.
  • Print — a new built-in function on report instances.
  • DefaultLayout — related to determining which layout a report should use by default.

Other Changes

On-Prem Blob Field Overloads

New overloads for import and export operations on BLOB fields have been added for on-premises deployments. Erik doesn’t spend much time on this since his focus is cloud-first, but it’s worth noting for those maintaining on-prem installations.

ErrorInfo Overload

A new overload for creating an ErrorInfo structure with additional parameters was added, continuing the trend from version 19 of enriching error handling capabilities.

Sample AL Code

The accompanying source code shows a basic AL extension targeting version 22 (runtime 11.0). Here’s the app configuration:

{
  "id": "8fef1be2-65a4-4b41-aa09-ba11d1db00d3",
  "name": "WhatsNewInALBC22",
  "publisher": "Default publisher",
  "version": "1.0.0.0",
  "platform": "1.0.0.0",
  "application": "22.0.0.0",
  "idRanges": [
    {
      "from": 50100,
      "to": 50149
    }
  ],
  "runtime": "11.0",
  "features": [
    "NoImplicitWith"
  ]
}

And a simple page extension demonstrating some current AL syntax features like foreach:

pageextension 50100 CustomerListExt extends "Customer List"
{
    trigger OnOpenPage();
    var
        Str: Text;
        c: Char;
    begin
        foreach c in Str do
            Message('App published: Hello world');
        if Rec.FindSet(true,true)
    end;
}

Summary

Version 20 (2022 Wave 1) brings a relatively focused set of AL language changes, dominated by the new report layout capabilities — especially Excel layout support and the ability to define multiple layouts per report. The two new attributes (Isolated for events and InherentPermissions for procedures) add meaningful functionality for resilient event handling and fine-grained security. Erik emphasizes that a shorter list of changes isn’t a bad thing — it’s a sign that the AL platform is maturing and stabilizing, which is ultimately good for developers building on it.

It’s also worth remembering that this analysis only captures changes to the AL language itself — what you can write in a .al file in Visual Studio Code. There are many other platform changes (new events, backend capabilities, UI improvements) that don’t require modifications to the compiler and therefore won’t show up in this kind of analysis.

Picture of hougaard

hougaard