Commercial use of Docker Desktop at a company of more than 250 employees OR more than $10 million in annual revenue requires a paid subscription (Pro, Team, or Business).³

Windows containers

To install the Docker Engine, I use the script that is provided by the microsoft/nav-arm-templates repository on GitHub. It installs and updates Docker on your local windows machine and is mentioned on the Install Docker Engine⁴ step in the README.md of the navcontainerhelper repository on GitHub.

Invoke-WebRequest -UseBasicParsing -uri 'https://raw.githubusercontent.com/microsoft/nav-arm-templates/master/InstallOrUpdateDockerEngine.ps1' -OutFile (Join-Path $ENV:TEMP 'installorUpdateDocker.ps1')
. (Join-Path $ENV:TEMP 'installorUpdateDocker.ps1')

The installorUpdateDocker script will take care over numerous steps for you:

1. check if docker desktop is already installed
2. install windows feature containers
3. get latest stable version and URL
4. check existing docker version
5. download new version
6. register service if necessary
7. start the service

Execute the InstallOrUpdateDockerEngine.ps1 for the first time:

Execute the InstallOrUpdateDockerEngine.ps1 for the second time:

Docker Engine: Pros and Cons

Docker has an official comparison: Docker Desktop vs DIY with Docker Engine

Here are some of my own thoughts:

Pros

• It’s free to use (see LICENSE⁵)
• Production servers running docker engine, so it’s a good habit to familiarize yourself with docker commands
• If you only use the Docker commands, a GUI might be too much anyway

Cons

• You do not get ready-to-use Linux and Windows containers, as would be the case with Docker Desktop
• You need to update the Docker Engine manually

Linux containers

• 1. Install WSL (version 2) wsl --install

  (by default, the installed Linux distribution will be Ubuntu. This can be changed by using the -d flag)

  • 1.1. Ubuntu has been installed. Changes will not be effective until the system is rebooted

  

  • 1.2. After reboot, a prompt will show up to setup Ubuntu (add a user)

  

• 2. Open Install Docker Engine of the Linux distribution you have chosen (we use Ubuntu)
• 3. Choose an Installation Method

  • 3.1. Set up Docker’s apt repository

    # Add Docker's official GPG key:
    sudo apt-get update
    sudo apt-get install ca-certificates curl
    sudo install -m 0755 -d /etc/apt/keyrings
    sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
    sudo chmod a+r /etc/apt/keyrings/docker.asc
    
    # Add the repository to Apt sources:
    echo \
      "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \
      $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
      sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
    sudo apt-get update
    

  • 3.2. Install the Docker packages

      sudo apt-get install docker-ce docker-ce-cli containerd.io
    

Conclusion

Regardless of whether you use Docker Desktop or Docker Engine, you will end up creating Docker containers on your local machine. For Business Central development, we typically use scripts from the BcContainerHelper PowerShell module, so we don’t miss the missing GUI too much. When managing multiple containers, a container management platform with a user interface can be particularly useful. In this case, Portainer is a great option, offering a web interface that makes it also accessible from other devices.

See you around 🦦

It’s been a while since my last blog post. As you may know, BC v24 has been released. I noticed that new BC APIs have been created. Woulnd’t be too much effort to add them to the Postman Collection¹, …right? 😏 Well, this is where the fun begins! 😁

The first thing I’ve noticed is that I can not get a request through. I want to get the list of accounts. The request gets stuck. No answer. After 5 minutes, the request eventually times out.

Ultimatley resulting in a bottleneck for all the otter requests as you can see in the event log of the container. The APIs which can usually be handled (<50-60 results) have to wait.

Detailed information can be found under Operational limits.

The picture in the header is the script I am using for the last couple of months. I am using BcContainerHelper v6.0.15. Never had a problem with the v23 APIs. But now suddenly they don’t work as expected in a BC v24 container, or at least some of them.

Surprisingly in the Business Central Launch Event² was mentioned that FindSet will be used for >50 rows. This is roughly the same range as our timeout issue. Remains to be seen if this is related, as I have not taken the time to analyze the cause of this problem and hope that this is only a temporary issue and will be fixed in the future.

Source: https://www.youtube.com/watch?v=VpNQ-CYNrkM&list=PL1FESh9FqyhSjW63Ouft5vbc2NSxXKV2k&index=39&t=263s

Afaik, there are currently two solutions to this particular problem:

• either stay with isolation mode hypver, but use ssl

or

• switch to isolation mode process

Hope you learned something new.

See you around 🦦

Update

I’ve created a custom table with 3 fields (id, name and age) and inserted 50 records. Now insert 1 record step by step and send an http request in between. The GET requests run smoothly up to 58 records. If you increase the number by 1 more, it no longer responds and leads to a timeout.

To give you an example what this looks like, see the following animation.

Adding one more field to the custom table and the custom api, the timeout now appears at 57 records, so it’s not just the number of records that matters, but also the size of the data.

When we think about bringing new developers into our project, it is likely that they will work with different guidelines than they have before. Sometimes the sheer amount of guidelines is simply too much to follow correctly after days, weeks or even months. Especially if you are not working entirely on the new project, but rather as a stand-in, meaning it could be weeks or months without working on this particular project, giving you a much harder time to keep-up with the specific guidelines.

One of the guidelines can be a prefix of the commit message by the project ticket number. This might not be that relevant if the pull request forces you to merge by squash commit. In my last post I showed an example to validate the commit message. However, since that is done locally there is always the possibility that some Devs might just turn the Git hooks off. That’s why we’d like to enforce rules centralized, and what better way than to automate this?

Getting started

Let’s say we are forced to merge our pull requests via squash commit. This is already an enforced rule (“policy” in the likes of Azure DevOps) in the repository, usually applied to certain branches and tags.

Unfortunately there is no predefined variable for the pull request title in Azure DevOps yet. So we have to call the Azure DevOps API, get all the metadata of the specific pull request and essentially the title of the pull request, which we then validate by the defined Regex pattern, in this case: [OTTER-xxxxxx] while x stands for a number between 0 and 9. Also notice the whitespace after ].

Azure DevOps Pipeline Task

