Overview of Dynamics 365 Business Central October ’18 release

Original URL…

Improved Visual Studio Code AL experience

Be more productive when developing and troubleshooting extensions with new and improved developer tools, such as sandbox environments with production data, improved breakpoint support, better inline Help, ability to trace raised events in a given user scenario, support for .NET Interop for on-premises deployments, extension support for enums, report data set and field groups, and more.

Anuncios

A way to deal with Extension IDs in NAV (Business Central) AL

Original URL...

In AL VS Code Extensions V2, if you try to create an extension and the ID or Name are already used, you get this error:

Because we don’t have the extension id in the name of the file (I assume you don’t have it either), you can use the following Powershell script to check what files are using the same name for example (change according to your need):

1
2
3
4
$Folder = 'your folder\with extensions'
$SearchString = 'pageextension50545' #your search string
$File = (Get-ChildItem $Folder -Filter '*.al' |
Where-Object {Select-String $SearchString $_}).Name
$File

This code will search for the string in the first line of each file and show you what files contain the same Id/name:

! Ok, this was the easy part. Now I want to assign a different Id (the next free Id) for my current file, in order to fix the error. But which is the next ID ? In good old C/SIDE it was so easy to find out things like this…

In order to find out the next free Id in AL, I need to look in each file and compare all the Ids to see which one is the greatest. The problem is that by now I have 200-300 files, so it will probably take around one week to do this manually…

Not when we have Powershell 🙂

First let’s see the situation from my example (you can then adapt the script for your own situation):

–> I have 1 folder with 2 sub folders with AL Page Extension files:
* Files in folder 1 are named like this:

* Files in folder 2 are named like this:

* The first line of each file contains information about the page extension like this:
pageextension 50333 pageextension50333 extends “Bank Account Card”

So, let’s look automatically in each file at the first line, create an array with the IDs, Object Name that it extends and other useful information about the files:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
Function Get-ALExtensionFilesInfo{
    [CmdletBinding()]
    param(
        [Parameter(Mandatory=$true)][array]$ALExtensionFiles,
        [switch]$GetIDFromExtensionName,
        [switch]$GetObjectNameFromFileName
        )
    If($GetIDFromExtensionName) {
        #let's complicate things for practice with
regex and extract the ID from the extension
name instead of simply take the Id
        [regex]$Regex = '[a-zA-Z]+(?<num>\d+)'
    } else {
        [regex]$Regex = '(?<num>\b\d+)'
    }
    $ExtensionNumbers = @()
    foreach($File in $ALExtensionFiles)
    {
        $ExtHash = @{}
        $stringfirstline = (Select-String
-InputObject $file -Pattern $RegEx | select-object -First 1).Line
        $m = $Regex.Matches($stringfirstline)
        $number = ($m[0].Groups["num"].Value) * 1
        $ExtHash.Add("FileName",$File.FullName)
        If(!$GetObjectNameFromFileName) {
            #match the object name from the first line
(after word 'extends'):
            $ExtHash.Add("ObjectName",(([regex]::Match
($stringfirstline,'(?<=extends ).*').Value) -replace '"','').TrimEnd())
        } else {
            #OR match the object name from file name: ex Name of file is 'PEX50343 - Test.al' or 'PEX - Test.al'; Object Name is 'Test.al'
            $ExtHash.Add("ObjectName",[regex]::Match($File.Name,'(?<=PEX(?:\d+)? - ).*').Value)
        }
        
        $ExtHash.Add("ExtensionNumber",$number)
        $ExtHash.Add("ExtensionType",[regex]::Match($stringfirstline,'^\b\w+'))
        $PsObject = New-Object PSObject -property $ExtHash
        $ExtensionNumbers += $PsObject
    }
    return $ExtensionNumbers
}

Let’s see how to use this function:

1
2
3
4
5
6
7
8
$Folder = 'C:\ALExtensionIdsSample\Folder 1'
$Folder2 = 'C:\ALExtensionIdsSample\Folder 2'
$Files = Get-ChildItem $Folder -Filter '*.al'
$Files += Get-ChildItem $Folder2 -Filter '*.al'
#get the info from extension files
$ExtensionInfo = Get-ALExtensionFilesInfo -ALExtensionFiles $Files
$ExtensionInfo

–> And now we have an array with custom objects that we can use:

For example, to get the last used extension ID for page extensions:

1
2
3
4
5
6
#get the maximum used id for page extensions
$MaxMinNo = $ExtensionInfo |
            Where-Object{$_.ExtensionType -like 'pageextension'} |
            Measure-Object -Property ExtensionNumber -Maximum -Minimum
$ExtensionInfo | Where-Object {($_.ExtensionNumber -eq $MaxMinNo.Maximum) -and
                               ($_.ExtensionType -like 'pageextension')}

Output:

Or I know I have a page Extension for page “Tranfer Order” and I want to retrieve the Id:

1
2
$ExtensionInfo | Where-Object{($_.ObjectName -like 'Transfer Order') -and
                              ($_.ExtensionType -like 'pageextension')}

Output:

–> Or the opposite example when I have the Extension Id and I need to find out the Name of the Object that it extends:

1
2
3
$ExtensionInfo | Where-Object{($_.ExtensionNumber -eq 50292) -and
                              ($_.ExtensionType -like 'pageextension')} |
                 Select-Object -Property ObjectName

