Wednesday, June 3, 2020
This is the second part of the blog post “Organizing Code for a Seamless Transition from C/AL to Extensions in AL.” If you haven’t read Part 1 yet, check it out now! You can also listen to the webinar on this topic here.
Table of contents:
- How to prepare for the requirements to have Extension on Business Central SaaS
- The Txt2AL conversion tool
- Merging objects to Microsoft Dynamics 365 Business Central
- The advantages of splitting solution code when getting ready for Business Central SaaS
- Tips for getting started
- Scope your transition to Extensions with C/AL to Extension Analyzer
How to prepare for the requirements to have Extension on Business Central SaaS
Below are a few tips on how you can organize the code in C/AL when getting ready to have an Extension on Business Central SaaS:
- Make sure that all solution Controls, Objects, and Fields have English (United States) caption. Managing translations in Business Central can be difficult because translations are decoupled from the code. If you have translations in place, you will have no problems in supporting your App in Business Central in AL for multiple localizations.
- Keep in mind that Application Areas for the Web Client are mandatory for Business Central in AL (while in C/AL those were optional). If you do not specify an Application Area on a Control, it won't be visible in the Web Client. Even worse, it won't be executed.
- ToolTips weren’t necessary in C/AL but in AL Microsoft is checking for Controls to have them. You should start populating the ToolTips in C/AL.
- Start creating Wizards. If you have setups that are 4/6 fields in your solution, you can create Wizard and use them instead of a regular setup for your application. Wizards can be created in C/AL and later converted to AL.
Txt2AL conversion tool
When you have done all the preparation tasks in C/AL, you can convert your solution to AL using the Microsoft Txt2AL conversion tool. The tool is being shipped with Dynamics 365 Business Central 2019 wave 1 release (version 14). It is the only tool that takes the existing Dynamics NAV objects that have been exported in .txt format and converts them into the new .al format. Txt2AL can be used with Deltas (which would generate you the actual Table and Page Extensions) or the whole Objects.
However, converting objects to AL can become problematic with the Txt2AL tool, as you might have to run it multiple times. This would happen if, for example, you have modified the Codeunit. You would have a Codeunit Delta that cannot be converted to an actual AL object. In such a case, you would have to manually take that text file for the Codeunit and convert it to AL. This would result in multiple iterations when converting everything to AL.
We suggest using Microsoft NavContainerHelper, which makes converting the solution to AL a lot easier. Using NavContainerHelper, create a new container with your base version and export all objects to text. Then import your solution and export everything to AL. You can find more information on how to use NavContainerHelper here.
Merging objects to Microsoft Dynamics 365 Business Central
Once you have converted everything to AL, you can start merging objects to the Business Central version that you are aiming for. In this stage, the same principles apply for AL as they would for C/AL, the only difference here being the coding language. You must export:
- The base objects of the version you're currently on
- The modified objects (your existing solution)
- The target version you are aiming for
After you export everything, do a 3-way merge.
You can automate all three exports using NavContainerHelper. To do that, create a PowerShell script. Freddy Kristiansen, the creator of NavContainerHelper, has a script in his blog that you can run. After export finishes, you would have to merge the differences.
The advantages of splitting solution code when getting ready for Business Central SaaS
Once you have converted your solution to AL and start getting ready for Business Central SaaS, we suggest splitting solution code into separate folders by functional area. This way, it will be easier as you will have less objects to work with. For example, having five folders split by functional area that have 200 pages each makes them easier to work with compared to one folder with 1,000 pages.
Splitting the code might also result in splitting your solution into multiple Apps. You should consider breaking your App into multiple ones only if you see the benefits in it, which are as follows:
- Limit the impact of the Breaking Changes that Microsoft introduces with new releases. For example, if you have 1,000 objects and Microsoft introduces one Breaking Change, your whole solution becomes incompatible. But if you have multiple dependent Apps, then it could be that just one or two Apps will become incompatible, while the rest of the solution remains completely fine.
- Segregate the development. It is a lot easier to handle 200 files in the folder compared to 1,000 files during the development as you can focus on the separate Apps that are most used.
- Install and sell the Apps separately on Microsoft AppSource (if you are going to the AppSource).
Tips for getting started
Transitioning from C/AL to Extension in AL can require a lot of preparation. First, you have to scope how much you have modified the existing NAV/Business Central solution. It might be difficult to do because you can't see the Keys you have modified, the Keys removed and the Keys created, unless you do a comparison analysis on an object by object basis.
Once you have the list of what you have changed, you can start refactoring. As previously mentioned, this could be done in C/AL as much as possible in order that you wouldn’t be limited by the new functionality or the new behavior of AL. It is very important to do the Cleanup and get rid of unused code.
When organizing code in C/AL, you should always think about the future in AL. Every single new development or bug fix, or any new code that you write, should be done with a thought in mind on how this will be converted to AL. So, before you start developing something, see if there's an Event Publisher that you have created or if there's an Event Publisher that Microsoft has created in the latest Business Central versions.
After you have done all the preparation tasks, you can easily convert everything to AL, eliminate the rest of the conflicts, and you will have a completely working AL App. Most of the preparation steps have been discussed previously, except scoping the transition from C/AL to AL.
Scope your transition to Extension with C/AL to Extension Analyzer
You can use C/AL to Extension Analyzer Report to scope C/AL to AL project requirements. To get the report, register/login on the 1ClickFactory Business Portal and upload your solution for analysis. The C/AL to Extension Analyzer Report will be ready in one business day.
The report saves developers time by eliminating tedious manual code analysis and automatically identifies a finite list of conflicts to transition to Extension. The report splits every single conflict found into two areas – C/AL and AL. This way, you have a list of conflicts you can solve in C/AL before transitioning to AL, and a list of conflicts that you can solve afterwards.
Screenshot 1. The C/AL to Extensions Analyzer Report example: project planning board.
You can solve conflicts in C/AL as a preparation before moving to AL while at the same time maintaining your solution. This will help you reduce the conversion step and help manage risks. The C/AL to Extension Analyzer Report indicates the steps that you should take, such as move to Custom Events, move to Existing Events, solve incompatibilities in C/AL, and so on.
The report suggests conflict resolution and shows the closest available Event Publishers so that you won’t have to manually look through every single object. In addition, the report includes proximity to the closest available Publisher within the version and evaluates the confidence level of moving code to Events.
Screenshot 2. The C/AL to Extensions Analyzer Report example: resolution advice and closest available Evet Publishers.
One of the important things that the report shows is the transition step in which to resolve the conflict. For example, the Cleanup step is very beneficial, because you don't know what's unused in C/AL until you delete it. In the report, you can filter out the Cleanup transition step to see all unused custom variables, unused custom procedures, and obsolete functionality in the solution.
Screenshot 3. The C/AL to Extensions Analyzer Report example: extension limitation – cleanup, resolution advice and details of change.
The report validates the solution against 90% of C/AL to Extension limitations. It is very useful when refactoring the code. For example, the report identifies the limitation “Dialog input is not supported in RTC and Web Client”. You can filter this particular limitation and see the full list of objects where a dialog type of variable is used.
Screenshot 4. The C/AL to Extensions Analyzer Report example: objects, limitation, resolution advice.
Now all you have to do is look into why it is used and how can you substitute it.
There’s plenty of other C/AL to Extension Analyzer Report features that will help you scope the solution transition from C/AL to Extension in AL and make it as seamless as possible. 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!