- task: PowerShell@2
  displayName: 'Validate PR title'
  env:
    SYSTEM_ACCESSTOKEN: $(System.AccessToken)
    REGEX_VALIDATION: (\[OTTER\-[0-9]{1,6}\] \w+)
  inputs:
    failOnStdErr: true
    targetType: 'inline'
    script: |
      $url = "$($env:SYSTEM_COLLECTIONURI)_apis/git/repositories/$($env:BUILD_REPOSITORY_ID)/pullRequests/$($env:SYSTEM_PULLREQUEST_PULLREQUESTID)?api-version=4.0"

      if(![string]::IsNullOrEmpty($env:SYSTEM_PULLREQUEST_PULLREQUESTID)) {
        $pipeline = Invoke-RestMethod -Uri $url -Headers @{
          "Authorization"="Bearer $($env:SYSTEM_ACCESSTOKEN)"
        } -OutFile output.json

        $Content = Get-Content output.json -Encoding UTF8
        $jsonObj = $Content | ConvertFrom-Json
        $pr_title = $jsonObj.title

        $Regex = $env:REGEX_VALIDATION
        if ($pr_title -match $Regex) {
          Write-Host "The title of the pull request is valid."
        } else {
          Throw "Error: Invalid pull request title! Please prefix with a valid project ticket number."
        }
      }

The script isn’t optimized. There is an error while reading the json content from the http response. This is why I opted in for the quick workaround, saving the content in a file and reading it again. The error handling can be improved. Also the task needs to be executed only if there is an actual PR, otherwise this script doesn’t make sense which is why I just let it pass. (Maybe I update this script in the future).

Conclusion

These automations guide us through the various guidelines of each project/repository without having to read a lot of documentation and also help the teams managing the project to enforce their policies.

The developers get immediate feedback on their pull requests, which leads to fewer delays and more productivity. Now it’s your turn. Get creative and create your own tasks to enforce your rules.

Hope you learned something new.

See you around 🦦

If you frequently clone new repositories, it can be a challenge to adhere to the specific development policy. New project, new development team, new software development policy. This doesn’t sound familiar to you? Then perhaps one of the following:

• “It would be cool if I could do X automatically befor pushing my Git commits.”
• “I still keep forgetting running my unit tests in between each Git commit.”
• “We have to prefix our Git commit message with the project ticket number.” (see Examples)

So.. Git hooks to the rescue! They allow us to customize the behavior of Git and trigger actions that are automatically executed when a specific Git event occurs. Development teams can enforce commit policies and implement CI workflows. You can use Git hooks to automate almost any aspect of your development workflow.¹

I’ll cover only local hooks and not server-side hooks, and show two small examples and since the .git folder is always ignored, we can not share those scripts out-of-the-box within our development team, so let’s have a look at how we can share our Git hooks aswell.

Prerequisites

• Git v2.9.0² as a minimum

Getting started

After executing the git init command, Git creates a new directory with the following structure:

local repository
├── .git
|   ├── hooks
|   |   ├── commit-msg.sample
|   |   ├── pre-commit.sample
|   |   ├── prepare-commit-msg.sample
|   |   ├── pre-push.sample
|   |   └── ...
|   ├── ...
|   ├── config
|   ├── description
|   └── HEAD
├── .gitignore
└── README.md

One of the folders is called hooks and contains only files with the extension .sample. The comment section of these files states that these pre-defined Git hooks become active when the filename extension .sample is removed.

For a full list of all available Git hooks, see: https://git-scm.com/docs/githooks#_hooks

Make sure that the Git hook is executable, otherwise it won’t run.

