Thursday, May 14, 2020
This is the second part of the blog post “C/AL to Extension transition alternatives: how to choose wisely.” In the first part, we reviewed the three alternatives to transition from C/AL to AL. If you haven’t read Part 1 yet, check it out now! In this blog post, we will look closer at the transition steps you need to make when moving custom functionality from C/AL to Extension in AL.
Table of contents:
Limitations to transitioning from C/AL to Extension
How C/AL to AL limitations are spread according to the specific transition steps
Moving From C/AL To AL
Base App Modification
Web Client
Getting ready for SaaS
How 1ClickFactory can help
Limitations to transitioning from C/AL to Extension
When planning the transition to Extension, the first question that comes up is: “What limitations will I have to solve to move a solution from C/AL to AL?” The answer is this:
The above list contains all C/AL to AL limitations that we identify at 1ClickFactory with the specific tools. We will discuss some of these limitations later in this blog post. In addition, you can download the entire limitations list on the 1ClickFactory website, C/AL to Extension Analyzer page.
At 1ClickFactory, we have split these limitations into the specific transition steps that we recommend making for the optimal solution transition from C/AL to AL.
How C/AL to AL limitations are spread according to the specific transition steps
The first step in the transition to the Extension project is done in the C/AL coding language, and it is a Cleanup of the solution.
The cleanup involves removing any unused functionality from the Business Central solution still on C/AL, such as unused variables, functions, and objects. As a result, when moving from C/AL to AL, you will have a lot less code to reimplement.
Moving From C/AL To AL
The next step is to move from C/AL to AL.
When moving from C/AL to AL, the first thing that needs to be done is for all the current solution’s C/AL code to be moved to the “New Syntax”:
- Export Standard Objects to the New Syntax.
Take the standard solution of Business Central on which the custom solution is based and run the “Export-NAVApplicationObject” command with the parameter “-ExportToNewSyntax” in the PowerShell. Once you do that, you will get a new C/AL Object text file which is based on the New Syntax of Business Central. After that, repeat the same with the custom solution. - Export Custom Objects to New Syntax.
Take the custom solution and use the same command “-ExportToNewSyntax” to generate the same custom solution (the solution with the standard and custom changes on the objects) objects in the New Syntax.
Wondering how the New Syntax compares to the old one?
The differences are visible in the image above:
- The date and time format
- Object declarations such as on the “SourceTable” On the new syntax, the full name of the object is written
- Attributes that use an option of “Yes” or “No”, have been changed to “True” or “False”
- Variable declarations use the full object name
- Casing changes in the code
But can this object be re-imported to Business Central? The answer is “no”. If you have the text objects with the New Syntax, you will not be able to reimport them back directly to NAV/Business Central.
When you have both your solutions (standard solution and custom solution) on the New Syntax, the next step is to investigate both solutions and to check what differences the custom solution has when comparing it to the standard Business Central solution.
Get the deltas between the two solutions
To get the differences between the standard and custom solutions, you have to compare them.
Run Text2AL and get the .al objects
After you get the deltas between the two solutions, use the Microsoft-provided Text2AL tool, which creates most of the AL objects from the deltas. The keyword is “most”, because not all modifications (deltas) are moved automatically. For example, if you have any conflicts in those deltas when you compare the custom and standard solutions, these deltas will not be moved to the AL automatically. This means that you will have to move these differences manually, code by code, into the new Extension solution. This is done in a couple of steps called “Move to Events” and “Base App Modifications”.
Move to Events
This step involves two parts:
- Moving the code modifications to Events and Publishers
- Moving the custom functions in standard code to separate codeunits
There are several limitations that can occur when moving code to the event architecture. For example, if you have any new parameters added to a standard function, you will not be able to move these modifications into the Extensions easily, and some type of reimplementation will be required. Among the most common limitations are Exit functions, which are not easily reimplemented to Events. These functions work differently when being executed in different scopes. For example, if an Exit function is executed in an object trigger, the code after the Exit function will not be run, but if it is executed in a subscriber, it is only going to escape from the subscriber scope, not the trigger on which the subscriber is called. Therefore, these Exit functions might need to be reimplemented with handlers. In such a case, when you have some code that you are not able to move, you need to start thinking about what modifications you should leave in the Base App.
Base App Modifications
The Base App modifications are changes that are left in the Base Application that could not be moved to Extensions. There are a couple of scenarios where you may need to leave code in the Base Application.
- Flow Modifying Statements (“if”, “switch”, “case”): These types of statements change how the code is run in the Base Application and it may not be possible to reimplement such functionality in Extensions.
- Not having a publisher fitted for the modification: There are scenarios where the modification does not necessarily fit with the publisher which is closest to the code. Also, sometimes a publisher close to the modification does not exist at all.
- Breaking changes, such as Field Length changes, field removals: No breaking changes such as these are allowed on Extensions, so some of these fields may need to be left in the Base Application.
Web Client
When moving from C/AL to AL, most customers will be using the Windows Client with their C/AL solution. But since the release of Business Central 150, the Windows Client has been discontinued. This means that some functionality that may not be available on the Web Client will need to be reimplemented.
With the Web Client comes additional limitations. One of those limitations is .NET RunOnClient functionality. Therefore, if you have any type of this functionality, you will not be able to run that specific code in your Extension. You will get an error and you will have to reimplement this functionality. Also, any File Upload- or Download-related functions in the solution will have to be reimplemented for the solution to work. As this reimplementation on the situation can differ, you might have to use Azure functions or a different type of storage.
After the Web Client step, you need to start thinking about data migration.
Data Migration
The data migration is not as easy as it used to be before, and it may cause some additional issues. One of the reasons is that in Extensions a different type of storage is used. For example, if you are moving from C/AL to C/AL, all modifications are made directly on tables. In AL, if you have an Extension, an additional companion table is created with the same primary keys and you’ll need to think how to move this data. Here you can refer to Microsoft documentation which goes in depth on how to migrate from C/AL to AL.
After the data migration part, you are ready to use the solution on-premise.
But what if you want to use the solution on SaaS? Or publish the solution on AppSource? In such a case, additional steps are required.
Getting ready for SaaS
We always recommend moving to the newest Business Central On-Premise release and then moving to SaaS from there. In addition, you need to complete the following steps:
- Eliminate any existing Base App modifications. While getting a solution ready for SaaS, there cannot be any modifications left on the Base Application.
- Eliminate any .NET Any type of .NET functionality is not allowed on the SaaS environment. We recommend reimplementing this type of functionality through some type of Web Services (e.g. Azure Functions).
- Eliminate any functionality that needs access to server resources. Functions that need access to server resources (e.g. File Upload or Download functions) are not allowed on the SaaS
- Prepare the solution so it would comply with the needed If the solution is going to be published on AppSource, it needs to comply with the AppSource requirements. However, if the solution is a Per-Tenant Extension, it still needs to comply with the Per-Tenant Extension requirements.
How 1ClickFactory can help
At 1ClickFactory we have the C/AL to Extension Analyzer. It is a self-service which analyzes the solution in 1 day and provides the report which identifies a list of conflicts that Dynamics partners might encounter while transitioning the solution from C/AL to an Extension in AL. Next to that, it recommends a resolution for each conflict based on 1ClickFactory best practices. The report helps to easily calculate how much effort is required by you or your technology partner to move the solution to an Extension. The overview of this report is free of charge and to get it, all you need to do is upload the solution now for analysis.
You can also watch Mantas Paskevicius’ webinar recording on this topic on YouTube: