Dynamics 365 Business Central (SaaS version) is available from April 2018 while in few months we’ll have also the on-premise version. This version will be the evolution of Dynamics NAV (it is time to start forgetting this name) and it will have the same codebase of the online version. We have shared the latest news from Microsoft “What to expect in Dynamics 365 Business Central October release” here.
Some important aspects to remember:
- The on-premise version will also have the Windows Client, but the Windows Client is still the same as in NAV 2018 (you will have the old NAV 2018 interface, not the new “Modena” interface that you have now in Dynamics 365 Business Central).
- You can install it directly from a DVD package like the classic NAV versions, it’s not Docker-container based as we have read in some forums. Do not worry.
- You can administrate all server settings and your database (you can’t do this in the cloud).
- You can continue to develop in CSIDE and C/AL if you want in the on-premise version (but we suggest not to do that and start using the new Modern Development Environment).
As you already know, you can customize and develop solutions for the Dynamics 365 Business Central SaaS platform only by using extensions and the new Modern Development Environment. You can’t use C/AL in the SaaS platform. So, how to start thinking on moving your old NAV solutions and customizations to Dynamics 365 Business Central?
Many Dynamics Partners have a lot of inquiries with customizations, vertical solutions, add-ons and etc., which have been developed during the years in C/AL. They are a core part of partner business and now must be moved to the new Dynamics 365 Business Central platform. The transition from a monolithic C/AL code to an extension-based solution is not a quick and easy task and it’s not only a “conversion of code” from C/AL to AL.
How to Start a Transition Process From the Old C/AL Based Solution to The Extensions World?
Later this year we have written the detailed blog post How to convert Dynamics NAV reports to NAV Extensions.
Talking about transition process from the old C/AL based solution to the extensions we suggest you to start thinking on the question “What you want to achieve?“. The first challenge we see our partners are facing when they start moving a C/AL solution to an extension is how to make the architecture of the new solution.
What are the available architectures building the new solution (from the C/AL to Extensions)?
- Monolithic extension (multi functions).
- N separated extensions.
- Base Layer (Hidden extension) + N Extensions dependent from the base layer.
Monolithic extension
In a monolithic extension, all your solution is packed on a single extension (.app) file:
Monolithic extension
You can create new and extend standard objects in this type of extension. You don’t have dependencies on other modules. This is the simplest architecture to choose (install and go) for the small projects, but for the large projects this should not be used.
Separated Extensions
The second possible architecture is to split your existing solution into N separated extensions (with separation of functions):
Separated extensions
In this type of the architecture, every single extension does a specific work and covers a specific functionality by creating new objects, extending standard objects and it could have dependencies with other extensions. In the diagram above, EXT1 is an independent extension that adds new objects and extends standard objects. EXT2 is an other extension that adds new objects and extends standard objects + objects defined in EXT1 (dependencies).
By choosing this scenario, you have a totally modular solution: you can decide what module to activate for your customer, every extension is “light” but you need to carefully handle the dependency problem between the different extensions.
Base Layer (Hidden Extension) + N Extensions Dependent from the Base Layer
The third possible architecture is to have a base layer extension (with all common objects) + N separated extensions that depends from the base layer.
Base Layer (Hidden extension)
In this scenario, the base layer extension contains new object and extend standard objects by covering all the underlying aspects of your solution (like defining all the new tables of your solution and adding all the new fields in standard tables). You have N separated extensions that covers the single functionality. In this architecture, the extensions EXT1 .. EXTn have dependencies only from the base layer. The solution is absolutely modular (you can activate the function you need for the particular case) and the dependency problem during upgrades is only related to handle the base layer.
What Architecture to Choose?
There is no one answer or a written guidance on what is the best scenario to choose for your new solution. It depends on the type of your existing solution and on what result you want to obtain on a business perspective. We suggest to avoid having a single huge extension that does all. It’s better to have separation of concerns to divide extensions for applicability area (for example the architecture 2 and 3 we have described above).
Do not split a C/AL solution into too much micro-extensions: this will be difficult to manage in the future and difficult to install to a customer’s site (do you remember dependencies?).
You have chosen the best architecture for your solution. But this is not the end. This decision brings up more important questions for you. How to start the coding phase? Should I start rewriting the code from scratch? Should I “convert” my old C/AL code? Should I refactor my old C/AL code before conversion? How can I organize my extension project?
First, ask yourself: “Do I want to develop my new extensions for Dynamics 365 Business Central SaaS (cloud version) or for both?” This will impact the object range available. Second, if you have a C/AL solution at the moment that works and you are selling it, start by “reusing” your existing codebase.
Remember, that if you have extensions V1 in place, these extensions must be converted to V2 before they can be installed on Dynamics 365 Business Central, also for the on-premise world. Extensions V1 are no longer supported.
Talking about the project organization in Visual Studio Code, this is quite a personal aspect. If you like organizing the project tree with folders for functionalities and subfolders for object types, you can do it in Visual Studio Code.
Visual Studio Code
If you have an existing C/AL codebase that works, you could follow the steps bellow:
- Carefully analyze the functionalities that you want to move as a single extension and in C/SIDE and identify the objects that covers the implementation.
- Use Txt2AL to convert the existing C/AL object to AL and load the new objects in Visual Studio Code.
- Check (and fix) the conversion errors and then refactor the code.
The Txt2AL Conversion tool is your friend for starting a migration process from C/Al to extensions V2. After you’ve identified the C/AL objects of your solution, you can export them as TXT files in a folder (named for example MYEXTSource) and using a Command Prompt, launch the following command:
“C:Program Files (x86)Microsoft Dynamics NAV110RoleTailored Clienttxt2al.exe” –source=C:MYEXTSource –target=C:MYEXTTarget –rename
This command will convert your C/AL object to AL objects and after that in the MYEXTTarget folder you’ll have a series of .al files that you can open in your Visual Studio Code extension project. Remember, that these objects are just a starting point!! You have to fix some errors (Txt2AL is not the perfect tool for this). You have to add some properties essentials for Dynamics 365 Business Central (like DataClassification on fields, UsageCategory and ApplicationArea on pages and many others) and after that, you have your existing code migrated “as-is” to AL.
The next step you need to do is certainly refactor the code. Remember, that in the AL world you have to use events for interacting with standard code, so if your existing code has interactions with a standard object (often ISV solutions adds lines of code directly inside standard objects) you have to recreate the same lines of code by using an event subscriber to a Microsoft Integration event in the existing object.
What to do if Microsoft has not the event that I need in a standard object? You should ask for it here and it will be delivered in the next upgrade iteration of Dynamics 365 Business Central.
The other problem you could have, when converting your C/AL code, is related to function visibility. If your extension targets only the on-premise world (you should add target = internal in app.json file):
Adding target = internal in app.json file
In this way, you’ve a complete visibility of all functions and objects that you have in a classic NAV environment (and yes, also to DotNet variables).
If you omit this, your extensions targets (including the online world) you can see only those functions, which have the FunctionVisibility property setted as External:
FunctionVisibility property in NAV
The last important aspect for you to consider when developing an AL extension is extensibility.
Standard ISV solutions, which are developed with C/AL, do not trigger integration events. This could not be a problem in C/AL, because you can directly customize the object itself, but what about AL?
If you want your extension to be “extendible” and that other extensions could integrate with yours in a near future, you should always raise Integration events in the relevant parts of your business process. This is an important aspect that usually everyone forgets. Use events and trigger as much as possible where needed. This guarantees extensibility of your solution and integration.
Are you ready to start your migration process to the new extension world? Need more information about AL World and assistance on moving your solution into extensions? Take the 8 hours Dynamics NAV Extensions Training Course from Simplanova academy. Have a lack of resources on your Dynamics NAV/365BC projects? Simplanova is your partner for Dynamics NAV/365BC upgrades, delivering the high quality Dynamics NAV/365BC development services or upgrading your add-on to extensions. Get a FREE Quote today.