To change the script interpreter, you can change the first line of the file (Shebang #!/bin/sh) to your preferred scripting language.

Configuration

Since we cannot share the Git hooks from the .git directory, we create a new folder with the name .git-hooks and put all Git hooks into this folder.

Advise your development team that they will need to change the default path to the new Git hooks folder for this to take effect. To change the path of the hooks for the current local repository, run the command:

git config core.hooksPath ./.git-hooks

It’s a good idea to add this step to the Getting Started / Setup section of your repository’s README.md file. This is a common place that every developer should read after cloning the repository.

If you want to take this one step further and copy Git hooks to the new repository you create/clone, see Git Template: https://git-scm.com/docs/git-init#_template_directory

Examples

If you decide that it fits well into your development process to add the ticket number to every single commit message, perhaps if you decide not to squash commits after you have completed the pull request, it can become very tedious for developers to add the ticket number every time, especially for those who commit in small increments and therefore a lot.

Let’s take a look at two examples. One where we trigger a validation step and another where a prefix is added to the commit message. Both examples come from the boring execution of adding the ticket number as prefix to the commit message. Normally we already name the branch with the ticket number, so why bother and just add it automatically.

commit-msg: Validate Commit Message

If you do not name your branch after a specific ticket number, but still want to check the commit message prefixed with a ticket number, you can use the following script.

Content of the commit-msg file:

#!/bin/sh

FILE_COMMIT_EDITMSG=$1
COMMIT_MSG=`head -n 1 $FILE_COMMIT_EDITMSG`
REGEX_RESULT=$(echo $COMMIT_MSG | grep -Eo '(\[[A-Z]+-[0-9]+\]\s)')
if [[ $REGEX_RESULT == "" ]]; then
  echo "Git commit message '$COMMIT_MSG' is missing a ticket number. Example '[OTTER-1234] add component'"
  exit 1
fi

prepare-commit-msg: Prefix Commit Message

Usually, the name of the branch already contains the ticket number. Therefore, we can automatically insert the ticket number into the commit message based on the name of the current branch.

Content of the prepare-commit-msg file:

#!/bin/sh

FILE_COMMIT_EDITMSG=$1
COMMIT_MSG=`head -n 1 $FILE_COMMIT_EDITMSG`
BRANCH_NAME=`git rev-parse --abbrev-ref HEAD`
REGEX_RESULT=$(echo $BRANCH_NAME | grep -Eo '([A-Z][A-Z0-9]+-[0-9]+)')
if [ $REGEX_RESULT == "" ]; then
  echo "The current branch name does not contain a valid ticket number. Example 'feature/OTTER-1234-new-feature'"
  exit 1;
fi

echo "$REGEX_RESULT $COMMIT_MSG" > $FILE_COMMIT_EDITMSG

Further Reading

A few additional sources you can read to dive a bit deeper into the Git hooks topic:

• https://github.com/git/git/blob/master/Documentation/githooks.txt
• https://www.atlassian.com/de/git/tutorials/git-hooks
• https://www.digitalocean.com/community/tutorials/how-to-use-git-hooks-to-automate-development-and-deployment-tasks
• https://kinsta.com/blog/git-hooks/

Conclusion

I hope these two practical examples will inspire you to get creative and create your own Git hooks. You can basically add every step you want, you are only limited by your skills and imagination. So.. automate the boring stuff and enforce local development policies! Please don’t bloat it too much to ensure fast and smooth development.

Hope you learned something new.

See you around 🦦

Application Area gives us the ability to define differentiated user experiences. They are mapped to controls to show or hide them on page objects to enable more or fewer business scenarios.

As you know, we can extend the application areas in Business Central¹ by extending the Application Area Setup table:

tableextension 60200 ApplicationAreaSetupExt extends "Application Area Setup"
{
    fields
    {
        field(60200; "Trading"; Boolean) { }
    }
}

Spaces in the field name are omitted in the ApplicationArea property.

Then we can set the ApplicationArea property² to our newly created application area, as in the following pagefield example:

field(TradingViewEnabled; Rec."Trading View Enabled")
{
    ApplicationArea = Trading;
    ToolTip = 'Specifies if the trading view is enabled.';
}

However, we can not enable/disable an application area out of the box. This is where the Experience Tier comes into play.

Extend the Experience Tier Setup

By adding experience tiers we allow the users to choose which set of application areas they want to enable in their specific company. We can change the User Experience on the Company Information page.

The way it works is the same as extending the Application Area Setup, except this time it extends the Experience Tier Setup. Let’s look at an example:

tableextension 60201 ExperienceTierSetupExt extends "Experience Tier Setup"
{
    fields
    {
        field(50100; Ultimate; Boolean)
        {
        }
        field(50101; Platinum; Boolean)
        {
        }
        field(50102; VIP; Boolean)
        {
        }
    }
}

Enable application areas

To enable application areas in a custom experience tier we need to subscribe to the event “OnSetExperienceTier” from the “Application Area Mgmt. Facade” codeunit.

codeunit 60200 EnableApplicationArea
{
    Access = Internal;
    InherentEntitlements = X;
    InherentPermissions = X;
    SingleInstance = true;

    [EventSubscriber(ObjectType::Codeunit, Codeunit::"Application Area Mgmt. Facade", 'OnSetExperienceTier', '', false, false)]
    local procedure EnableAdvancedApplicationAreaOnSetExperienceTier(experienceTierSetup: Record "Experience Tier Setup"; var tempApplicationAreaSetup: Record "Application Area Setup" temporary; var applicationAreasSet: Boolean)
    begin
        if experienceTierSetup.Ultimate then begin
            tempApplicationAreaSetup.Basic := true;
            tempApplicationAreaSetup.Suite := true;
            tempApplicationAreaSetup.Service := true;
        end;
    end;
}

For an overview, which application areas are enabled in the current company, search for Application Area via Tell Me:

Refresh experience tier of current company

There is still one more thing left to do: set the experience tier of the current company. This is done when installing the extension as in the following example:

codeunit 60201 InstallApplicationArea
{
    Subtype = Install;

    trigger OnInstallAppPerCompany()
    var
        applicationAreaMgmtFacade: Codeunit "Application Area Mgmt. Facade";
    begin
        applicationAreaMgmtFacade.RefreshExperienceTierCurrentCompany();
    end;
}

As you have already noticed, it’s necessary to update our AL code whenever there are new Application Areas added to our solution.

Enable the Application Area via Setup page

Since we can design module-driven in Business Central, I think that enabling the Application Area in a setup page makes sense. It gives the administrators the ability to enable/disable the module for specific companies without switchting the Experience Tier.

The following example Module Setup table just goes to show how this can be done. This time we refresh the experience tier on validating the Application Area Enabled field.

table 60200 "Module Setup"
{
    Caption = 'Module Setup';

    fields
    {
        field(1; "Primary Key"; Code[10])
        {
            Caption = 'Primary Key';
        }
        field(10; "Application Area Enabled"; Boolean)
        {
            Caption = 'Application Area Enabled';

            trigger OnValidate()
            var
                applicationAreaMgmtFacade: Codeunit "Application Area Mgmt. Facade";
            begin
                applicationAreaMgmtFacade.RefreshExperienceTierCurrentCompany();
            end;
        }
    }
}

This triggers our event subscribers so that we can activate the application area depending on the value of the Boolean.

if moduleSetup.Get() then
    tempApplicationAreaSetup.Trading := moduleSetup."Application Area Enabled";

To cover every aspect, here’s a full example:

codeunit 50103 EnableApplicationArea
{
    [EventSubscriber(ObjectType::Codeunit, Codeunit::"Application Area Mgmt.", 'OnGetBasicExperienceAppAreas', '', false, false)]
    local procedure EnableModuleOnGetBasicExperienceAppAreas(var tempApplicationAreaSetup: Record "Application Area Setup" temporary)
    begin
        EnableApplicationArea(tempApplicationAreaSetup);
    end;

    [EventSubscriber(ObjectType::Codeunit, Codeunit::"Application Area Mgmt.", 'OnGetEssentialExperienceAppAreas', '', false, false)]
    local procedure EnableModuleOnGetEssentialExperienceAppAreas(var tempApplicationAreaSetup: Record "Application Area Setup" temporary)
    begin
        EnableApplicationArea(tempApplicationAreaSetup);
    end;

    [EventSubscriber(ObjectType::Codeunit, Codeunit::"Application Area Mgmt.", 'OnGetPremiumExperienceAppAreas', '', false, false)]
    local procedure EnableOnGetPremiumExperienceAppAreas(var tempApplicationAreaSetup: Record "Application Area Setup" temporary)
    begin
        EnableApplicationArea(tempApplicationAreaSetup);
    end;

    local procedure EnableApplicationArea(var tempApplicationAreaSetup: Record "Application Area Setup" temporary)
    var
        moduleSetup: Record "Module Setup";
    begin
        if moduleSetup.Get() then
            tempApplicationAreaSetup.Trading := moduleSetup."Application Area Enabled";
    end;
}

A complete list of the state of all application areas per company would be appreciated. This would give a quick overview of the modules used in each company, and it would even be possible to activate/deactivate them without having to change companies from time to time.

Conclusion

We tend to use ApplicationArea = All; always and everywhere without thinking about whether the customer will use the module in the company at all. Giving them the ability to determine it themselves makes for a great user experience, which we should enable whenever possible.

This is especially true for ISVs. When developing directly for a customer, it tends to downplay this feature because the new fields should always be displayed until they realize they are not needed in other companies. Then they would hide them if needed through individual personalization.

I would not extend the Experience Tier as I would leave it to the specific licensing scenario Essential or Premium which should be activated. Remember to enable your custom application area to one or both of these experience tiers and allow the user to toggle the Application Area for the specific companies.

Hope you learned something new.

See you around 🦦

As I’ve setup a GitHub workflow for e2e testing BC container APIs via newman-cli (postman) last weekend, I used the cmdlet New-BcContainer from the BcContainerHelper¹ module to provide a BC container to test against. Nothing too special at this point.

I thought to myself: “Why do we need BC containers to compile our AL project?”. At least this is what I see in many build pipelines: creating a BC container to compile the application.

So let’s just compile without containers.

Getting started

Before we can use the Compile-AppWithBcCompilerFolder.ps1 cmdlet² we have to make sure that we can provide it with a compilerFolder path.

Create a compiler folder

Create the compiler folder by executing the New-BcCompilerFolder.ps1³ cmdlet with some additional parameters such as the artifactUrl.

New-BcCompilerFolder `
  -artifactUrl (Get-BCArtifactUrl -type Sandbox -country w1 -version 20)

Adjust the Get-BCArtifactUrl parameters to your project needs.

The compilerFolder consists of the following structure:

compilerFolder
├── compiler
|   ├── \_rels
|   ├── extension
|   ├── package
|   ├── \[Content\_Types].xml
|   └── extension.vsixmanifest
├── dlls
|   ├── Mock Assemblies    
|   ├── OpenXML    
│   └── Service
└── symbols
    ├── Microsoft_Application_xx.x.xxxxx.xxxx.app
    ├── Microsoft_Application_xx.x.xxxxx.xxxx.json
    ├── Microsoft_Base Application_xx.x.xxxxx.xxxx.app
    ├── Microsoft_Base Application_xx.x.xxxxx.xxxx.app.json
    ├── Microsoft_..._xx.x.xxxxx.xxxx.app
    ├── Microsoft_..._xx.x.xxxxx.xxxx.app.json
    ├── System.app
    └── System.app.json

The compilerFolder is created in the C:\ProgramData\BcContainerHelper\compiler directory by default. Obviously we don’t have to create the compiler folder every single time. Save the path to the compiler folder or cache the entire folder within your pipeline.

Compile the app with the compiler folder

We can now use the Compile-AppWithBcCompilerFolder² cmdlet to use the compiler folder instead of creating a docker container for app compilation.

Compile-AppWithBcCompilerFolder `
    -compilerFolder $compilerFolder `
    -appProjectFolder C:\code\AL\JustAnotterApp

The app file is created by default in the output folder in our app project folder after successful compilation.

If you are using AL-RunPipeline⁴ in your pipelines, you might want to have a look at the useCompilerFolder argument.

Breaking Changes

Although this section could be placed in another blog post, I decided it is somewhat related. Some build pipelines would not only compile but also publish and install the app to the container, which again is not primarily the purpose of a build pipeline.

So… AppSourceCop to the rescue!

I’ve prepared a small app which has a dependency to the Base App v20.0. It contains a table object with 2 fields and also a ruleset file to ignore some of the AppSourceCop rules.

Running the following script…

$compilerFolder = New-BcCompilerFolder -artifactUrl (Get-BCArtifactUrl -type Sandbox -country w1 -version 20)
$projectFolder = 'C:\code\AL\JustAnotterApp'

Compile-AppWithBcCompilerFolder `
    -compilerFolder $compilerFolder `
    -appProjectFolder $projectFolder `
    -CopyAppToSymbolsFolder `
    -EnableAppSourceCop `
    -rulesetFile $projectFolder\al.ruleset.json `
    -FailOn error

…leads to this output:

The app has been created successfully.

Set version in AppSourceCop.json

We shipped our latest release. Partners and customers would publish and install the app (v0.0.0.0). How does the AppSourceCop know what the previous app is?

We can configure the AppSourceCop with the AppSourceCop.json⁵ file. Provide a version to check against. This version should be the latest published version of our app.

{
    "version": "0.0.0.0",
    "mandatorySuffix": "CB"
}

Download the specific app file to the symbols folder. As we set the CopyAppToSymbolsFolder in the Compile-AppWithBcCompilerFolder our previous app file (*v0.0.0.0) is already copied to the symbols folder.

Make a breaking change

To check if the breaking change is detected, we:

• remove the non primary key field from our table object
• increase the version of our app in our app.json file.

Running the script again…results in the following output:

Compilation of our app version 0.1.0.0 is not successful because it detects a breaking change: AS0002: The field with the name ‘Enabled’ and ID ‘2’ was found in the previous version, but is missing in the current extension. This might break the upgrade of existing installations.

Conclusion

The scripts shown in this example allow us to compile our app without a docker BC container.

• Pros
  • faster build speed
  • save resources
  • runs on Linux
• Cons
  • not able to run tests this way
  • not able to test install/upgrade logic

If you have any questions or suggestions, feel free to contact me.

Hope you learned something.

See you around 🦦

Have you ever wondered how to access your colleague’s local container, so that you can test a new feature right away? Instead of making your local container available we should follow a different approach. Let’s not think of local machines, but rather the cloud or actually temporary resources. Ultimatly, we want to set up a container, deploy our code, provide access to it, test the new feature, then stop and remove the container.

Fair enough… we are going to create a Traefik (https://traefik.io/) container and a Dynamics 365 Business Central container with the help of the BcContainerHelper and some additional docker labels. Our Traefik container than listens on the Docker Deamon to know excactly where to forward the HTTP requests to.

Introduction

As a brief introduction, there are multiple ways to make the container accessible. Before we dive into the Getting started section, we want to make sure that we have a rough overview of what the alternatives to Traefik are.

Transparent Network

Define a transparent network in Docker that you can choose when creating your container. This will handle the container as a physical client in your local network, which comes with some security concerns. As you can already tell, it’s usually not allowed (and shouldn’t be) in your companys network.

The good thing about this is, that each container has its own IP address, making it accessible in your local network without having to spend too much time on managing port mappings.

These are the two steps to create a container in a transparent network.

1. Create the transparent network

docker network create --driver=transparent transparentnetwork

1. Add the network to the additional parameters (New-BcContainer)

-additionalParameters "--network=transparentnetwork"

The additional parameters allow us to provide additional docker commands.

Port Mapping

The Port Mapping from the container to the docker host is a common thing. This might very well fit your needs if you are just working with one docker container.

The basic syntax is as follows: -p HOST-PORT:CONTAINER-PORT

So you might define your additional parameters as follows: -additionalParameters "-p 3080:80".

Now the container port 80 is mapped to the host port 3080, which allows us to access the BC container web client at http://cbserver:3080.

However, if you were to manage multiple docker containers on one machine, it becomes more and more difficult to keep track of all the used ports. Especially when we are dynamically creating containers, we don’t want to worry about that too much and instead just run the container and access it.

Reverse Proxy

For me, this is the easiest way (once you figured it all out). I recommend this way as it’s easy to setup and forwards all the HTTP requests to the specific container by the rule you defined. You could also provide a signed SSL certificate and provide access to your container from outside your network.

Getting started

For the scope of this blog post, I’d like to keep it simple and just focus on our need to provide access to docker containers within our local network from otter clients. This allows us to develop on one machine and automatically deploy our changes to a docker container on our server.

Requirements

• Docker
• BcContainerHelper

I used Docker Desktop to install Docker on my server. As things turns out, Traefik doesn’t really support it¹, so you would be better off to just install the Docker (standalone) Engine.

Setup

We begin with the creation of a Traefik container.

Traefik container

As Business Central is still running on a windows-based OS, we have to get a Traefik installation based on windows, so that it can than pick-up the correct Docker Deamon that will listen to all the otter windows-based containers, including our Business Central container which we want to expose in our local network.

We actually don’t have to create an image ourselfs, as Tobias Fenster² has already done that (see DockerHub: tobiasfenster/traefik-for-windows)³⁴.

docker run -d -p 80:80 -p 443:443 -p 8080:8080 -v C:\traefikforwindows\config:c:\etc\traefik -v \\.\pipe\docker_engine_windows:\\.\pipe\docker_engine_windows tobiasfenster/traefik-for-windows:v2.9.6

Depending on your Docker Deamon you might need to change the docker_engine_windows to something else, e.g. docker_engine. You can find the name of your Docker Deamon in the “%USERPROFILE%.docker\daemon.json” file.

BC container

One thing we should keep in mind right now, is the fact that we leverage the Traefik support for listening on Docker Labels (see: https://doc.traefik.io/traefik/providers/docker/). There are also many other so called providers you can use. I definitely recommend you to read the Traefik documentation⁵.

The following script is a minimal version to give you an impression on how it can be done:

$publicDnsName = 'cbserver'
$containerName = 'bcserver'
$Credential = New-Object pscredential 'admin', (ConvertTo-SecureString -String 'P@ssword1' -AsPlainText -Force)

$additionalParameters = @(
    "-l `"traefik.enable=true`"",
    "-l `"traefik.http.routers.$($containerName)-webclient.service=$($containerName)-webclient@docker`"",
    "-l `"traefik.http.services.$($containerName)-webclient.loadBalancer.server.port=443`"",
    "-l `"traefik.http.services.$($containerName)-webclient.loadBalancer.server.scheme=https`"",
    "-l `"traefik.http.routers.$($containerName)-webclient.rule=PathPrefix(``/$($containerName)``)`"",
    "-l `"traefik.http.routers.$($containerName)-webclient.entrypoints=websecure`"",
    "-l `"traefik.http.routers.$($containerName)-webclient.tls=true`""
)

