From the very beginning the core technology that made Dynamics 365 Business Central (or Navision back then) tick has been C/AL. That’s the language that the whole solution is written in, from the core building blocks, like posting routines and tax calculations, all the way up to the custom code written specifically for your business. It’s all the same. However, that’s beginning to change.
To explain why this is changing, we first need to look at both the pros and the cons of C/AL.
As a development language, C/AL is actually pretty simple. It’s procedural, which means that in most cases a developer just has to write ‘If something is true, then do this, otherwise do that’. This simply means that someone with a background in software development can usually pick it up in a few days (check out our C/SIDE Development training course!)
In other languages, you often need a specialised set of tools (called the development environment) to write the code and deliver it to the solution. Again though, with C/AL this has never been a problem, as the development environment (called C/SIDE) is baked directly into the solution. So, you simply open it up and get to work. Once your code is written, it’s saved directly into the same database as the rest of your ERP data and the changes are applied immediately. So far, so good!
However, this power and flexibility comes with a cost. The ability to make changes quickly and easily to the solution means that people actually do. On the one hand this is great, it means that you can have an ERP solution tailor-made to your particular business needs. However, when it’s time to upgrade, all of these changes add complexity. It means that a developer needs to look at each piece of modified code and decide how they can be fit together with the new version of the solution.
This brings us back to the beginning: the core of the solution is C/AL, whether it is code written by Microsoft, your partner or your in-house developers, it’s all mixed up together. What Dynamics 365 Business Central needed was a way to separate those layers of code to allow customisations to be made without ever touching the core C/AL code. To solve this problem, Microsoft gave us AL.
“It was also designed to be easy for existing C/AL developers to pick up, using same concepts and structures as C/AL, in fact the code itself is almost exactly the same!”
A quick detour. Before AL came along, Microsoft produced a different solution to this problem in the form of Extensions 1.0 and was a way for developers to package up chunks of C/AL code into an ‘Extension’. However, instead of the Extension having all of the code, it only contained the changes that had been made. So, if the change was to add a field to the item card, the Extension would contain code saying ‘Add the Field X to the Item Card after the Field Y’. As a result, you could apply that same Extension to any system as long as it had ‘Field Y’. For simple changes this works really well, however as the changes became more complex more issues arose. Fundamentally the problem was that the changes were still being written in C/AL, which didn’t have the right structure to support this splitting out of the changes. This idea needed a language designed specifically for the task.
In 2018 Microsoft launched the AL language (or Extensions 2.0). AL was written from the ground up as a way of describing changes to C/AL. It was also designed to be easy for existing C/AL developers to pick up, using same concepts and structures as C/AL, in fact the code itself is almost exactly the same!
So, what can you actually do with AL? Happily, the answer is almost everything that you can do in C/AL. You can do simple things like adding fields and tables, to much more complex things like writing entire new modules that integrate seamlessly with the core system. As a general rule of thumb, if you want to add something new, you can do it easily with AL. However, where it becomes more complex is when you want to change something that the system already does. The problem is that if developers can just change anything they like in the core system, then you’re still going to hit the same problems come upgrade time. If the new version of the core system has also changed the way that part works, the only answer is to get a developer hands on again to work out how to combine the two different changes. To solve this problem Microsoft introduced something called ‘Events’. These are dedicated points in the core system that developers can ‘hook’ into to make their changes. That means that as long as the Event never changes, the custom code will continue to work, no matter what else changes in the new version. So, by hooking into these events, AL has the power to change the way standard parts of the system work, such as changing sales price calculations or redirecting inventory to different locations. Of course, the limitation of this method is that you can therefore only change processes that have an Event in the right place. Fortunately, each version since NAV 2016 has added more and more Events for developers to use.
“The move to AL has added a complexity that was never previously a consideration, which is source code. The source code is what you use if you ever need to fix a bug or make further changes to a modification.”
Much like C/AL had its development environment, C/SIDE, developers too needed a place to write their new AL code. For this, Microsoft turned to
its industry leading software called Visual Studio Code, or VSCode for short. This is the new development environment written by Microsoft, not just for AL, but for a whole host of other populate languages, such as Javascript, Python, PHP and many others. This means that for the first time, developers in the Dynamics 365 Business Central world can take advantage of all same tools as other developers.
Once a developer has written an Extension (or ‘App’) using AL, there are two ways that it can be delivered to your system. The first is for someone to manually upload the extension file into Business Central; this is usually done either using Powershell, or an Upload option inside Dynamics 365 Business Central. The second option is via a Microsoft service called AppSource. This is very much like the App Store for your iOS device, it’s a website where developers can publish their apps, you can then simply click on ‘Install’ and it will be automatically installed on your system. Unfortunately, this second option is currently only available if your Dynamics 365 Business Central system is hosted on the Microsoft Public Cloud.
The move to AL has added a complexity that was never previously a consideration, which is source code. The source code is what you use if you ever need to fix a bug or make further changes to a modification. The C/SIDE development environment, which is used to write C/AL, automatically saves the source code of any development directly inside the ERP database. As a result, neither you, nor the developer had to worry about where the source was. This changes with Extensions (both 1.0 and AL/2.0). The source code itself is now stored as, essentially, text files on the developer’s machine. When the Extension is installed into your system, the developer can choose whether or not the source code is delivered with it. When an Extension is installed from AppSource the developer doesn’t have this choice, the source code simply isn’t made available to you. Fortunately, this isn’t a new problem, it’s always been the case for almost every other development language in the world. As a result, there are industry standard tools and processes in place to handle source code and make sure that it’s kept safe and secure. VSCode has built in integration to a Source Control system called ‘Git’, which is a type of server that you upload source code to. This actually delivers huge benefits, by keeping track of every single change ever made to code, so that at any point you can see what was changed, when it was changed and by whom. You can then even roll back changes if they caused a bug. It’s very important therefore that if you have extensions installed in your system that you know where the source code is stored and that you can have access to it if needs be. Many partners are updating their contracts to provide these details, but it’s definitely worth checking!
“By separating custom code away from the core of the system, AL gives you the ability to customise your ERP solution to the exact needs of your business, without adding complexity to upgrades.”
So, this is the new world, the future of Dynamics 365 Business Central development. By separating custom code away from the core of the system, AL gives you the ability to customise your ERP solution to the exact needs of your business, without adding complexity to upgrades. So, you can keep up to date with all the advances being made by Microsoft without losing the flexibility that makes Dynamics 365 Business Central such a great solution.
Want to learn more about Dynamics 365 Business Central? Head over to our website!
Interesting in learning more about available Dynamics 365 Business Central Extensions? Check out our product offering here!