Dynamics 365 Business Central in an Azure Container Instance

I recently came across this article, which talks about using the Azure Cloud Shell to create an Azure Container Instance that runs Dynamics 365 Business Central. I was intrigued because Azure Container Instances has just recently been released to the public and I just gotta try the new stuff! Thanks Andrey for that article!

What is an Azure Container Instance you might be asking? If you’ve been keeping up with Dynamics 365 Business Central development, you have been using containers to create your environments. This requires Docker to run either on a Windows 10 or Windows 2016 Server machine that’s either hosted or on-prem. Either way, you’re carrying the overhead of the machine, physical or virtual. With Azure Container Instances, you can create the containers directly in Azure without that machine overhead. This ‘should’ translate to some sort of cost savings, but as my container has only been up for about 2 hours as of the time of this article, I don’t yet know if or how much savings there will be.

In Andrey’s post, he walks you through using the Azure Portal and Azure Cloud Shell to create the container. Being the ‘lazy developer’ that I am though, I prefer to do as little manual work as possible so I thought I’d take a stab at building PowerShell script that I can run locally and potentially automate the entire process. Yup, even opening my browser to paste the code into Azure Cloud Shell is apparently too much work for me. 🙂

Turns, out this is pretty easy to do. Using the Azure Resource Manager PowerShell module, we can easily connect to our Azure account, and create the necessary container pieces.

Here’s how…

Connect-AzureRmAccount
The first thing we need to do is connect to our subscription and tenant. The user will be prompted for credentials when this command is executed. If you don’t know what your subscription and tenant IDs are, you can find instructions here for the subscription ID, and here for the tenant ID.

New-AzureRmResourceGroup
Once we’re connected we need to create the Azure Resource Group that will be used for our container instance.

New-AzureRmContainerGroup
Once the resource group is created now we can create the container. This is where we get to set the parameters for the container. One change I made from Andrey’s initial post is that I assigned the container the DnsNameLabel, which will mean we can use the Fqdn to access the container instead of the IP address. If you’ve used FreddyK‘s NavContainerHelper module, you’ll also notice that the parameters here are similar to some of the ones used by the New-NavContainer commandlet. Hey maybe we can get some new additions to the module for this stuff!

Ok…..here’s the actual code. It’s pretty basic at this point in time. Just getting my feet wet to see how it goes.

Install-Module AzureRM

### SET VARIABLES
$azureSubID = ''
$azureTenantID = ''
$azureResourceGroupName = 'myResourceGroup'
$azureLocation = 'EastUS'
$containerEnvVariables = @{ACCEPT_EULA='Y';USESSL='N'}
$containerImage = 'microsoft/bcsandbox:us'
$containerName = 'myContainer'

### CONNECT TO AZURE ACCOUNT
Connect-AzureRmAccount -Environment AzureCloud -Force -Subscription $azureSubID -TenantId $azureTenantID

### CREATE RESOURCE GROUP
New-AzureRmResourceGroup -Name $azureResourceGroupName -Location $azureLocation