New-BcContainer `
    -accept_eula `
    -auth NavUserPassword `
    -artifactUrl (Get-BCArtifactUrl -type OnPrem -country 'us' -version '21') `
    -containerName $containerName `
    -Credential $Credential `
    -isolation hyperv `
    -shortcuts None `
    -updateHosts `
    -additionalParameters $additionalParameters `
    -multitenant:$false `
    -useSSL `
    -PublicDnsName $publicDnsName `
    -installCertificateOnHost

Remember that we ultimately want to define rules for all the other ports as well, such as OData, SOAP, devEndpoint, etc. In order for you to access all the other Business Central components⁶ you need to add additional docker labels to that container. This is neccessary to connect to the different ports. Maybe I’ll provide a full script for that later…

Access your BC container from another client

At this point we can access the container from a different host machine by sending the HTTP request to the previously defined path prefix rule /bcserver. As my server is named cbserver (..apologies for the confusing names at this point..) the full path I’d send the request to is: https://cbserver/bcserver

You can already see that Traefik, in combination with a CI/CD pipeline that deploys your code at a certain stage, can be a powerful ally that allows you to provide access to these newly created containers. These can be named after the ID of the Pull Request in combination with the shortcut name of your extension app for example.

You can think of it like GitHub Codespaces, which basically allows you to check out a branch into a newly created container and continue developing based on that container and also access the web server. I’ll follow up on that with a blog post soon.

Conclusion

It’s very easy to make your containers accessible in your internal network so that otter clients can access the web-client and start testing the features. With the reverse proxy its also possible to make your containers available outside of your own network for example to demo it to your customers.

Make sure to watch the following presentation of Tobias Fenster² on NAV TechDays 2019. He also explains the usage of Container Orchestration in his scenario, which is taking it one step further.

Hope you learned something.

See you around 🦦

as you may already know, Microsoft announced in September ‘22 at BC TechDays¹ in the Collaborating on Business Central’s open source platform² session they are adding community members to their contribution pilot. If you didn’t make it to the eventor session, don’t worry. You can watch the sessions on the @mibuso.com YouTube-Channel³.

They also provide all previous NAV TechDays sessions in their YouTube-Playlist⁴. I definetly recommend you to visit their channel³. Their is so much valuable knowledge. A huge thanks to the organizers, partners and speakers making this event possible!

Before we start, you may have asked yourself: “Why would you add it yourself? Isn’t this Microsoft’s job?” Good question. Personally, I think there are so many possible answers to this, that I’ll leave the topic open for another blog post. For now, I would just leave this tweet by Natalie Karolak⁵, which more or less covers the topic imho:

Source: https://twitter.com/KarolakNatalie/status/1590375302227972099

Well… this blog post is not about the whole contribution pilot project itself. I think that Open Source is a huge step and a big opportunity for the BC Community to make the product even better than it already is today. But that’s another story.

Let’s focus on the technial part itself. As with any new project, chances are high that you’ll need to setup some requirements before you can develop locally. Especially in this different ecosystem it might not be as intuitive if you’ve never done it before. It’s not our usual environment, as we would normally load the dependenies by setting the application and plattform property in our app.json manifest file.

In the following steps, I describe how to setup a local development environment, so that you would be able to make changes to the Base Application and publish these changes.

Setup local development environment

This whole step is rather optional, since you most likely already have one or multiple containers up-and-running.

In the BC TechDays sesion² they run the ./Modules/.AL-Go/localDevEnv.ps1⁶ PowerShell script. However, I use my own PowerShell Script New-BcContainer.ps1 which you can find here: https://github.com/christianbraeunlich/bccontainerhelper-scripts. The repository itself, follows the wise words of Freddy Kristiansen: “Keep the script, not the Container”⁷.

You need the PowerShell module BcContainerHelper⁸ installed and imported.

Ofcourse you can use your own script or simply use the provided script by Microsoft:

$containerName = 'mydemo'
$password = 'P@ssw0rd'
$securePassword = ConvertTo-SecureString -String $password -AsPlainText -Force
$credential = New-Object pscredential 'admin', $securePassword
$auth = 'UserPassword'
$artifactUrl = Get-BcArtifactUrl -type 'OnPrem' -country 'w1' -select 'Latest'
$licenseFile = '<Path to license file>'
New-BcContainer -accept_eula `
    -containerName $containerName `
    -credential $credential `
    -auth $auth `
    -artifactUrl $artifactUrl `
    -includeTestToolkit `
    -includeTestLibrariesOnly `
    -licenseFile $licenseFile `
    -includeAL -doNotExportObjectsToText `
    -updateHosts

