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.
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?
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.
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.
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.
Enjoy this little tool as I am sure you will find it useful.
This is great stuff! You two rock!
LikeLiked by 1 person
Hi, Thank you for this post
I have a simple question, I created a new table using AL under VS Code, when I want to use The rapid start (Config. Worksheet), I can find the table in the list, but after selecting I am geting this error :
“The field Table ID of table Config. Line contains a value (50016) that cannot be found in the related table (Object).”
That means my table was not created in the Object table. please did you manage to find a solution to this problem, or using AL means forget about the Rapid Start!
Exactly in the validation of the in the “Table ID” in the Table ID – OnLookup() Trigger. (Table: 8622 – Config. Line)
Using the debugger, it’s stopping in the: Table ID – OnLookup() Trigger (Table 8622 “Config. Line”),
Iin fact, I understand the issue, the issue is when you create an object in Nav using C-Side, you will create a line in the system table “Object”, but using AL in Vs Code, the created objects, you’ll not find them in the Object Table, and we can’t create a function to create them in this table because we’re not supposed to modify or to add in it.