Output:

For this script I used some simple powershell commands and a little bit of Regex. This is not a final product, but more a script made quickly when I was in need 🙂

What do you say, would it be helpful a Powerhell module with functions for this kind of stuff ? Or maybe we should just wait for Microsoft to provide a better way of dealing with Extension Ids (or maybe they plan to not use Ids in the future) ?

You can find these scripts also on my GitHub:
https://github.com/andreilungu/Utilities/tree/master/Powershell
Filename: 001_GetALExtensionIDandObjectName.ps1

*Later Edit:
In the meantime I created a small Powershell module to help you get information about AL Extension Files. You can read

Example – Hello World – Your first extension

Original URL…

Extending Visual Studio Code

Your first extension

This document will guide you through creating your first VS Code extension (“Hello World”) and explain the basic VS Code extensibility concepts.

In this walkthrough, you’ll add a new command to VS Code which will display a simple “Hello World” message. Later in the walkthrough, you’ll interact with the VS Code editor and query for the user’s currently selected text.

Prerequisites

You need Node.js installed and available in your $PATH. Node.js includes npm, the Node.js Package Manager, which will be used to install the extension generator.

Generate a new extension

The simplest way to add your own functionality to VS Code is through adding a command. A command registers a callback function which can be invoked from the Command Palette or with a key binding.

We have written a Yeoman generator to help get you started. Install Yeoman and the Yeoman VS Code Extension generator and scaffold a new extension:

npm install -g yo generator-code
yo code

For the hello world extension, you can either create a TypeScript extension or a JavaScript one. For this example, we pick a TypeScript extension.

The command generator

Running your extension

  • Launch VS Code, choose File > Open Folder and pick the folder that you generated.
  • Press F5 or click on the Debug icon and click Start.
  • A new instance of VS Code will start in a special mode (Extension Development Host) and this new instance is now aware of your extension.
  • Press Ctrl+Shift+P and run the command named Hello World.
  • Congratulations! You’ve just created and executed your first VS Code command!

Running VS Code with an extension

The structure of an extension

After running, the generated extension should have the following structure:

.
├── .gitignore
├── .vscode                     // VS Code integration
│   ├── launch.json
│   ├── settings.json
│   └── tasks.json
├── .vscodeignore               // files ignored when publishing extension
├── README.md
├── src
│   └── extension.ts            // the source of the extension entry point
├── test                        // test folder
│   ├── extension.test.ts       // extension.test.js, in case of JavaScript extension
│   └── index.ts                // index.js, in case of JavaScript extension
├── node_modules
│   ├── vscode                  // include vscode type definition file 
for extension development
│   └── typescript              // compiler for typescript (TypeScript only)
├── out                         // compilation output (TypeScript only)
│   ├── extension.js            // the extension entry point
│   ├── extension.js.map
│   └── test
│       ├── extension.test.js
│       ├── extension.test.js.map
│       ├── index.js
│       └── index.js.map
├── package.json                // extension's manifest
├── tsconfig.json               // jsconfig.json, in case of JavaScript extension
└── vsc-extension-quickstart.md // extension development quick start

Let’s go through the purpose of all these files and explain what they do:

The extension manifest: package.json

Example TypeScript extension manifest

{
    "name": "myFirstExtension",
    "description": "",
    "version": "0.0.1",
    "publisher": "",
    "engines": {
        "vscode": "^1.5.0"
    },
    "categories": [
        "Other"
    ],
    "activationEvents": [
        "onCommand:extension.sayHello"
    ],
    "main": "./out/extension",
    "contributes": {
        "commands": [{
            "command": "extension.sayHello",
            "title": "Hello World"
        }]
    },
    "scripts": {
        "vscode:prepublish": "tsc -p ./",
        "compile": "tsc -watch -p ./",
        "postinstall": "node ./node_modules/vscode/bin/install",
        "test": "node ./node_modules/vscode/bin/test"
    },
    "devDependencies": {
       "typescript": "^2.0.3",
        "vscode": "^1.5.0",
        "mocha": "^2.3.3",
        "@types/node": "^6.0.40",
        "@types/mocha": "^2.2.32"
   }
}

Note: A JavaScript extension doesn’t require the scripts field as no compilation is needed.

This specific package.json describes an extension that:

  • contributes an entry to the Command Palette (Ctrl+Shift+P) with the label "Hello world" that will invoke a command "extension.sayHello".
  • requests to get loaded (activationEvents) when the command "extension.sayHello" is invoked.
  • has its main JavaScript code in a file called "./out/extension.js".

Note: VS Code does not load the code of an extension eagerly at start-up. An extension must describe, through the activationEvents property under what conditions it should get activated (loaded).

Generated code

The generated extension’s code is in extension.ts (or extension.js in case of a JavaScript extension):

// The module 'vscode' contains the VS Code extensibility API
// Import the module and reference it with the alias vscode in your code below
import * as vscode from 'vscode';

// this method is called when your extension is activated
// your extension is activated the very first time the command is executed
export function activate(context: vscode.ExtensionContext) {

    // Use the console to output diagnostic information (console.log) and 
errors (console.error)
    // This line of code will only be executed once when your extension is activated
    console.log('Congratulations, your extension "my-first-extension" is now 
active!');

    // The command has been defined in the package.json file
    // Now provide the implementation of the command with  registerCommand
    // The commandId parameter must match the command field in package.json
    let disposable = vscode.commands.registerCommand('extension.sayHello', () => {
        // The code you place here will be executed every time your 
command is executed

        // Display a message box to the user
        vscode.window.showInformationMessage('Hello World!');
    });

    context.subscriptions.push(disposable);
}
  • Each extension should export from its main file a function named activate(), which VS Code will invoke only once when any of the activationEvents described in the package.json file occur.
  • If an extension makes use of OS resources (e.g. spawns processes), the extension can export from its main file a function named deactivate() where it can do clean-up work and VS Code will invoke that function on shutdown.
  • This specific extension imports the vscode API and then registers a command, associating a function to be called when the command "extension.sayHello" gets invoked. The command’s implementation displays a “Hello world” message in VS Code.

Note: The contributes section of the package.json adds an entry to the Command Palette. The code in extension.ts/.js defines the implementation of "extension.sayHello".

Note: For TypeScript extensions, the generated file out/extension.js will be loaded at runtime and executed by VS Code.

Miscellaneous files

  • .vscode/launch.json defines launching VS Code in the Extension Development mode. It also points with preLaunchTask to a task defined in .vscode/tasks.json that runs the TypeScript compiler.
  • .vscode/settings.json by default excludes the out folder. You can modify which file types you want to hide.
  • .gitignore – Tells Git version control which patterns to ignore.
  • .vscodeignore – Tells the packaging tool which files to ignore when publishing the extension.
  • README.md – README file describing your extension for VS Code users.
  • vsc-extension-quickstart.md – A Quick Start guide for you.
  • test/extension.test.ts – you can put your extension unit tests in here and run your tests against the VS Code API (see Testing Your Extension)

Extension activation

Now that the roles of the files included in the extension are clarified, here is how your extension gets activated:

  • The extension development instance discovers the extension and reads its package.json file.
  • Later when you press Ctrl+Shift+P:
  • The registered commands are displayed in the Command Palette.
  • In this list there is now an entry "Hello world" that is defined in the package.json.
  • When selecting the "Hello world" command:
  • The command "extension.sayHello" is invoked:
    • An activation event "onCommand:extension.sayHello" is created.
    • All extensions listing this activation event in their activationEvents are activated.
      • The file at ./out/extension.js gets loaded in the JavaScript VM.
      • VS Code looks for an exported function activate and calls it.
      • The command "extension.sayHello" is registered and its implementation is now defined.
  • The command "extension.sayHello" implementation function is invoked.
  • The command implementation displays the “Hello World” message.

Debugging your extension

Set a breakpoint, for example inside the registered command, and run the "Hello world" command in the Extension Development VS Code instance.

Debugging the extension

Note: For TypeScript extensions, even though VS Code loads and executes out/extension.js, you are actually able to debug the original TypeScript code due to the generated source map out/extension.js.map and VS Code’s debugger support for source maps.

Tip: The Debug Console will show all the messages you log to the console.

To learn more about the extension development environment.

A simple change

In extension.ts (or extension.js, in a JavaScript extension), try replacing the extension.sayHello command implementation to show the number of characters selected in the editor:

    let disposable = vscode.commands.registerCommand('extension.sayHello', () => {
        // The code you place here will be executed every time your 
command is executed

        let editor = vscode.window.activeTextEditor;
        if (!editor) {
            return; // No open text editor
        }

        let selection = editor.selection;
        let text = editor.document.getText(selection);

        // Display a message box to the user
        vscode.window.showInformationMessage('Selected characters: ' + text.length);
    });

Tip: Once you make changes to the extension source code, you need to restart the Extension Development Host instance of VS Code. You can do that by using Ctrl+R (macOS: Cmd+R) in the Extension Development Host instance or by clicking the Restart button at the top of your primary VS Code instance.

Create a file (File > New File), type some text and select it. When you run the Hello World command, you should now see the count of selected characters.

Running the modified extension

Installing your extension locally

So far, the extension you have written only runs in a special instance of VS Code, the Extension Development instance. To get your extension running in all instances of VS Code, you need to copy it to a new folder under your local extensions folder:

  • Windows: %USERPROFILE%\.vscode\extensions
  • macOS/Linux: $HOME/.vscode/extensions

Publishing your extension

Read about how to Share an Extension.

Next Steps

In this walkthrough, we’ve seen a very simple extension. For a more detailed example, see the Word Count Example which shows how to target a specific language (Markdown) and listen to the editor’s document changed events.

If you’d like to read more generally about the extension APIs, try these topics:

How to get the new Dynamics 365 Business Central and extend it

Original URL…

What is it?

Dynamics 365 Business Central is the new and, I hope, the last official name of Dynamics NAV.

No more Dynamics 365 Finance and operations Business Edition, no more Dynamics 365 “Tenerife”, even no more Dynamics NAV (basically it is yes now, until Q4 2018, when D365BC on-premise will be released)!

The official announcement was made 4 days ago and can be found here.

2 days after at DirectionsASIA we’ve got much more information about the product from Microsoft team.

The official hashtag is #MSDyn365BC, and if you will search it on twitter you will find a huge portion of images and info about new web client, new roadmap, new possibilities and so on.

But this blog is not about What’s new staff. It is about How to get it?

Step 1. Register on collaborate portal

If you are already registered – skip it. If not, go to https://aka.ms/collaborate and register.

The registration process is very nice described here https://docs.microsoft.com/en-us/collaborate/registration

Just go steps by steps, and you should be able to see this

 

Step 2. Register on Ready to Go program (Updated)

After publishing first version of this blog, I’ve got many questions about why D365BC is not visible on collaboration portal. Because of this step was missed. Sorry. Updated.

If you are already registered – skip it. If not you should sign up for Ready to Go program http://aka.ms/ReadyToGo

To do so, after step 1, please write an e-mail to Dyn365BEP@microsoft.com

When contacting, please provide following information:

Publisher display name Name Email Role
Chosen during registration, should be the same for all users User 1 Email 1 Power user (can access content and add new users to engagements)
User 2 Email 2 Participant (can access content)
Etc. Etc. Power user

The registration process should take 1-2 business days.

After successful registration, you will be able to see this

 

YES! This is pre-release version of NEW Dynamics 365 Business Central.

If you click on it you will find something interesting, guess what?

.Zip, DVD?  No =)

You will find 2kb txt file with instructions of …. How to get it via Docker.

Download it.

Advantages of Ready to Go program

Ready to Go program, it is not only the possibility to download and play with pre-release versions of Dynamics 365 Business Central.

The idea is to prepare every partner for new SaaS world. It consists of training materials on http://aka.ms/ReadyToGoOnlineLearning and also potentially coaching through a Development Centres

BTW. If you want to prepare yourself for new modern SaaS world, you can also contact me for individual workshops and coaching.

Step 3. Create new Docker container with Dynamics 365 Business Central

But first, Install Docker.

If you don’t have docker, then download and install it. You can choose to download a full docker client or only a module.

You can download and install docker as a module executing this code in PowerShell

invoke-webrequest -UseBasicparsing -Outfile docker-17.09.0-ce.zip 
https://download.docker.com/win/static/stable/x86_64/docker-17.09.0-ce.zip
# Extract the archive.
Expand-Archive docker-17.09.0-ce.zip -DestinationPath $Env:ProgramFiles

# Clean up the zip file.
Remove-Item -Force docker-17.09.0-ce.zip

# Install Docker. This requires rebooting.
$null = Install-WindowsFeature containers

# Add Docker to the path for the current session.
$env:path += ";$env:ProgramFiles\docker"

# Optionally, modify PATH to persist across sessions.
$newPath = "$env:ProgramFiles\docker;" +
[Environment]::GetEnvironmentVariable("PATH",
[EnvironmentVariableTarget]::Machine)

[Environment]::SetEnvironmentVariable("PATH", $newPath,
[EnvironmentVariableTarget]::Machine)

# Register the Docker daemon as a service.
dockerd --register-service

# Start the Docker service.
Start-Service docker

#Next steps are optional!

#Run test container, to check that Docker is alive
docker container run hello-world:nanoserver

# Check what containers do you have
docker ps

Next, install Navcontainerhelper

I personally love what Freddy has done to us. So I will use navcontainerhelper to simplify my work.

Run next script in PowerShell

Install-Module -Name navcontainerhelper -Verbose

If, you are running it on Windows10, check that your policy is allowed you to install new modules.

If it is restricted, then change it

Create new D365 Business Central container

1)    Login to azure container register, to be able to pull (download) D365BE Image (also in powershell).

docker login "navinsider.azurecr.io" -u 
"insert-user-id-here-from-Build-21063.txt-file" -p " 
insert-password-here-from-Build-21063.txt-file "

2)    Choose what version of Business Central do you want.

Currently available 14 Versions and W1!

dynamics-nav:11.0.21063.0

dynamics-nav:11.0.21063.0-finat

dynamics-nav:11.0.21063.0-finbe

dynamics-nav:11.0.21063.0-finca

dynamics-nav:11.0.21063.0-finch

dynamics-nav:11.0.21063.0-finde

dynamics-nav:11.0.21063.0-findk

dynamics-nav:11.0.21063.0-fines

dynamics-nav:11.0.21063.0-finfi

dynamics-nav:11.0.21063.0-finfr

dynamics-nav:11.0.21063.0-fingb

dynamics-nav:11.0.21063.0-finit

dynamics-nav:11.0.21063.0-finnl

dynamics-nav:11.0.21063.0-finse

dynamics-nav:11.0.21063.0-finus

3)    Create new container

I will use W1 version, so I run next command in PowerShell

New-NavContainer -accept_eula -alwaysPull -imageName 
"navinsider.azurecr.io/dynamics-nav:11.0.21063.0" -containerName D365BC-W1

and after a while – about 5 minutes of pulling (depends on your internet speed), and 2 minutes of initialization – we have it!

This wonderful, modern look and feel web UI

Hmm…. Not really what I was expected =)

Let’s try old trick =) We will add ?aid=fin to the end of our URL.

So url will be http://d365bc-w1/nav/?aid=fin

 

Much better now!

By the way, if you will create a container from US image (dynamics-nav:11.0.21063.0-finus), then we will have new web UI by default.

 

Step 4. Extend it!

Install Visual Studio Code AL extension

First copy .vsix file on your host.

To do so, copy a link to vsix file from container creation log

Open it in a browser

Click Save.

Open Visual Studio Code. Go to Extentions -> … -> Install From Vsix