Source: https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/developer/devenv-set-up-an-environment#set-up-a-business-central-docker-container

Just make sure to select w1 as country.

For the provided code example to work you need to provide a valid developer license.

Now let’s move on to the actual steps.

Clone the git repository

Before you can clone the GitHub repository⁹ you need access to it. To get invited you need to contact for example Jesper Schulz-Wedder¹⁰ as he mentioned in one of his tweets:

Source: https://twitter.com/JesperSchulz/status/1570770745491587073

By the time of writing it is a private repository. It may be that the repository will be made public at some point in the future.

The following code snippet can be used in your terminal. Just change the directory and enter the following commands:

git clone https://github.com/microsoft/BusinessCentralApps
cd BusinessCentralApps
code .

A successful cloning step looks similar to this terminal output:

We change our directory to BusinessCentralApps. The command code . will open the current directory in VS Code and we will see the following structure in the VS Code Explorer:

At this point, the opened folder contains multiple projects, so we need to open the workspace.

Open the Workspace

As we like to make contributions to the Base Application, we can simply open the predefined workspace by opening the BaseAndTests.code-workspace file. Enter CTRL + P and search for code-workspace. Click on BaseAndTests.code-workspace.

After opening the BaseAndTests.code-workspace file the content looks similar to this:

Now click on the button in the bottom right corner that says Open Workspace.