### CREATE CONTAINER
New-AzureRmContainerGroup -Image $containerImage `
 -Name $containerName `
 -ResourceGroupName $azureResourceGroupName `
 -Cpu 2 `
 -EnvironmentVariable $containerEnvVariables `
 -IpAddressType Public `
 -MemoryInGB 4 `
 -OsType Windows `
 -DnsNameLabel $containerName ​
 -Port 80,443,7048,7049,8080 `
 -Location $azureLocation

Once you execute the above script, go grab a coffee. After about 15-20 minutes your container should be up and running. You can check on the state of your container using the following code:

Get-AzureRmContainerGroup -ResourceGroupName $azureResourceGroupName -Name $containerName

When you run the above code you’ll see various properties of the container. What you want to pay attention to are ProvisioningState and State, which will appear as ‘Creating‘ and ‘Pending‘ as shown below.

InkedAzContainerDeploy1_LI

 

Once the container has been created, you should see the following statuses:

InkedAzContainerDeploy2_LI.jpg

 

Take note of the Fqdn property and save the address value. This is the address that you will need to use to connect to your Business Central environment later on.

Once your container has a State of ‘Running‘, you can check the container logs by using the following code:

Get-AzureRmContainerInstanceLog -ContainerGroupName $containerName -ResourceGroupName $azureResourceGroupName

Running the above code will show you the container logs, and again, if you’ve been using the NavContainerHelper, these logs will look very familiar to you:

InkedContainerLogs_LI

 

Remember!!!
When you connect to your container via Visual Studio Code or the Web Client, or to download the VSIX, you need to use the address from the FQDN property of the container instance, and not the address values that you see in the container logs. See some examples below:

Insiders
If you have access to the private insider builds for Business Central, you need to provide credentials in order to access the Docker image registry. You can do that by adding the ‘-RegistryCredential‘ parameter and supplying a PSCredential object to the New-AzureRmContainerGroup command.

Oh, if you’re into this kind of thing, you can check out the Azure Container Instance SLA here. It’s a super fun read! 🙂

Thanks again to Andrey Baludin for his original post on Azure Container Instances!

Happy coding!

AL Extensions: Managing Version Numbering With VSTS Builds

I wanted to do this post to talk a bit more about something that Soren Klemmensen had in Part 2 of the blog series on automated builds with VSTS. We wanted to keep those original posts as simple as possible but there are a few more topics that we would like to expand upon.

In that particular post, he covered the PowerShell code needed to generate the AL extension using the ALC compiler tool, and in there is some interesting code around setting the version number of the extension package that gets created. That’s what I want to talk a bit more about here.

As we know, the version number that is assigned to the AL extension needs to be stored in the app.json that sits in the the AL project, and that value needs to be there before the compile process can be executed, like this:

ALExtensionVersion

Typically, this means that the developer is updating that value as needed before they compile and package the extension.

Wouldn’t it be nice to not have to have the developer do that every build? They’ve already got so much to worry about! 🙂

Well…it just so happens that one of the many great features in VSTS build definitions is the ability to automatically generate build numbers. Using a combination of static values and tokens, you’re able to generate any build number that you would like and in pretty much any format you would like.

You can read up on what tokens are available here, and how you can use them to build whatever format of build number you want.

In VSTS, these build numbers can be used to tag checkins so that you can track which checkin represents a build, but we’re going to leverage this and build ourselves a properly formatted version number that we will inject into the AL extension during the build process. This way, the developer can sit back and relax wait for the VSTS magic to happen!

Here’s how we’re going to do it…

1. Update build definition

We need to update our build definition to create our version number for us. We do that by populating the Build number format box on the Options tab of the build definition. Here’s where you can use the VSTS tokens and/or static text.

For this walkthrough, my version number needs to meet the following criteria:

  1. It will follow the standard #.#.#.# formatting that is required for an AL extension.
  2. It will be based on the date that the build is executed.
  3. I need to ensure I always get a unique version number even if I generate multiple builds in a day.
  4. This is the first version of my extension, so I want to make sure the version number begins with 1.0.

Given all of this criteria, I’ll populate the field like this:

BuildVersionFormat

As you can see, I am just hard-coding the “1.0.” so that every version I get begins the same. I’m using the date token (note the format can be changed if you like) so that the version contains the date on which the build is executed. Last but not least, I’m using the revision token to ensure that every time the build is executed I will get a unique version number. If you’re implementing Continuous Integration (and you really should!) you will certainly at some point have multiple builds done within the same day.

NOTE: The revision token is 1-based, so in my example the first build on a given day will end with .1 and not .0 (not what I would have preferred but what can you do).

2. Update build script

Remember I mentioned Soren’s post? In that post the following code is added to your build script. We only really need to update 1 line in this script, but I do want to talk about a few of the other lines so you know what’s going on here. The specific code we’re interested in is shown in red:

$ExtensionAppJsonFile = “.\app.json”
$ExtensionAppJsonObject = Get-Content -Raw -Path $ExtensionAppJsonFile | ConvertFrom-Json
$Publisher = $ExtensionAppJsonObject.Publisher
$Name = $ExtensionAppJsonObject.Name
$ExtensionAppJsonObject.Version = ‘1.0.’+$env:Build_BuildID + ‘.0’
$ExtensionName = $Publisher + ‘_’ + $Name + ‘_’ + $ExtensionAppJsonObject.Version + ‘.app’
$ExtensionAppJsonObject | ConvertTo-Json | set-content $ExtensionAppJsonFile
$ALProjectFolder = $env:System_DefaultWorkingDirectory
$ALPackageCachePath = ‘C:\ALBuild\Symbols’
Write-Host “Using Symbols Folder: ” $ALPackageCachePath
$ALCompilerPath = ‘C:\ALBuild\bin’
Write-Host “Using Compiler: ” $ALCompilerPath
$AlPackageOutPath = Join-Path -Path $env:Build_StagingDirectory -ChildPath $ExtensionName
Write-Host “Using Output Folder: ” $AlPackageOutPath
Set-Location -Path $ALCompilerPath
.\alc.exe /project:$ALProjectFolder /packagecachepath:$ALPackageCachePath /out:$AlPackageOutPath

 

The first 2 lines of highlighted code read the app.json file from the AL project into a PowerShell object using ConvertFrom-Json. This will allow us to read/write any of the properties within the json file:

$ExtensionAppJsonFile = ".\app.json"
$ExtensionAppJsonObject = Get-Content -Raw -Path $ExtensionAppJsonFile | ConvertFrom-Json

Now what we want to do is update the Version property with the build number that our VSTS build definition generated. We can get that value by using one of the environment variables that VSTS makes available while the build process is running. There are a bunch of environment variables available to us (see here for more info) but the one that we’re interested in is Build.BuildNumber. The value in this variable is the value that VSTS generated based on the Build number format that you populated in your build definition. If you leave that field blank, then this environment variable would be empty.

This is where we need to replace some of the code from Soren’s post. The original code (shown below) sets the version number to Build.BuildID, which is the identifier that VSTS assigns to each build:

$ExtensionAppJsonObject.Version = ‘1.0.’+$env:Build_BuildID + ‘.0’

Since we want to control the version number format using our build definition, this is where we need to make a small change. We’ll replace the above line of code with the following that will update the Version property to Build.BuildNumber:

$ExtensionAppJsonObject.Version = $env:Build_BuildNumber

Notes

  • To access VSTS environment variables in your PowerShell script, begin the variable name with ‘$env:’ and replace ‘.’ with ‘_’.
  • Because this environment variables are only generated during the build process you will not be able to manually run your PowerShell script to test the values of these variables.

Finally, we need to write our changes to the app.json file as so far we’ve only made the changes in the PowerShell object We use ConvertTo-Json for that:

$ExtensionAppJsonObject | ConvertTo-Json | set-content $ExtensionAppJsonFile

That’s It!

After you’ve done the above updates to your build definition and script, when you generate your build either manually or via trigger, your packaged AL extension will have version numbers similar to the following:

1.0.20180407.1   (first build of the day)
1.0.20180407.2   (second build of the day)
1.0.20180407.3   (third build of the day)
1.0.20180407.n   (nth build of the day)

Source code management

One of the obvious questions if you implement your build process like this is that if the version number is only updated at the time the build is done, what happens with source code management? Well to be honest, I do not track the version number of my extension in source code management at all.

Personally, I don’t see the value since when my build runs, it tags the checkin that represents that build, so at any point in time I can go back and find the source code for any build that I’ve done, and if I need to I can rebuild it.

So what do I keep in source code management? I keep all of my extension versions permanently set to ‘0.0.0.0’. This means that no developer ever needs to touch the version property during the development stage. It also helps identify if a database has a released version of my extension installed versus a pre-release development version, which does happen from time to time.

Hopefully you’ve found this useful and you’ve now updated your build definition to provide you the exact version number format that you want.

For a listing of the all the automated build articles, see my post here.

That’s it for now, happy coding!

AL Extensions: Automated Builds with VSTS

Hello there,

I recently spent a few hours with Soren Klemmensen, whom I have known for many years. He was actually the one who introduced me to source code management, at which I swore I’d never be happy using it because it was just “development overhead”. Story for another day, but rest assured, that’s not at all how I feel now. I cannot live without Visual Studio Team Services (VSTS)!

In any case, aside from catching up on things, we decided to put together a series of articles on automating builds using VSTS and AL Extensions.Having been the person who has spent countless hours manually doing “the build”, I cannot express how happy I was to push all of that off to automation so that “it just happens”.

Below is where you can find the articles. They’ll walk you through setting up a simple build to start, and from there we’ll build on it with some more advanced topics, such as having VSTS sign your app during the build!

Part 1: How to setup a build agent in VSTS

Part 2: Prepping your build server for creating Apps from source

Part 3: Creating a build definition

Part 4: Preparing your build server for code signing

Part 5: Updating your build server for code signing

There you have it, the first articles covering automating builds for AL extensions using VSTS.

Also, don’t forget that you can sign up for a VSTS account for free, and with that account you can have up to 5 developers use it, so for some, you just might be able to make use of the free account! There’s really no reason to not use it!

That’s all for now, this is not the end of the articles on this topic, so keep an eye out here and on Soren’s blog for more information in the future.

Happy coding….

AL Extensions: Reading JSON info with Powershell

A quick post today on how to read values from a JSON file with PowerShell.

PowerShell contains the commandlet ConvertFrom-Json, which as its name implies, converts a JSON object into a PowerShell object, from which you can then access the values and read them into variables, etc.

Let’s assume we have a file named MyFile.json, which contains the following JSON object:

{
   "id": "123456",
   "name": "MyObjectName"
}

We can convert this into a PowerShell object with the following code:

$JsonObject = Get-Content -Raw -Path .\MyFile.json | ConvertFrom-Json

We can then read the value of  name into a variable like this:

$Name = $JsonObject.Name

SO WHAT?

As the title of this post suggests, we can make use of this handy code with our AL extensions.

In my previous post, I showed you how to create a custom AL extension build task with Visual Studio Code. You can expand on this and launch a PowerShell script to execute the ALC compiler. When you do that, one of the parameters you can supply to the compiler is the output path and resulting app file name. By using the app.json file that is part of every AL extension, you can utilize things such as the extension publisher, name, version, etc. in your compiler process.

You can do something like the following…

$JsonObject = Get-Content -Raw -Path .\app.json | ConvertFrom-Json

$ExtensionName = $JsonObject.Publisher + '_' + $JsonObject.Name + '_' + $JsonObject.Version + '.app'

$CompilerPath = 'C:\Users\<username>\.vscode\extensions\Microsoft.al-0.10.13928\bin'

$ALProjectFolder = 'C:\MyProjectFolder'
$ALPackageCachePath = Join-Path -Path $ALProjectFolder -ChildPath '.alPackages'
$AlPackageOutFilePath = Join-Path -Path 'C:\MyCustomOutputFolder' -ChildPath $ExtensionName

Set-Location -Path $CompilerPath
.\alc.exe /project:$ALProjectFolder /packagecachepath:$ALPackageCachePath /out:$AlPackageOutFilePath

…which would replicate the same file name that the out of box compile process does, but will still allow you to direct the file to be output to a custom path. For example, maybe a shared AL package cache that you use for multiple developers.

Until next time, happy coding!

AL Extensions: Custom Build Process Using Visual Studio Code Tasks

I recently discovered the Tasks menu in Visual Studio Code and after a bit of wondering why I’ve not seen it after using VS Code for many months, I then took a quick look into what it was all about.

Turns out VS Code has yet another amazing feature called Tasks, which let’s you automate things such as builds, packaging, deployment, and probably whatever else you can think of. You can read all about tasks in detail here.

This got me thinking, I wonder if I can use this to make my own build process for AL extensions? Turns out this is quite easy…and here’s how you can do it.

Open up your AL extension folder and select Tasks > Configure Tasks.

TasksConfigureTasks

In the command palette select Create tasks.json from template.

CommandBoxConfigureTasks

In the command palette select Others.

CommandBoxSelectOthers

You’ll now see a tasks.json file create in the .vscode folder of your AL project.

tasksJsonFile

In the tasks.json file you’ll see some default settings like this:

{
    // See https://go.microsoft.com/fwlink/?LinkId=733558
    // for the documentation about the tasks.json format
    "version": "2.0.0",
    "tasks": [
        {
            "taskName": "echo",
            "type": "shell",
            "command": "echo Hello"
        }
    ]
}

We need to change the task command so that we build our AL extension. When you install the AL Language extension, behind the scenes is installed a command line compiler (alc.exe). The alc compiler accepts 3 parameters:

  1. project: The path to the AL project folder
  2. packagecachepath: The path to the folder containing the reference packages
  3. out: The path to output the packaged extension app file to. This parameter is optional. If it’s not specified then the compiler will output the app file in the project folder with the default name of <Publisher>_<Name>_<Version>.app

For example, in order to build our AL extension with the default output and name, we’d need a command such as this:

C:\Users\<username>\.vscode\extensions\Microsoft.al-0.10.13928\bin\alc.exe /project:C:\ALProject1 /packagecachepath:C:\ALProject1\.alpackages

One more quick thing before we continue. Within VS Code tasks, you have access to some predefined variables. You can read about what they are here. For our task, we’re interested in the ${workspaceFolder} variable, which will give us the path to the workspace folder of the project.

Back to the VS Code task. We need to update the tasks.json file now. We’ll change the taskName property to a more meaningful name, and we’ll update the command property to execute our alc compiler. Make sure to note the double slashes and that you replace the <username> and AL Language extension version number with the correct one as per your environment.

{
    // See https://go.microsoft.com/fwlink/?LinkId=733558
    // for the documentation about the tasks.json format
    "version": "2.0.0",
    "tasks": [
        {
            "taskName": "Offline Build",
            "type": "shell",
            "command": "C:\\Users\\<username>\\.vscode\\extensions\\Microsoft.al-0.10.13928\\bin\\alc.exe /project:${workspaceFolder} /packagecachepath:${workspaceFolder}\\.alpackages"
        }
    ]
}

Now that we’ve updated the task file, you need to set this task as the default build command. To do that you select Tasks > Configure Default Build Task from the menu. Doing this will not change the existing F5 or Ctrl+F5 commands that Microsoft delivers with the AL Language extension.

TasksConfigureDefaultBuildTask.png

In the command palette select the name of the task you created above. In my case, I’ve named the task Offline Build.

CommandBoxSelectTaskName

The following lines were just added to your tasks.json file:

"group": {
    "kind": "build",
    "isDefault": true
}

You can close and save the tasks.json file now if you still have it open. You’re ready to use your new build task in the following ways:

  1. Tasks > Run Task
    • With this method you can select to run any task that you’ve created.
  2. Tasks > Run Build Task
    • This will work only if you’ve made your task the default build task.
  3. Ctrl+Shift+B
    • This will work only if you’ve made your task the default build task.

No matter what method you choose to execute the task, you can monitor it for errors in the VS Code terminal window.

TerminalWindowOutput

That’s it! Now you’ve got a way to build your extension without having to deploy it at the same time.

Pretty sure I’ve only scratched the surface on what VS Code tasks can do, so I’m excited to see how else I can make use of them in my AL development.

Until next time…..happy coding!