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 this Enterprise Resource Planning (ERP) system 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 Dynamics 365 Business Central called AL. This has resulted in a huge shift in the way development is done for Business Central, and the impact it has on your system going forward.
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 the time comes 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.
Extensions
The key to the solution that AL provides is the idea of ‘extensions’. 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 extensions. The standard Business Central code from Microsoft is an extension (actually, it is multiple extensions, but we won’t worry about that), and then any code you write is published to the system in one or more extensions. This way, if you want to upgrade the core Business Central extension, you can do without affecting the other custom code you’ve written. It’s all neatly compartmentalised.
Events
There are two main ways that these extensions 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 extension 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 extension could then subscribe to that event so that, as soon as you enter a value, it can run some code to check for sales restrictions 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 extension. 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.
Extension Objects
The second way these extensions 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 extension 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 extension 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 extension has little dependency on the standard code 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 must 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.
“If you write code that changes the way the system works, when the time comes 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”.
AL didn’t just bring us events and extensions though, it also brought with it more programming concepts from other languages. For example, things like Lists and Dictionaries have been added to the language which are really useful tools for developers to use instead of the workarounds that were required in C/AL.
Interfaces
A big new feature of the AL language is something called ‘Interfaces’. This feature is all about the ability to abstract custom code from the underlying core functionality. A great example of this is the new Sales/Purchase Price functionality that Microsoft added fairly recently to Business Central. The Interface functionality means that Business Central can now simply say “what is the price for this sales line” without any idea of how that price would be calculated. Developers can then write their own price calculation functionality and simply bolt it into the standard system. A bit like contracts, all they need to do is make sure that when the system asks “what is the price for this sales line”, they give back the right pieces of data, everything else then just continues as normal.
Email Integration
Another example of this functionality is the new Email Integration in Business Central. Again, the system doesn’t care how the developer sends an email, it simply says ‘send this email’, then depending on what extension you have installed that work with this ‘Interface’ you could send email via Outlook, Exchange, Gmail or anything else without the underlying code being touched.
Native JSON Support
Another example of features that Microsoft have added to AL to bring it in line with more modern development languages is native JSON support. JSON is a text format for describing data (a bit like XML) that is used in modern web development, and AL now has the ability to read and write in this format without any requirement for third-party products or libraries.
The development environment you can use to write in a language can make a huge difference to how quickly someone can write and maintain great code.
The C/AL Development Environment
For C/AL, the development environment was called C/SIDE and was built into the Classic NAV client. It was purpose built for writing C/AL and C/AL alone. For AL, Microsoft made the choice to move to industry standard tools, instead of having something custom built for Business Central.
VSCode
The first tool to talk about is VSCode. This is the code-editor that is used to write not just AL, but lots of other languages (Javascript, Go, Python etc), and as a result is constantly being maintained and improved.
One of VSCode’s biggest features is its ability to support extensions (not Business Central extensions, these are different). These extensions provide a huge array of features to the code-editor, from fundamental things like the ability to work with AL itself, to smaller utilities like extensions to help name variables, or show who last changed a line of code.
VSCode Extensions from TNP
At TNP, our Head of Development Andrzej Zwierzchowski has written his own extension to VSCode that adds a wide range of features that make writing AL a snip. It adds things like the ability to see what objects are inside an AL extension, functions to generate brand new Card and List Pages with a single click, and a really useful tree view showing all functions inside a codeunit (along with loads more!). It’s been downloaded over 140,000 times by AL developers as of today!
Code Analysers
The last feature of VSCode that I want to talk about is Code Analysers. Whilst C/SIDE could tell you if you’d got an error in your code that would stop it from working, it couldn’t tell you if your code was good. This is where VSCode’s Code Analysers come into play. They are tools that are constantly monitoring every line of code that you write and comparing them to a set of development standards. If you write some code that doesn’t comply to those standards, then VSCode will warn you and even suggest corrections.
Development standards can cover a variety of topics, from simple things like variable naming to warning you if you’re writing code that uses something that is going to become obsolete in the future. Of course, Microsoft provide a set of these Code Analyser rulesets which ensure that developers are working to industry standards, and we can even add our own rules to make sure TNP developers continue to lead the way.
“At TNP, our Head of Development
Andrzej Zwierzchowski has written his own extension to VSCode that adds a wide range of features that make writing AL a snip”.
Source Control
Once you’ve written your code in your code-editor (C/SIDE or VSCode) you then need to store it somewhere. This is another area where there is a huge change between C/AL and AL. In the C/AL days, code was stored directly inside the NAV/BC database itself. If you wanted to see what the code looked like at a certain point in time you needed to get hold of a backup of the database and take a look. However, in the new world of AL, all code is simply stored inside individual files. This may seem like a backwards step, however it has actually opened the door to a great set of tools called ‘Source Control’.
The most popular Source Control tools are GitHub or BitBucket. Both of these are built on top of an industry standard called Git. There are vast amounts of books and online material explaining how Git works, so we won’t go into detail here. But, to simplify it, Git enables you to store copies of these source code files along with every single line of code that was changed and when. This is a massive improvement for Business Central developers everywhere. They are now able to see who changed what, when and why. All this information is stored on a source control server (GitHub/Bitbucket) so that if multiple developers are working on the same project, they can all see what each other is doing and automatically handle issues like conflicts where two developers try to change the same thing at the same time.
DevOps
By adding support for Git to the AL language, Microsoft has also opened up another door for improving the speed, quality and efficiency of development – DevOps.
DevOps is a way of automating the things you need to do when developing code for any language. In particular, testing your code to make sure it works and deploying your extension to the various test and production systems.
AL:Go
Microsoft have written a set of DevOps tools called AL:Go which work with GitHub. With AL:Go, whenever a developer finishes a piece of development, processes can automatically be triggered to run tests on that code (Microsoft provide some standard tests, but developers can write their own custom tests for that specific functionality). Once the tests have been passed, the code is automatically compiled into a new version of the extension, which is then deployed to whichever environments you like. This automation of testing and deployment means that common issues can be spotted well before any rogue code gets close to a production system. It’s also really useful when it comes to Business Central upgrades.
Whenever Microsoft release a new version of Business Central, AL:Go can be used to test all extensions that you’ve written against the upcoming release to make sure nothing is going to break. If there are errors found, then the developers get all the details they need to identify and fix the issues.
If you are considering upgrading from Dynamics NAV to Dynamics Business Central or require support for your current system, feel free to contact us. We look forward to hearing from you.
.png)