Standard Web APIs are going out of BETA with the spring release

Some great news on the API front.

With the release of the upcoming Spring 2019 release of Business Central the APIs are finally leaving BETA and going into v1.0.

Why is that a great thing?

Well now we can count on them being there and they will not change. Creating strong and deep integrations, into Business Central with little or no knowledge of the code, is within everybody’s reach. Using some of the many tools (Flow and Power Apps to mention 2) available is now something anyone can do.

The sky is the limit.

The release comes with 48 entities out of the box, but if you are missing an API you can also create your own.

Happy coding everyone

Field and Row size changes coming to the Spring 2019 Release

Another change coming to the April 2019 release of Business Central is changes to the field sizes allowed in the code and database.

Fields and variables of type Text and code can now be up to 2048 characters. The same for Text constants.

The earlier restrictions were 250 characters for table fields of type code and text and 1024 for variables of type Code and Text.

Yes I know you could have a Text variable with no length specified that would be unlimited, but this is only a variable and managed differently.

You can find all public information about this here: https://docs.microsoft.com/en-us/business-applications-release-notes/April19/dynamics365-business-central/max-length-of-variable-length-table-fields-has-been-expanded

This comes with another change to the tables where the 8KB row size is getting relaxed. Microsoft has not said a lot about this change and the only public available documentation on this can be found here: https://docs.microsoft.com/en-us/business-applications-release-notes/April19/dynamics365-business-central/relax-requirement-of-8k-row-size

With great power comes a great responsibility:

Just because you can doesn’t mean you should.

We have seen it all too often that restrictions are relaxed and people jump on the wave starting to do all kind of strange things. Use your new found power with great wisdom my friends.

Happy Coding everyone.

Multiple Unique Keys on AL Tables in Business Central

My first thought was FINALLY.

Having multiple unique keys is very common in just about all databases and finally it is coming to Microsoft Dynamics 365 Business Central.

Basically there is a new property that can be set on each key called “unique” which indicates that this key is a unique key.

When you have a unique key there cannot be any records in the database with the same key and it is validated and verified at the time a record is inserted that this is the case. If there is a duplicate key the insert will fail.

Why am I so excited about this? Well one of the things I have wanted for many years is a surrogate key. A key consisting of a single field that is unique and not based on any of the user controlled data in the table. Basically a single unique key on every record in a table. I have wanted that on all tables in Business Central, because it would create a single anchor to connect everything and anything to.

Having multiple unique keys is the start for creating this, so hoping this is just the beginning.

All the information in this blog is public and can be found here: https://docs.microsoft.com/en-us/business-applications-release-notes/April19/dynamics365-business-central/multiple-unique-indexes

This is coming in the April 2019 release as per https://docs.microsoft.com/en-us/business-applications-release-notes/April19/dynamics365-business-central/planned-features

Happy Coding to everyone.

Naming your Objects when coding AL for Business Central

Some tips and tricks in naming your objects well while developing code for Business Central.

First you need a pre/post fix from Microsoft. Well you only need this if you are developing things that go into AppSource, however just get it, so we don’t have conflicting objects out there.

So why is this important. Well if 2 objects have the same name one of the 2 extensions cannot install and we will have an issue.

So lets look at how you should name your objects.

First you get your pre/post fix from Microsoft. In my case this could be IB. You would than think I can create an object named IBSetup or SetupIB and I would never have a conflict. Well they assumption is that you likely would develop more extensions at your company, so this is not quite enough. Let’s say I am developing a Label extension. Well in that case I could reserve IBLBL as my prefix IB required my Microsoft and LBL I can track internally as my Label extension. If I now have a Setup object I can call it IBLBLSetup and I know it is unique.

Well that is a little hard to read in my book so I prefer IBLBL_Setup. Why underscore is a good idea is because I don’t need quotes around the name as you would if you selected to use a dot. “IBLBL.Setup” If you use underscore you can also quickly double click the variable to mark it up if needed something that doesn’t work if you use a dot. I use that all the time when I need to copy a variable.

Last but not least prefix or post fix. Why not call it Setup_LBLIB. (Beaware the IB must be first or last.) Personally I prefer post fixes but it is just something you need to agree on company wide as mixing these up just creates total confusion.

We use prefixes because that was decided at some point and we are not about to change it.

Field names should be treated the same however you only need to follow the standard for fieldnames that are extending existing objects. If the object is all yours pre or post fixes are not needed.

Hopefully this helps some of  you in naming your objects in good ways when you start extension development.

 

Developer Preview – February 2019 – Full AL – Love it.

Some great news. The new Developer Preview is fresh out and this time there is BIG news.

The biggest announcement this month is that we are publishing a preview of the base application fully on AL language.