Create new AL project

As usual, press Crtl + Shift + P -> AL:Go

We change server in launch.json (take it from container creation log), and authentication to Windows.

Press Crtl + Shift + P -> AL:Download Symbols

Then we will create some new code.

We will add one more insight to RoleCenter. This is really wow feature of new UI.

After publishing (ctrl+F5) we will see new insight!

And we’ve done!

I encourage you to take all advantages of Collaborate and start exploring Dynamics 365 Business Central right now!

CRS AL Language Extension – File Management

Original URL…

Time for the next round of functionality I added in my VSCode Extension (the CRS AL Language Extension) – a functionality that manages your filenames (and pre/suffix). Hold your horses – this is going to be a long one ;-). You don’t want to know how many hours I spent on this functionality – many points of feedback from the community, and even some pullrequests from some (for all of which I’m very thankful!) has made it into the functionality it is today.

The problem(s) I wanted to solve

There are multiple problems with filenames, to be honest.

We never cared about this

In a way, we are not used to deal with filenames, because in C/AL, we simply have an object designer – which only needs an object name. So, this is new!

There is a “File name convention”

On top of that, there is even a file name convention that Microsoft wants us to follow. You can find them here on Docs. When you read carefully through it, you’ll see that it gives some practical challenges:

  • Every name has the object ID
    • I don’t know that object ID when I create the file?
    • But I need to create the file first to give it the al-extension, to put the client in language mode “al”
    • What if I renumber my object – then I need to think about renaming the file as well!
  • Every name has also the object name – what if I rename my object -then I need to think about renaming the file as well!
And what about subfolders?

Next to that, it is not a good practice to have our files all in the root – so we should be putting that into subfolders. Microsoft’s recommendation is to have:

  • \Src – for source code
  • \Res – for resources (whatever that means – control addins?)
  • \Text – for testability

And within these subfolders, you can create a next level of subfolders. I would recommend subfolders that indicate a certain functionality. Many people create subfolders by object type – but why would one do that? Because C/SIDE did that? It’s much more convenient that you create a structure based on functionality, so that all objects (reports, tables, pages, … ) that belong together, are actually together. Like this example:

  • \Src
    • \_FunctionLibrary
    • \NotificationMgt
    • \InterCompany
    • \Sales
  • \Test
    • \NotificationMgt
    • \InterCompany
    • \Sales

You see – you can even follow the same structure in your testability – although there is a lot to say about that (it might be better to do testability in a separate app – it gives you much more flexibility by decoupling/disabling your methods if necessary – but that’s a whole other topic).

And even prefixes

And then there is prefixes. Know that there is a requirement for apps on AppSource – they need to be prefixed! Not only objects, but also fields and controls that you add to existing tables/pages! Simply because of the fact that one field or control can’t be added twice ;-).

Also, you need to make sure your prefix is unique. And to do that, there is a mail address to apply for a prefix: d365val@microsoft.com.

I don’t want to care about this

It adds complexity to my project, and it needs to add discipline to the developers. Complexity and discipline, that’s a dangerous combination to rely on. So I don’t want to.

 

That’s why I started to build something that can manage this for me.

Rename/Reorganize

Maybe first some vocabulary:

  • Rename = Renaming a file following a pattern (which you can configure – the default is the one Microsoft describes).
  • Reorganize = Renaming a file, and put it in a subfolder (categorized by object type).

Renaming is very interesting. Reorganizing – to be honest – I don’t use that anymore, because as said before, I believe you should organize your objects per functionality, not per object type. This was just something we were used to from the Object Designer. But now we can do better ;-).

To start with, I added commands to the command palette:

One downside on a command is that you have to manually run this. So every single time you create, renumber, rename, .. an object, you need to think about running one of these as well …

I’m lazy and undisciplined, so this was not automatic enough. So I included a setting that this can be done automatically “OnSaveFile”. But later more about that – let’s first talk about the basic settings…

The Basic Settings

There are quite some settings – but do know you don’t *need* to set up anything – it will just work without settings, as the defaults are the ones that Microsoft describes. Let me try to categorize them a bit:

See Table…

Since a normal file, and extension file and a customization all have a different pattern, I needed to split it in three settings. You can change them at your convenience using the tags you see in the third column.

Some tips that go along these settings

Before you start renaming your files – commit your code to Git first, because that will be the only rollback you will be able to do ;-).

The last setting “AlSubFolderName” is only used to reorganize the file(s). If you don’t ever want to accidentally run that command, just set it up with “None” – that will deactivate the “reorganize” command, and prevent from accidentally disrupting your (manual) folder structure. This is what I do lately.

Automatically rename/reorganize filenames (when you save a file)

As I said, I don’t like to manually run any command, because that demands me being disciplined. I’d like to rely on the opposite, so I also introduced another setting “CRS.OnSaveAlFileAction”:

Default setting is “DoNothing”, but you can set it to “Rename” or “Reorganize” which will simply call the Rename/Reorganize Current File when you save a file.

Tips:

I usually set this on workspace-level, so that I always have a decent filename in my repository, whoever is working on my app.

If you apply your own folder structure, set this setting to “rename” – else your folder structure is going to get automatically messed up ;-).

Prefix/Suffix