Update settings

In order for the AL Language extension to find all the necessary DotNet libraries and to be able to compile the app, we need to add/update the following settings: https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/developer/devenv-set-up-an-environment.

"al.assemblyProbingPaths": [
  "C:/Windows/Microsoft.NET/Framework64/v4.0.30319",
  "C:/bcartifacts.cache/sandbox/21.2.49946.51329", // type and version number depends on the downloaded artifact
  "C:/WINDOWS/assembly"
],

With a project that big we’d like to further optimize the performance of our VS Code editor. You can follow the instructions provided by the documentation: https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/developer/devenv-optimize-visual-studio-code.

"al.backgroundCodeAnalysis": false,
"al.enableCodeActions": false,
"al.enableCodeAnalysis": false,
"al.incrementalBuild": true,
"editor.codeLens": false,
"[al]": {
  "editor.formatOnSave": false
}

After applying all the changes, your .vscode/settings.json file might look similar to this:

{
  ...
  "al.assemblyProbingPaths": [
    "C:/Windows/Microsoft.NET/Framework64/v4.0.30319",
    "C:/bcartifacts.cache/sandbox/21.2.49946.51329", // type and version number depends on the downloaded artifact
    "C:/WINDOWS/assembly"
  ],
  "al.backgroundCodeAnalysis": false,
  "al.enableCodeActions": false,
  "al.enableCodeAnalysis": false,
  "al.incrementalBuild": true,
  "editor.codeLens": false,
  "[al]": {
    "editor.formatOnSave": false
  }
  ...
}

But… nowadays, especially because there are +20 paths in the .code-workspace file, I recommend to add the launch and the settings keys to the .code-workspace file. Defining the launch property in here is possible since AL Language version 10.1 (see the changelog¹¹). If you need a more in-depth description, ZHU¹² got you covered in one of his amazing blog post: https://yzhums.com/32067/. In short: the information is inherited by all projects, so we end up with only one configuration file that works for all paths.

To add the previous configuration to the workspace settings, open the command pallet (F1 or CTRL + SHIFT + P) in an opened workspace and search for workspace settings. Click on the be prompted option Preferences: Open Workspace Settings (JSON). This will open the BaseAppTests.code-workspace file to which we can now add all the informations needed for us to compile and publish the app in the next steps. This is how the file could look like after applying the changes:

Which way you choose depends on your preferences.

At this point you can try and publish the Base Application, which most likely will end up with errors that we will fix in the next step.

Customize the app.json

We need to edit the app.json before we can publish the app to our local container. Enter CTRL + P on your keyboard and search for app.json base. The additional base keyword makes sure to filter the search results. Otherwise we would get too many files to choose from … efficiency is key.

change version

As the version numbers only change in their major and minor parts we can already assume that the installed version is higher due to the build and revision parts. All about the version numbers in Business Central you can read here: https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/administration/version-numbers

To make sure the version we publish is higher we can increase the major or minor part. I choose to increase the major part so that I don’t have to worry about it any time soon.

