A fundamental part of the Navision/Dynamics NAV/Dynamics 365 Business Central (whatever you want to call it!) proposition is that you can tailor the system to fit the needs of your business.
As the product has matured, it’s become easier to personalise your experience without writing code, but to really make big changes to the way it works you need a developer.
Up until a few years ago this development work was done in a language called C/AL, but in 2018 Microsoft gave us a whole new way of working when it released a new language for NAV/BC called AL. This has resulted in a huge shift in the way development is done for NAV/BC, and the impact it has on your system going forwards.
Before looking at what the differences between C/AL and AL are, it’s important to understand why Microsoft felt it was time for a change. The flexibility that C/AL development made possible was creating some challenges in terms of upgradeability.
If you write code that changes the way the system works, when it comes time to upgrade you need to see if your code will work in the new version. This takes time and effort, which is why many customers continue to use older versions of NAV.
This is the problem that AL solves.
The key to the solution that AL provides is the idea of ‘apps’. Previously, in C/AL, all code changes were done in the core of the system – it was one monolithic code base. However, in AL all code is contained in chunks called apps.
So, the standard Business Central code from Microsoft is an app (actually, it’s multiple apps, but we won’t worry about that), and then any code you write is published to the system in one or more apps.
This way, if you want to upgrade the core Business Central app you can do without affecting the other custom code you’ve written. It’s all neatly compartmentalised.
In AL Microsoft have found a way to enhance a core strength of the NAV product, reduce the cost of future upgrades and enable deployment choice.
There are two main ways that these apps can interact with each other. The first way is through a mechanism called Events. These are places in the code where the system sends out a signal, any app that is listening to that signal can tell the system to run whatever code it likes.
For example, an event might be triggered when you enter the Item No. on a Sales Order Line, an app could then subscribe to that event so that as soon as you enter a value it can run some code to check for promotional prices for that Item. This means you don’t need to add code to the Sales Line table (as you would previously), instead your code is neatly segmented away in its own app.
Since 2016, Microsoft have been gradually adding more and more of these events to the core system, so by now there is an event for pretty much everything you might want to do.
The second way these apps can interact is via a new set of objects introduced in AL called Extension objects. Let’s say you want to add a field to the Customer table and card so that you can identify them as a VIP customer.
In C/AL you add the field directly to the Customer table, and the Customer Card, however in AL you can write an app with two new objects. The first object type is called a TableExtension, here you would simply add a few lines of code to describe the field you want to add. The second object type is called a PageExtension, and again, here you are just describing the change you want to make to the Customer Card page, in this example adding our new field.
Whenever the app is installed it will automatically make the changes to the table and page that these objects describe.
The result of developing this way is that your new custom app has very little dependency on the app you’re extending. It doesn’t matter if the whole Customer Card is redesigned in a new version, as long as there is still a field called ‘Name’, our ‘VIP’ field will go directly after it.
Similarly, as long as the event that our Promotion Engine subscribes to still exists, the code will continue to work. Of course, there are occasions when Microsoft has to make breaking changes to the core application, but as Business Central has become more mature these are becoming few and far between, meaning that upgrades become relatively pain free.
In AL, Microsoft have found a way to enhance a core strength of the NAV product, reduce the cost of future upgrades and enable deployment choice. Business Central is the only ERP application that is capable of running on-prem, in a Managed Service, and the public cloud.
Microsoft have taken a very measured approach to introducing AL, careful to give customers time to upgrade and migrate their code to AL from C/AL.
Business Central 14 was released in April 2019 and is the last version of Business Central that supports both C/AL and AL code. As such BC14 represents a useful stepping stone for customers who have C/AL code to migrate. This version will be available to existing customers until October 2021. From BC15 and beyond all modifications need to be built in AL code.