It is a good practice to prefix as well, to avoid conflicting names in objects, fields, … a requirement which Microsoft describes here. And it’s best to apply for a prefix by mailing to d365val@microsoft.com – just to make sure your prefix is reserved and unique.

I built that into the “Rename” and “Reorganize” feature mentioned above. So when you try to rename/reorganize a file, it’s also going to check whether you set up a prefix/suffix, and it’s going to apply that to the :

  • Object Name
  • Actions (only prefix)
  • Fields (only prefix)

There are a few settings that make that possible:

  • CRS.ObjectNamePrefix
  • CRS.RemovePrefixFromFilename
  • CRS.ObjectNameSuffix
  • CRS.RemoveSuffixFromFilename

As you can see, there are some “Remove” settings as well. They are there to avoid to have the prefix in the filename (as the filename will get the object name by default). This will give you much nicer filenames without prefixes.

Tips:

By default, the system is not going to prefix/suffix anything. You will have to set these settings before anything will be prefixed

Because of the “OnSaveAlFileAction” setting, the prefixes will be applied automatically as well – no extra work needed.

Warning:

If you renumber/reorganize for the first time with a prefix – it’s not actually going to “rename symbols”, which means you will end up with compile errors. They are easy to solve, so don’t panic! – it’s just not possible (yet) to do a decent rename symbol with the VSCode API to prevent this.

That’s it!

That’s all, folks. This has cost quite some hours of my life – and not only my life, also from a few people from the community, that has contributed to the project on github, like Dmitry Katson and Johannes Wikman. I so love this community :-).

Things that need improvement

That doesn’t mean that things doesn’t need improvement. While writing this blog, i realized that I actually never implemented the suffix for fields and actions. Probably because I never needed it – because we always “prefix” our objects.

In any case – if there is anything you lack, might want to have changed – don’t hesitate to file an issue on my repository.

My Settings

Let me conclude with my settings – what I usually use (in terms of this blogpost, obviously). Well, here is an example:

I usually don’t use the “Reorganize”, as I want to organize my files manually in function areas (subfolders). So the “AlSubFolderName” is “None”, which prevents anything to reorganize (it basically disables that function).

I do want to rename everything automatically, therefore the “OnSaveAlFileAction” to “Rename”.

And then I set a prefix, since that’s mandatory by Microsoft. It’s best to have this prefix set all in the beginning. So make sure you apply for a prefix rather sooner than later!

Getting Started with AL

Original URL…

To get started writing extensions for Dynamics 365 Business Central you will need a Dynamics 365 Business Central tenant, Visual Studio Code, and the AL Language extension. Visual Studio Code is a cross platform editor that you will use for coding and debugging.

Steps to set up a sandbox environment and Visual Studio Code

Go through the following steps to set up a sandbox environment. With the preview you get sample code that compiles and runs with just a few commands.

  1. Sign up for a Dynamics 365 Business Central sandbox.
  2. Download Visual Studio Code.
  3. Download the AL Language extension.
  4. Press Ctrl+, to open the user settings window; here you can modify the telemetry settings.
  5. Press Alt+A, Alt+L to trigger the AL Go! command, and then choose Cloud.
  6. Enter the credentials you provided for the sign up, and then Download symbols.
  7. Press F5 to deploy and run the extension on your online sandbox tenant.

Note

Use Ctrl+Shift+P to clear the credentials cache if you want to deploy against a different environment.

You now have a HelloWorld sample that compiles and runs. The JSON files in the project are automatically updated with the settings that allows you to press F5 to build and deploy the solution.

Tip

For information about which sandboxes you can choose, see Choosing Your Dynamics 365 Business Central Development Sandbox Environment.

Note

Build and get inspired by our sample library on GitHub.

JSON file settings

There are two JSON files in the project; the app.json file and the launch.json file. The files are automatically generated for your project. For more information, see JSON files.

Telemetry settings

By default, Visual Studio Code is set up with a telemetry system to enable that data and errors are sent to Microsoft. If you do not want to send telemetry data, you can change the telemetry.enableTelemetry setting from true to false.

To modify the telemetry setting, press Ctrl+, in Visual Studio Code and choose the user settings window, which opens the settings.json file, and then add telemetry.enableTelemetry and set it to false.

"telemetry.enableTelemetry": false,

Tip

The settings.json file contains user and workspace settings, these options can be modified to suit your preference. If you want to modify Visual Studio Code editor options and functional behavior settings, see User and Workspace Settings.

The symbol file

The symbol file contains metadata of the application. This is what your extension is being built on, and therefore the symbol file must be present. If it is not present, you will be prompted to download it. For more information about the platform symbol file, see Symbols.

Installing and publishing an extension

To make your extension available to users, the package must be published to a specific Microsoft Dynamics 365 Business Central Server instance. The extension can be installed for one or more tenants. For more information about how to install and publish an extension, see How to: Publish and Install an Extension V2.

Accessing a control add-in in a dependency extension

Original URL…

Long time no see, eh? Time flies, what do you know…

I am thrilled to still find you here. Honestly, I wasn’t sure this morning if I was about to even find this blog where I left it seven months ago. Cool to find both my blog and you in good shape, patiently waiting for my contribution.

This morning I had a call with a partner asking if it was possible to deploy a control add-in in such a way that other partners could use its functionality from their own extensions. My answer was, and it still is – well, it should be possible, but I don’t know for a fact because I never tried it.