Fun fact: with this version number in place I might get some trouble with it by the year ~2062 when this version number becomes lower than the installed version.

add runtime

I’ve had to lower the runtime version to 10.1, as the default runtime (11.0 in this case) is not supported by the previously setup local container. You can try publishing it without adding this property.

Additional information about choosing a runtime version can be found here: https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/developer/devenv-choosing-runtime

Correct AL Language version

One step that is often completely ignored is that we should develop with the correct AL Language version. We can do this by downloading the ALLanguage.vsix file from our previously created container by navigating to http://containername/ALLanguage.vsix via the browser of choice.

After we successfully downloaded the file, open VS Code. Navigate to Extensions and select Install from VSIX…. Select the downloaded file ALLanguage.vsix. Now reload VS Code.

Publish

Select a file that is included in the BaseApp path of the opened Workspace. This way we make sure that we will publish the correct extension.

Now publish (without debugging) (CTRL + F5).

This might take a moment, depending on your hardware specs and current usage of your host machine. Would highly recommend you to have more than 16GB of memory.

Publishing took about +8 minutes for me (i5-6300U & 16GB RAM).

At this point you are ready to develop your first contribution to the contribution pilot. Please refer to the CONTRIBUTING.md¹³ in the microsoft/BusinessCentralApps GitHub repository⁹ on how to contribute.

Hope you learned something.

See you around 🦦

Credits to Frédéric Vercaemst¹⁴ who provided useful tips in the BusinessCentralApps discussion¹⁵.

Data is essential to any ERP system, unless the data is irrelevant or so old that it’s no longer needed (depending on your local policies). This is true whether you archive some records or create log entries for a feature of your extension. If these records would also store files in a blob field aswell, chances are that sooner or later you will run out of storage space.

As of Version 17.x (that’s already two years ago) Microsoft introduced the possibility to Define retention policies¹. Pretty big deal as this is a big productivity boost for developers and a good way for customers to keep control of the data (e.g. how long the data would be allowed to stay in the system, by defining a Retention Period).

If there is a risk of data loss, it is advisable to contact the extension publisher. Conclusion: only allow tables where the data is not important at all.

You can find the Retention Policies page by searching for retention via Tell Me:

After opening the Retention Policies page you will be displayed with the already created records. The list also gives you a quick overview of which records are enabled and which Retention Period is set for the individual entry:

As this list is company specific, it’s important to make use of an event that is triggered either after login or after initialization of a new company. This way we ensure that the tables are allowed for newly created companies. Check out my last blog post) for examples on Company-Initialize.

Without further ado, let’s take a look at an example:

codeunit 50100 "Module Installer"
{
    Subtype = Install;
    Access = Internal;
    Permissions = tabledata Field = r;

    trigger OnInstallAppPerCompany()
    begin
        AddRetentionPolicyAllowedTables();
    end;

    procedure AddRetentionPolicyAllowedTables()
    begin
        AddRetentionPolicyAllowedTables(false);
    end;

    procedure AddRetentionPolicyAllowedTables(ForceUpdate: Boolean)
    var
        Field: Record Field;
        UpgradeTag: Codeunit "Upgrade Tag";
        RetenPolAllowedTables: Codeunit "Reten. Pol. Allowed Tables";
        IsInitialSetup: Boolean;
    begin
        IsInitialSetup := not UpgradeTag.HasUpgradeTag(GetEmailTablesAddedToAllowedListUpgradeTag());
        if not (IsInitialSetup or ForceUpdate) then
            exit;

        RetenPolAllowedTables.AddAllowedTable(Database::"Demo Log");

        if IsInitialSetup then
            UpgradeTag.SetUpgradeTag(GetEmailTablesAddedToAllowedListUpgradeTag());
    end;

    local procedure GetEmailTablesAddedToAllowedListUpgradeTag(): Code[250]
    begin
        exit('CB-1234-DemoLogEntryAdded-20221217');
    end;

    [EventSubscriber(ObjectType::Codeunit, Codeunit::"Reten. Pol. Allowed Tables", 'OnRefreshAllowedTables', '', false, false)]
    local procedure AddAllowedTablesOnRefreshAllowedTables()
    begin
        AddRetentionPolicyAllowedTables(true);
    end;

    [EventSubscriber(ObjectType::Codeunit, Codeunit::"System Initialization", 'OnAfterLogin', '', false, false)]
    local procedure AddAllowedTablesOnAfterSystemInitialization()
    begin
        AddRetentionPolicyAllowedTables();
    end;
}

The code snippet above is a slightly modified copy of the 1596 “Email Installer” codeunit. There is a lot of overhead in this codeunit, I agree. The only relevant line for now is RetenPolAllowedTables.AddAllowedTable(Database::"Demo Log");. This will add our custom Demo Log table to the allowed tables that can be picked up by the Retention Policy. Only now we are able to add a new Retention Policy based on that table.

This simplified example is probably not sufficient because you only want to refer to specific records in this table. That’s where the procedure AddTableFilterToJsonArray comes in. But first take a look at the AddAllowedTable procedures from the 3905 “Reten. Pol. Allowed Tables” codeunit. Thanks to overloading we are looking for the procedure AddAllowedTable(TableId: Integer; TableFilters: JsonArray): Boolean. If you want to set the mandatory minimum retention days and still be able to filter you have to provide a few more parameters to the procedure AddAllowedTable(TableId: Integer; DefaultDateFieldNo: Integer; MandatoryMinRetenDays: Integer; RetenPolFiltering: Enum "Reten. Pol. Filtering"; RetenPolDeleting: Enum "Reten. Pol. Deleting"; TableFilters: JsonArray): Boolean.

The official documentation of the Define Data Retention Policies² provides the following example which includes a mandatory filter:

trigger OnInstallAppPerCompany()
var
    ChangeLogEntry: Record "Change Log Entry";
    RetenPolAllowedTables: Codeunit "Reten. Pol. Allowed Tables";
    RetentionPeriod: Enum "Retention Period Enum";
    RecRef: RecordRef;
    TableFilters: JsonArray;
    Enabled: Boolean;
    Mandatory: Boolean;