Yes it is finally here. I know I will be setting this up tomorrow and testing all builds and test scripts are running like a charm so we can move our development over to this version right away.

Amazing work Microsoft and looking forward to get this one rolled out to our teams.

If you want to read more take a look here:

https://community.dynamics.com/business/b/businesscentraldevitpro/archive/2019/02/27/developer-preview-february-2019

What else is new:

Rapid Application Development RAD. A way to quickly publish and test during development.

New schema update mode – ForceSync

Debug without publiching

Debugger info for http, json with more

Code Actions – this looks pretty amazing and something I need to test right away. If what I read is accurate this will help a lot in our code converting projects.

TableRelation Extensibility… Oh yes something we have needed often

Views and Defining views in AL. Looking at this for the first time it does seem not to be the kind of views I was hoping for, but still an interesting concept.

There is a number of other minor things, but all in all we are moving quickly and fast towards the future.

See you back to the future we go.

Adding the Test App to the Artifacts

In my previous post (https://klemmensen.ca/2018/11/27/build-numbering-with-yaml/) I expanded the scripts Freddy has created with the ability to number the builds and the compiled app (artifacts) automatically.

Another little thing I noticed was that Freddy’s script doesn’t store the Test App in the Artifacts, however as many of us need to upload the finished product to AppSource we need the Test App too.

This can be accomplished by a simple little change to the “CI.yml” file.

Add this

– task: PublishBuildArtifacts@1
  displayName: ‘Publish Artifact: TestApp’
  inputs:
    PathtoPublish: ‘$(Build.ArtifactStagingDirectory)\test’
    ArtifactName: TestApp

right after the “Publish Artifact: App” task which currently is the second last task in Freddy’s version of the “CI.yml” file.

The test app will now show up under the Artifacts when you click the drop down arrow.

ArtifactsDropDownWithTestApp

As always I hope this helps you getting started with Azure DevOps and Source Code Management.

Enjoy,

Soren

Build Numbering with Yaml

Many of you might have read some great blog posts from Freddy Kristensen on his blog. If not I can highly recommend reading through this blog series on how to get Azure DevOps setup to work with your Extension/App development for Microsoft Dynamics 365 Business Central.

Here is a list of the blogs released at this time:

Part 1Part 2Part 3Part 4Part 5

One of the things I was missing my self in this serie was to be able to change the way the build numbers are generated. Freddy used the default numbering which is YYYYMMDD.R where YYYY is the Year, MM the Month, DD the Day and R the revision number for any given date. This is the stamp the build is getting inside Microsoft Azure DevOps.

You can change this very simple with adding the following to the IC.yml file at the very top.

name: $(Build.BuildID)

Here I set the naming to the internal build ID generated by Azure DevOps, but you can of course also set it to something of your own choosing. The link blow gives you a huge selection of options for setting the build number differently.

https://docs.microsoft.com/en-us/azure/devops/pipelines/build/options

This only resolves half the problem. If you are like me you would want to update the version number in the app.json file too.

I did that by adding a new script called “SetVersionNo.ps1” in the scripts folder.

$AppJsonFile = “.\app\app.json”
$AppJsonObject = Get-Content -Raw -Path $AppJsonFile | ConvertFrom-Json
$AppJsonObject.Version = $AppJsonObject.Version -replace “.{3}$”
$AppJsonObject.Version = $AppJsonObject.Version+$env:Build_BuildID + ‘.0’
$AppJsonObject | ConvertTo-Json | set-content $AppJsonFile

$TestAppJsonFile = “.\test\app.json”
$TestAppJsonObject = Get-Content -Raw -Path $TestAppJsonFile | ConvertFrom-Json
$TestAppJsonObject.Version = $TestAppJsonObject.Version -replace “.{3}$”
$TestAppJsonObject.Version = $TestAppJsonObject.Version+$env:Build_BuildID + ‘.0’
$TestAppJsonObject | ConvertTo-Json | set-content $TestAppJsonFile

This script updates the current version number I use “13.0.0.0” by removing the last 3 digits and replacing them by the BuildID and “.0”

In other words if the BuildID is 1234 than the version number is set to “13.0.1234.0.

Again you can do your own thing here by using the link from above and build the version number in a different way.

The only missing is to add a task to the CI.yml file to execute the PowerShell Script as the first task. This is done by adding the following right after the “steps:” in the CI.yml file.

– task: PowerShell@2
  displayName: ‘Set Version No.’
  inputs:
    targetType: filePath
    filePath: ‘scripts\SetVersionNo.ps1’
    failOnStderr: true

This will run the PowerShell Script from earlier and automatically set the correct version number before building the Extension. One less thing for the developer to do manually.

We can agree or disagree if that is the right way of numbering an extension, however it works for me and I hope it inspire all of you to do your own thing.

Enjoy.