So let’s try it and find the answer together.

(It goes without saying, but I’ve learned that things that “go without saying” often don’t, so let me go with saying it: this is about Extensions V2, NAV 2018, and Business Central; no NAV 2017 stuff here. And no animals were harmed while during writing of this blog, yet…)

To keep my partner safe and anonymous, and stay GDPR compliant in and out, let’s imagine this imaginary scenario: you are building a cool horizontal feature that does “things” in the back end, but also exposes a little bit of front-end sugar for other NAV partners to consume. So you want to make your control add-in accessible to them.

If this was all about pure AL – it’s a no brainer. Your workflow is as follows:

  1. Create and build your extension
  2. Ship your .app file together with your app.json manifest file to your partners.

Your partners, who want to tap into your functionality from their extension, need to do this:

  1. Create their extension
  2. Make your .app file available in their package cache path
  3. Use the information from your app.json to declare a dependency on your extension from their app.json

If your extension uses publicly accessible stuff, such as a table or a codeunit, or events, your partners can now tap into this functionality from their extension (by reading your table, or calling your functions, or subscribing to your event publishers).

But what if you also make a control add-in a part of your extension? Let’s try it out together.

Creating the “horizontal” extension (the “dependency”)

Let’s get the first part done. The “your” part where you are creating your extension that includes a control add-in to expose to your partners. Your amazing new control add-in will expose a button, that will have a caption of your choosing, and will allow your partners to respond to its click event. Crazy stuff, right?

I’ve got myself a nice and fresh VM this morning from aka.ms/getnav to have access to latest CU (being CU6 from June 6). You may want to get one for yourself, too.

Once it’s up and running, start VS Code, and run the “AL: Go!” command from the command palette. Then choose the “BaseExtension” as its name, select “Your own server” as the server, enter your username (mine was “admin”), enter your password (mine was, whoops, I am not telling you what it was!).

When it’s done, which takes like a half a femtosecond, you have your launch.json file open. Go back to your landing page in IE, or access it from the desktop if you closed it) and copy the last four lines from it (under “launch.json settings” subsection) and paste it inside of your launch.json (make sure to overwrite those same settings in there, which is all settings after “name” and before “startupObjectId”). Also, set the “startupObjectId” to 50100 to run your first page.

If you did it correct, you’ll get something like this:

SNAGHTML2a47603d

A few more housekeeping steps:

  • Delete the HelloWorld.al file
  • Edit the app.json file to declare your extension. Mine changed the name, the publisher, and the idRange sections, and it now looks like this:
    image

Now, time for the real stuff. Create a new file and name it “ControlAddIn Base Control.al”

In it, request some real estate from the app, declare a startup script and a “normal” script, then declare a procedure to set a caption on the button, and two events (one to indicate the control is ready, and one to include the implementation for your declared methods). If you care, declare a stylesheet file to make it look nice, too.

If you are as good as I am, yours will also look more or less like this:

image

Rats! I am not that good – there’s red stuff in here. Let’s fix it.

Create two folders, call one “Scripts”, and another one “Styles”, and in them, create the files as declared in your control .al file. Mine are “startup.js”, “baseControl.js”, and “baseControl.css”.

This takes care of the “red stuff” in the control add-in object (it may require you to close and re-open the editor tab for the control add-in object, though).

Now put beef in these files as indicated in the screenshots below.

image

This one was tough! It calls the OnControlReady event when the control add-in starts. Now, let’s get the easier ones done, too.

image

This is your implementation. It contains one function to set caption, as declared in your control add-in object file. It’s not the smartest piece of JavaScript code ever written, but gets the job done. If there is no button, it creates one, sets its caption, and saves the reference for future use. The button, when clicked, invokes the OnClick event, duh!

And last, but certainly the least and entirely optional, add some CSS juice to get rid of Times New Roman:

image

(Times New Roman makes my toenails curl up)

Finally, let’s test if this works as expected. Create a “Page 50100 Test Control.al” file and populate it with bare minimum of al to try this out:

image

Ctrl+F5, sign in once to deploy your control add-in, then sign in once more to, well, sign in to your NAV, and then perform this complex set of steps:

image

So, we did it, or so it seems.

Now, you are good to deploy this to your partners.

Deploying it to your partners

To deploy it to your partners, just do this:

  1. Take your app file (mine is “Vjeko.com_Control Add-in Base_1.0.0.0.app”) and your “app.json” file
  2. Send them to your partners.
  3. Done.

Using your partner’s control add-in

Time to put your partner’s shoes on. You are now not you anymore; you are now your partner, the one who uses your extension. Yes, I confused myself, too, I tend to do this.

First thing, create your extension, the one that will (try to) consume your partner’s shiny button control add-in.

It’s easy, “AL: Go!” once again, follow the same first bunch of steps as you did earlier, up to deleting the HelloWorld.al file.

First step, sort out the app.json manifest file. This time (apart from using a different control add-in range, which should go without saying, but doesn’t, just in case) you need to declare a dependency on the Base Extension you (when you were your partner) created earlier. To do that, use the info from the “app.json” file you received from your partner. This is what I’ve got:

image