begin
    ChangeLogEntry.Reset();
    ChangeLogEntry.SetFilter("Field Log Entry Feature", '%1|%2', ChangeLogEntry."Field Log Entry Feature"::"Monitor Sensitive Fields", ChangeLogEntry."Field Log Entry Feature"::All);
    RecRef.GetTable(ChangeLogEntry);
    Enabled := true;
    Mandatory := true;
    RetenPolAllowedTables.AddTableFilterToJsonArray(TableFilters, RetentionPeriod::"28 Days", ChangeLogEntry.FieldNo(SystemCreatedAt), Enabled, Mandatory, RecRef);
    RetenPolAllowedTables.AddAllowedTable(Database::"Change Log Entry", ChangeLogEntry.FieldNo(SystemCreatedAt), TableFilters);
end;

At this point I would like to recommend to you to check out the blog post of Stefano Demiliani - Dynamics 365 Business Central: creating retention policies from AL³ and the blog post of Krzysztof Bialowas - Clean after yourself – a few words about Retention Policies⁴. These MVPs describe the feature in more depth.

If you are curious what’s inside the Retention Policy JQ you should check out the amazing repository⁵ provided by Stefan Maron.

Sometimes users are responsible and want to perform the action manually. In this case, the operation may fail due to insufficient permissions. Let’s have another look at the 1598 “Email Logs Delete” codeunit.

What we can see is a property Permissions on top of the object and an [EventSubscriber(ObjectType::Codeunit, Codeunit::"Apply Retention Policy", 'OnApplyRetentionPolicyIndirectPermissionRequired'.

    ...

    Permissions = tabledata "Demo Log" = rd;

    ...

    [EventSubscriber(ObjectType::Codeunit, Codeunit::"Apply Retention Policy", 'OnApplyRetentionPolicyIndirectPermissionRequired', '', true, true)]
    local procedure DeleteRecordsWithIndirectPermissionsOnApplyRetentionPolicyIndirectPermissionRequired(var RecRef: RecordRef; var Handled: Boolean)
    var
        RetentionPolicyLog: Codeunit "Retention Policy Log";
    begin
        if Handled then
            exit;

        if not (RecRef.Number in [Database::"Demo Log"]) then
            exit;

        // if no filters have been set, something is wrong.
        if (RecRef.GetFilters() = '') and (not RecRef.MarkedOnly()) then
            RetentionPolicyLog.LogError(Enum::"Retention Policy Log Category"::"Retention Policy - Apply", StrSubstNo(NoFiltersErr, RecRef.Number, RecRef.Name));

        RecRef.DeleteAll(true);
        Handled := true;
    end;

    ...

Notice that we create an error in the Retention Policy Log whenever no filters have been set.

This was a brief overview of the Retention Policy feature in Dynamics 365 Business Central.

Hope you learned something new.

See you around 🦦

Recently, I’ve come across a rarely used event called OnCompanyInitialize which is published by the Company-Initialize codeunit. In my case, I wanted to create a new evaluation company and found that some important configurations were missing in custom modules.

So whenever creating a new company, the event is triggered. This gives us the opportunity to initialize our modules with some pre-configurations for newly created companies.

Remember that the customer expects the extension to work the same way when creating additional companies as it did before.

Also notice that this is the recommended way by Microsoft: »If you are inserting data for a newly created company, we recommend subscribing to OnCompanyInitialize from Codeunit 2 instead.«¹

Let’s take a look at an example:

codeunit 56780 "CB Install"
{
  Subtype = Install;

  trigger OnInstallAppPerCompany()
  begin
    ModuleInitialization();
  end;

  [EventSubscriber(ObjectType::Codeunit, Codeunit::"Company-Initialize", 'OnCompanyInitialize', '', false, false)]
  local procedure ModuleInitialization()
  var
      ModuleSetup: Record "Module Setup";
  begin
      if not ModuleSetup.Get() then begin
          ModuleSetup.Init();
          ModuleSetup.Insert();
      end;
  end;
}

This way you don’t have to worry about an uninitialized setup record. All the additional initialization steps are bundled into the CompanyInitialize procedure, which is triggered by the OnCompanyInitialize EventSubscriber.

There is also a CodeCop rule AA0235² that checks if the OnCompanyInitialize EventSubscriber is added. They also noticed that many extensions were missing an OnCompanyInitialize subscription³, which again goes back to my issue from the beginning. I found out about this rule from this tweet: https://twitter.com/rvanbekkum/status/1598703510794674176

UPDATE (2023-01-02) - A question was asked: “What’s the difference between the events OnAfterInitialization and OnCompanyInitialize?”. Good question.

Recently the OnAfterInitialization event became obsolete and is replaced by OnAfterLogin. That is because the OnAfterLogin shares an awesome new feature called Isolated Event⁴ which means that each subscriber is executed in its own transaction.

Now with that in mind, what’s the difference between this new event and the OnCompanyInitialize event? The answer hides inside the BaseApp codeunit CompanyInitialize. So, let’s take a look:

[EventSubscriber(ObjectType::Codeunit, Codeunit::"System Initialization", 'OnAfterLogin', '', false, false)]
local procedure CompanyInitializeOnAfterLogin()
var
    ClientTypeManagement: Codeunit "Client Type Management";
begin
    ...
    InitializeCompany();
end;

For a better overview I cut out a few lines. It’s just important to know that the InitializeCompany procedure is called at the end of the OnAfterLogin EventSubscriber.

This internal procedure now calls the OnRun trigger of the Company-Initialize codeunit:

internal procedure InitializeCompany()
var
    GLSetup: Record "General Ledger Setup";
begin
    if not GLSetup.Get() then
        CODEUNIT.Run(CODEUNIT::"Company-Initialize");
end;

So in the end, the OnCompanyInitialize event gets published after the setup procedures in the OnRun trigger (also cut out some lines for a better overview).

    trigger OnRun()
    begin
        Window.Open(Text000);

        OnBeforeOnRun();

        InitSetupTables();
        AddOnIntegrMgt.InitMfgSetup();
        InitSourceCodeSetup();
        ...

        OnCompanyInitialize();

        Window.Close();

        Commit();
    end;

With all this in mind, Isolated Event is a great improvement to the overall sustainability of the product. With a wide range of possible extensions from the marketplace⁵ to install, we want everything to run as stable as possible without affecting other non-dependent extensions. Otherwise, incidents may occure and users may not be able to sign-in again.

Hope you learned something new.

See you around 🦦