Yes! The short answer is yes and if you don’t care about details you can close the browser window or delete the email.
I’ll elaborate on the Yes, but there is also a “Yes, but not if…” that I will share... (Continue reading)

Two days after the news about the new product name for NAV (Navision) has leaked I am already getting used to it and actually starting to like it. I just hope the poor Marketing boy or girl who was responsible... (Continue reading)

Having a big mouth is easy. Everyone can go on social media and tell whats wrong in the world. But did you actually try to change it? Or are you just talking about it?
Dynamics NAV is full of legacy code... (Continue reading)

Ok, so today I had another issue in my NAV 2018 upgrade that made my blood pressure go up. I kept getting a weird error in the Sync-NAVTenant PowerShell command. I was afraid that this would be a showstopper... (Continue reading)

The ForNAV standard reports are in public preview. We have just released CTP2 and now we want to start testing them with Visual Studio Code. In order to do that we have to convert them to AL objects.
Microsoft... (Continue reading)

Managing Extensions in Microsoft Business Central

Two days after the news about the new product name for NAV (Navision) has leaked I am already getting used to it and actually starting to like it. I just hope the poor Marketing boy or girl who was responsible for the name is not paid per changed word.

So let’s get back to business. Many companies are upgrading to NAV 2018 or have already completed this task. The reason for this is simple, NAV 2018 is a mandatory step if you want to move forward with your investment and if you want to grow into Microsoft Dynamics 365 Business Central.

Microsoft is currently working very hard to move their NAV C/AL code to AL and move us to Visual Studio Code as a development platform. Extensions are a great concept and in my opinion the only way forward even though roumors have reached me that in On-Prem versions of Business Central you can still make raw source code modifications. I would strongly advise against doing that.

Challenges with Extensions

I’ve created quite a few extensions. In fact, I would be surprised if you can find anyone in our community that has created more than I did which are actually running live either on prem or via App Source.

If you are lucky you can start from a blank slate and this post does not apply to you but most of us, almost everyone has legacy IP to move forward. If this is the case you want to keep your extensions more or less in sync with your C/AL objects.

Object Numbers

This is where object numbering becomes a challenge. If you look at the Microsoft C/AL objects you can see patterns in the object numbers, but you can also see anomalies. For example: Relationship Management starts at object ID 5050, Employee Management at 5200 etc.

The General Journal Template is table 81 and the Journal Line is table 82. The General Journal Batch is number 232. Table 83 is the Item Journal Line.

Reason is simple. Legacy. Journal Batches were introduced a number of releases after the initial Journal design is created. Later journals like Warehouse have adjacent numbering.

Why is this important with Extensions? Well. I can guarantee you that very soon you will loose overview of which object ID’s have been used.

Encapsulation & Modularity

Another challenge that you will have to solve is breaking up your existing code into smaller modules. You will want to build up your extensions in layers with dependencies.

This is rediculouly complex as we have never faced this challenge before. Let me give you an example.

You may think that the lowest level of modularity is in Setup tables and Master Data. This might be true, but what about the flowfields in your Master Data that point to Entry tables? Are you moving them away to Table Extensions higher up in your layers? Are your setup tables separated per module? Or did some developer who left your company years ago made a mistake by putting values in wrong tables?

Running Objects

Another challenge is to be able to quickly run a page or a codeunit. This is easy today but not so easy from VS Code. Microsoft is shoving the Web Client down our throat but in reality this client is far from ready for prime time use. 99.9% of all users work with the Windows Client.

Versioning

It took me some time to figure out how to do versioning with my Extensions. Yes, we have native GIT integration but that does not solve the problem of understanding which version of code is running in which database in your DTAP environment. You will want to version your extensions each time you want to move something forward but most versions will never make production.

The Solution

I am very fortunate to call Michael Nielsen my colleague and friend. As most of you know he invented the C/AL programming language and came up with the idea of C/Side and the Object Designer.

Object Designer is basically an Excel Sheet that is helping you manage your solution. It works so well that I’ve seen partners manage over 10.000 objects. Try that in Visual Studio Code.

Michael decided to create an Object Designer for Extensions and I have the luxury of testing and helping to make some improvements.

You can try it out yourself and download it from the ForNAV website. It’s 100% free and customizable. You may find some neat tricks in there.

We decided to use Page ID 1000 which is free in NAV 2018 but also available to execute in End User licenses. This allows everyone to start using this today.

As soon as Microsoft supports DotNet Interop in Extensions we will ship a version as an Extension so you can manage it in a proper way.

View the AL Source Code

Microsoft decided with Extensions to allow partners to hide their source code from being debugged. This is extemely anoying as you constantly have to contact your partner to do troubleshooting.

Michael found a way to go around this and reveal the code and re-create the extension as a debug version. You still need a partner license to publish this to the server though.