Now, to make it simpler, run the “AL: Download symbols” command, to get the symbols files stored in your package cache path. If you didn’t do anything fancy, it should be right inside your workspace, under .alpackages. Now, select any of the .app files inside your .alpackages folder, press Alt+Shift+R to reveal the .alpackages folder in Explorer, and then paste the .app file you received from your partner right in there together with the two files already in place. Now, if you are doing this from the same machine, that file will already be there, because VS Code was smart enough to download that file together with base NAV files automatically.

Good, now let’s try to see if we can use the control add-in your partner extension exposes.

Create a “Page 50110 Test Partner Control.al” file and add al code to define the page that, well, at this stage, attempts to use your partner’s control add-in. For all I care, it can be the exact copy of the original page 50100 from the previous workspace, save for the object ID and name, which should be 50110 “Test Partner Control”. If you didn’t care more than I did, this is what you have at this stage:

image

Last step, change the startupObjectId from 22 to 50110 inside your launch.json file, cross your fingers, close your eyes, and press Ctrl+F5. Okay, if you can’t do it with your eyes closed, open your eyes, position your left pinky on Ctrl, your left middle finger on F5, close your eyes, and click.

(you may open your eyes now…)

image

Yaay! It works!

Really, I didn’t expect anything less, but now I know for a fact. And so do you. You’re welcome!

Mark Brummel Blog – Business Central-as-a-Framework

Original URL…

Compared to other programming languages AL can be less intuitive to get started with and it behaves unexpectedly for modern developers. It requires a lot of effort for the Business Central team to maintain a language dedicated for only one application.

Solution is to move AL to TypeScript to reduce the learning curve for new developers and add modern programming capabilities….

Dynamics 365 Documentation

Original URL…

    • Get started with Dynamics 365
      • What’s new

        Stay on top of the latest features and releases

      • FastTrack your deployment

        Speed up your rollout with personalized tools, resources, and best practices

      • Training classes

        Find the right eLearning courses for your role

      • Accessibility center

        Resources for people with disabilities

      • GDPR center

        Learn how Dynamics 365 supports your GDPR compliance journey

Development in AL

Original URL…

The AL developer environment is evolving with frequent updates. To stay up to date on the latest information and announcements, follow us on the Dynamics NAV Team Blog.

Development in AL

Extensions are a programming model where functionality is defined as an addition to existing objects and defines how they are different or modify the behavior of the solution. This section explains how you can develop extensions using the development environment for Dynamics 365 Business Central.

If you are new to building extensions, we recommend that you read this document to get an understanding of the basics and terms you will encounter while working. Next, follow the Getting Started with AL to set up the tools.

Tip

If you are looking for the C/SIDE documentation, visit our Dynamics NAV library.

Understanding objects in the development environment

All functionality in Dynamics 365 Business Central is coded in objects. The extension model is object-based; you create new objects, and extend existing objects depending on what you want your extension to do. Table objects define the table schema that holds data, page objects represent the pages seen in the user interface and codeunits contain code for logical calculations and for the application behavior. These objects are stored as code, known as AL code, and are saved in files with the .al file extension. The AL Language extension also supports the multi-root functionality which allows you to work with multiple AL folders within one workspace. For more information on how to group a set of disparate project folders into one workspace, see Working with multiple AL project folders within one workspace.

Note

A single .al file may contain multiple objects.

There are two other special objects which are specifically used for building extensions. Table extension objects and page extension objects are used for defining additive or overriding changes to table or page objects. For example, an extension for managing a business that sells organic food may define a table extension object for the Item table that contains two additional fields, Organic and Produced Locally. The Organic and Produced Locally fields are not usually present in the Item table, but through the table extension these data fields will now be available to store data in and to access from code. You can then use the page extension object to display the fields that you added to the table object.

Note

Extension objects can have a name with a maximum length of 30 characters.

You have several options for creating new objects with the AL Language extension for Visual Studio Code. For more information about the objects that you can create for your extension, see AL Development Environment.

Developing extensions in Visual Studio Code

Using the AL Language extension for Visual Studio Code, you will get the benefits of a modern development environment along with seamless publishing and execution integration with your Dynamics 365 Business Central tenant. For more information on getting up and running, see Getting Started with AL.

Visual Studio Code and the AL Language extension lets you do the following tasks:

  • Create new files for your solution
  • Get assistance with creating the appropriate configuration and setting files
  • Use code snippets that provide templates for coding application objects
  • Get compiler validation while coding
  • Press F5 to publish your changes and see your code running

For more information, see Visual Studio Code Docs.

Tip

If you have previous experience working with the C/SIDE development environment and need an overview of some of the changes between the two development environments, see Differences in the Development Environments.

Designer

The Designer works in the client itself allowing design of pages using a drag-and-drop interface. The Designer allows building extensions in the client itself by rearranging fields, adding fields, and previewing the page design. For more information, see Using Designer.

Compiling and deploying

Extensions are compiled as .app package files. The .app package file can be deployed to the Dynamics 365 Business Central server. An .app package contains the various artifacts that deliver the new functionality to the Dynamics 365 Business Central deployment as well as a manifest that specifies the name, publisher, version, and other attributes of the extension. For information about the manifest, see JSON Files.

Submitting your app

When all development and testing is done, you can submit your extension package to AppSource. Before you submit the extension package, we encourage you to read the checklist to help facilitating the validation. For more information, see Checklist for Submitting Your App.

See Also

Getting Started with AL
Keyboard Shortcuts
AL Development Environment
FAQ for Developing in AL