Wednesday, June 3, 2020
Since Business Central 2019 release wave 2 (version 15), the application has become completely AL-based. All functionality that modifies standard business logic must be moved into an Extension. This change influences how upgrades are performed and impacts all the solutions that are still in C/AL, making Dynamics partners consider transitioning to Extensions in AL.
In this blog post, we’ll walk you through some of the steps you can take to organize the code in the existing C/AL coding language before the transition. Following these practical advices will facilitate the transition from C/AL to AL, making it as seamless as possible. You can also listen to the webinar on this topic here.
Table of contents:
- Why does it make sense to refactor the code in C/AL before transitioning to AL?
- Best practices for standard, custom and modified objects when refactoring code in C/AL
- Solving Modified Base App incompatibilities and handling modifications in Codeunits
- Standard Events and Custom Events
Why does it make sense to refactor the code in C/AL before transitioning to AL?
There are several reasons why it is better to refactor the code in C/AL as a preparation instead of converting everything as is to AL and continuing from there. First, you should do that because you are familiar with the development environment, with C/AL coding language, and with all the limitations in C/AL. Because of that, there is no learning curve when doing any changes.
Also, it is a lot safer to do the code refactoring in C/AL before moving to the newer version of Business Central. If you don't have automated tests in place (which is the case for many solutions), you can only trust your gut feeling that the changes you make won’t break anything. But when refactoring code already in C/AL, every change you make and test will be tested again in your existing live system. This way, you will know that you’re not influenced by the new language behavior and you're not impacted by the new Business Central functionality in any way. You can be sure that changes you have made in C/AL while preparing to move to AL work exactly as expected.
If, by any chance, you decide to move straight from C/AL to AL, there will be quite a big overhead of tasks to do. There can be many things that don’t work, and you’ll have to figure it all out. It can be an old bug that you have not encountered before, a conversion issue, a merge issue, or the way the new Business Central release excuses the business logic. On top of all that, you would get many warnings after converting C/AL to AL, which doesn't help when developing.
Best practices for standard, custom and modified objects when refactoring the code in C/AL
Before transitioning to AL, your C/AL solution usually contains the standard objects, the custom objects, and the modified objects. Let’s review what preparation tasks you can do with these three groups of objects.
Handling standard objects in C/AL
You can leave standard objects as is because there is no need to do anything specifically with them. If you have time and resources, we suggest looking into obsolete functionality to ensure that your solution does not rely on any functionality that does not exist in the next Business Central version. In addition, you can also check the obsolete pending functionality – the functionality that will become obsolete in the near future. For example, the sales and price management functionality is marked as obsolete pending in Business Central version 16. This means that in the next Business Central version, you won't be able to utilize that functionality anymore; therefore, you should keep it in mind when you are refactoring your code. Review your code that is using obsolete or obsolete pending functionality.
It is useful to have a look at the new functionality that has been introduced up to the current Business Central release. For example, if you are currently on the NAV 2013 R2 version and you have a custom functionality that handles Item attributes, you can check and see that this functionality became a part of the standard NAV 2017. Therefore, it makes sense to get rid of custom functionality when refactoring the code in C/AL and take advantage of the standard one after the upgrade.
There are two ways to find obsolete and obsolete pending functionality in Business Central:
- For the System App, you can use GitHub. On GitHub, you can find a very well documented list of changes made by Microsoft that are no longer supported in Business Central newest releases.
- For the Base App, or the actual functionality, you should investigate the code. The functionality that is obsolete or obsolete pending is marked with the tag “obsolete” and kept in the code by Microsoft. You can search for these tags in Business Central code to see what Microsoft has already discontinued or is going to discontinue in the nearest future.
Handling custom objects in C/AL
You don’t necessarily need to do anything with custom objects in C/AL and you can leave them as they are. However, if you want to make your life easier after you convert everything to AL, you can add an affix to the objects. When converting your solution to AL, and especially if you're planning to go to Business Central SaaS, you must have either prefix or suffix for every single object you’ve created. Keep in mind that the 30-symbol limitation applies when renaming your objects to include prefix or suffix, and you cannot exceed that.
Another useful thing you can do in C/AL is to centralize .NET/JSON/XML Document/Web service/File usage that you will have to refactor in AL afterwards. There are native types in AL for JSON, XML and Web Services. Therefore, you should centralize them in one place so that there will be less modification of objects when converting to native types.
In addition, before transitioning to C/AL, you can think in advance about what to do with the .NET components. .NET is not allowed on SaaS, that’s why any Custom Libraries should be refactored, most likely using Azure functions. Also, if you have any Control Add-ins, you should refactor them using JavaScript.
You can also think about what to do with the File usage. Further actions depend on how you're using it. If you’re planning to go to SaaS and you have batch invoicing that you run every single night and store PDFs somewhere on your network share, you can already refactor it in C/AL and store it on the external drive (let’s say on OneDrive).
In addition, you can clean up the code in C/AL. While doing a development, if you see unused variable or unused function – make sure to delete them. Otherwise, if you transfer them into the AL, you will receive warnings saying that this variable isn't used.
Handling modified objects in C/AL
The biggest challenge when transitioning from C/AL to AL is handling the modified objects because you cannot make any Breaking Changes in Business Central, especially if you're going to SaaS. If you have deleted or modified the Key, it has to be reverted. Sometimes, if you create a Key just for Calcsums or just for sorting order, it is not necessary for Business Central anymore because the system will select the most suitable Key. So, you can easily revert those changes. However, it is not always the case and it is crucial to check for Breaking Changes before transitioning to AL.
Also, check for the changes that are incompatible with Business Central. Mostly, it is setting a standard NAV or Business Central field to be not editable. You have to think in advance about how to re-implement that, because you cannot modify the property in Business Central SaaS. You either leave Base App modification or you can create a copy of that field and use it in your functionality.
It is also very important to reduce your code footprint. You can do that by moving to Events, although sometimes it might not be possible. Moving to Event gives you a clear indication of what Global Variables you are using from the Standard Object and what Local Functions you are using. If it is not possible to move to Event, make sure to move your code to the start or the end of the Trigger if possible. If there is a lot of code, create a Function, move all your code to a Function and make a Call at the end or the start of the Trigger. This way, you will see more clearly that there is some code modification, which should be refactored.
When refactoring, make sure to remove any legacy code. Frequently, solutions that have been created a long time ago and evolved over multiple NAV/Business Central versions have functionality that is no longer used. If this is the case, do not move this code to AL. Instead, in C/AL, you should mark it as unknown. After you remove it, push it to the production and double-check if it is used.
As previously mentioned, an affix is required; therefore, add an affix for any Fields or Controls you have added, including Separators on the Pages. Also, centralize .NET/JSON/XML Document/Web service/File usage, which you will need to refactor later in AL.
Solving Modified Base App incompatibilities and handling modifications in Codeunits
When transitioning from C/AL to AL, you might not know what to do with Posting Codeunits and the Reports. You have the following options to handle those changes in applications:
- Use Events, not just the Standard Events, but also create Custom Events where Standard Events do not exist.
- Do refactoring and check if after the refactoring you are able to use the Standard Events. Part of the refactoring would be reverting to standard. If, for example, you have commented out the standard code, you won’t be able to move this to an Event. If you have Conditional Statements that you are using to execute the standard business logic according to your custom functionality, you must revert this to standard.
- Remove unused code. This is mandatory if you have a lot of code. Also, keep in mind that if you don’t remove unused code, you will waste a lot of time trying to figure out if this code can be moved to an Event.
- Clone object. This option is mostly used with the Reports. If you have modified any Standard Report, move it to your custom range and treat it as your object. Later, in AL, you can use substitute Report Event to print your Report. This does not apply to the Posting Codeunits because cloning Posting Codeunits would only result in additional maintenance tasks. But for the Reports, XML Ports, and Queries that's quite an easy solution.
Standard Events and Custom Events
Use Standard Events if they suit your needs. You can also backport the Standard Event. This means having a look at the future versions of Business Central, including the upcoming version which hasn’t yet been released. You can take that Event if it's compatible with the older version and move it to your application. What does that give you? At your application level this would be a Base App modification but once you have upgraded to the latest Business Central version, you would have no problems because your Event Subscriber will listen to the Event.
If Standard Event doesn’t exist, instead of writing the whole code in the, let's say, Posting Codeunit, you can create a Custom Event. After that, request Microsoft on GitHub to create a Standard Event. If your solution is large, it will take you some time to do an actual upgrade and by the time you have finished the upgrade, there will be a big chance that Microsoft will place the needed Event into the standard Business Central so you can move your customization into the Extension.
When moving to Events, you can get a list of the closest available Event Publishers by using C/AL to Extension Analyzer Report. To explore all benefits of the report, try it for free now. This is a limited time offer for all Dynamics partners who haven’t tried it yet, which will expire in just 2 weeks. So don’t delay, because when it’s gone, it’s gone!