Best practices for starting with Dynamics 365 Business Central extensions

In Microsoft’s ERP world the big change has already started and this is the right moment for partners to start rethinking on their solutions. Despite the last announcements (you will be able to sell Dynamics 365 Business Central April 19 release till October 2020 and this is a window where customers can keep using Windows Client and make CAL customizations if they have to continue working with this platform), the future is signed and the future is AL and Dynamics 365 Business Central extensions only.

Moving an old C/AL-based solution to a modern solution based on AL and the Dynamics 365 Business Central extension’s framework is not always a simple work of “code conversion” but in many cases, it involves rearchitecting the solution. I’ve always said that this is my preferred way of work (rearchitecting is better than converting old fashioned code) but to start this process on the right way, you (and your organization too!) need to have in your mind some important aspects in the Dynamics 365 Business Central extensions world.

In this article, I will list my personal 10 rules/best practices/recommendations to start working for Dynamics 365 Business Central Extensions. These 10 points are not listed in priority order, but I recommend to keep them in mind when starting working with AL.

Rule 1: start from your actual base code

Rearchitecting is important and essential when moving an existing C/AL solution to Dynamics 365 Business Central extensions, but don’t forget your actual base code. Normally, an existing C/AL solution is made of new objects and modified standard objects. New objects can be immediately moved to AL, and a tool like Txt2AL is your friend here.

This is the path I recommend:

Convert your existing C/AL objects to AL and then refactor your AL code. This process can help speed up the work, at least for starting.

During this process, there’s a second step that I always suggest to partners: SaaS should be always your point of reference when developing an extension. Please try to avoid using target = internal for your Dynamics 365 Business Central extensions as much as possible.

Rule 2: do not avoid dependencies

When moving an existing ISV solution to Dynamics 365 Business Central extensions, the first dilemma that normally developers have is: how many extensions should I do?

The choices normally are a monolithic extension vs N separated extensions. This choice is up to you, it depends a lot on your solution and it should be carefully evaluated.

A monolithic extension normally is:

• Simple to manage and develop (at least for starting)
• It requires more time to be released (100% of the functions must be ready)
• You don’t have modularity

If you choose to go for the “N separated extensions” road, remember that:

• An extension cannot see objects from another extension.
• If extension 2 needs to see objects of extension 1, it must be dependent from 1.
• You need to carefully handle dependencies between the different Dynamics 365 Business Central extensions.

My suggestion here is: don’t abuse on splitting (for example, a single extension for every minimal existing functionality) and do not afraid to use dependencies only because they bring complexity in your development process.

Rule 3: do not fork the base code

The extension model has a great advantage over C/AL: it permits us to create customizations on top of a standard layer. This is a rule that you must always follow on your solutions, especially when you customize your solutions for specific customers.

One of the errors I see on some partners is that they continue to have a “C/AL-like” approach to customizations of their products. If you have released a solution as an extension (and this is your base solution) and N customers asks you to have specific customizations for your solution, please don’t create N “copies” of your base solution and modify them for every customer:

What you should do is to create the customizations as a specific per tenant extensions that will be dependent from your base extension:

This will permit you to have ONLY ONE SINGLE BASE CODE (a must in the extension’s world).

Rule 4: Select the right type of Dynamics 365 Business Central extensions for your business

When developing Dynamics 365 Business Central extension, you can choose between two types:

• Per-tenant extensions (PTE)
• AppSource extensions

The main difference between the two types that you should have in mind are the following:

Many partners think that per-tenant extensions are more easy for starting (no validation process, you can manage all by yourself), but per-tenant extensions also have their (big!) problems due to their internal processing by the Dynamics 365 Business Central engine. In particular, what normally happens with PTEs on every partner I see is the following:

They release an application X as a PTE to Customer 1: all is ok

Then Customer 2 wants the same application (PTE X), they compile the project (check if all is ok, etc) and they deploy the extension to Customer 2:

Unfortunately, the same PTE extension can be uploaded to different tenants only under certain conditions:

• If the Dynamics 365 Business Central regional service is different for customer 1 and 2
• If the Dynamics 365 Business Central regional service is the same for customer 1 and 2 then the following 3 conditions (in OR) must be respected:
  • only if Package ID is the same;
  • only if AppID or Version is different;
  • only if Name, Publisher and Version are different.

Rule 5: Getting your app into AppSource rules

• If your strategy is to release your apps on AppSource, then you need to start an approval process by Microsoft and only after that process, your app will be available on Microsoft’s marketplace. Also, all the future updates for your apps must be approved by Microsoft.

I’ve recently talked about AppSource on this post, so please read it carefully here.

If you go for AppSource, I have also these recommendations:

• Don’t under-estimate the marketing validation.
• Sales for your app can be different than “architecture” of your app: if on AppSource you have an app that is split into N modules, what customer pays is up to you and this could be not 1:1 to the app itself.
• Protect your app with custom license management.
• Don’t store license keys or other sensitive data on custom tables. Instead, use the IsolatedStorage.

Rule 6: Handle schema changes

Always remember that Extensions V2 does not support breaking schema changes across synchronized versions of the extension. Once an extension is synchronized to a tenant in a product environment, then all the next versions (upgrades) must have a schema that is backward compatible.

If you create breaking schema changes from version 1 to version 2 of your published extension, you need to handle the upgrade process in an upgrade codeunit, and you need to target fields and objects removed or changed with the ObsoleteState property as described here.

The rule here is: be careful before deploying a solution into production! Check your code and your database structure. Things that until now you do in C/AL (objects moved in the production environment and then changed by using Force) cannot be done so easily on SaaS.

Rule 7: Try to be “data agnostic” on your development process

This is a common problem I see almost every day on every partner. During the development phases, in C/AL you have your database with your data for testing. Partners work in the same way when developing AL solutions, and they manually insert test data into their custom objects in order to check if the deployed extension works. Normally, when you deploy from Visual Studio Code, your data is preserved:

Unfortunately, during the development phase of an extension is quite common to “correct mistakes” and have the needs to “force” schema changes. If you deploy with “schemaUpdateMode”: “Recreate”

all your data will be lost:

I think it’s extremely important to start using automatic testing for your apps. This is a need (mandatory!) for AppSource apps, but it’s extremely recommended also for every extension.

Rule 8: Use events if you want to be extendible

This is another common error I see quite often. When a partner moves its C/AL-based solution to AL, it doesn’t think on the extensibility of the solution (extensibility for other partners that uses the solution or for the author itself).

To be more clear, consider an extension that adds a new function (feature) called CreateSpecialOrder to Dynamics 365 Business Central:

Without exposing events:

• you can modify the behavior of the solution for a customer only by modifying the base app itself;
• another partner that uses your solution cannot modify the standard behavior.

When you create Dynamics 365 Business Central extensions, remember to add events (Integration events) to your extensions in order to permit extensibility. In the example, you could have something like this:

Here another extension can subscribe to the events and make some actions or change the standard behavior of the CreateSpecialOrder method. This is a pattern that you have to remember always, or your solution will not be customizable.

Rule 9: Handle source control

This is a problem that you will have starting from the first day of developing extensions in the team.

Now, all the “components” of your development environment are no more on a single box:

With NAV you have The C/SIDE and all your objects are stored on the database itself. If you work on a team, when you access an object on C/SIDE, you can immediately see the modifications that other colleagues have done on that object.

AL development is different, and you have:

–    docker-based environments that can be different for every developer;

–    Visual Studio Code (on the developer machine);

–    AL project files and folders (stored on the developer machine).

Source code is now external (file-based), and you absolutely need a central repository for your code and a source code management tool for handling merging and conflicts. Start being confident with GIT and embrace tools like GitHub or Azure DevOps (my personal favorite tool) for handling your projects:

This can save you time and efforts.

Rule 10: remember the notification recipients in the Admin Center

This is another point to remember. Dynamics 365 Business Central has an Admin Center where you can administer some aspects of your tenant (like creating sandboxes, managing upgrade windows, checking the telemetry, etc.).

One of the key points here is the Notification recipients panel:

Please always insert the email address of the users (administrators) here, that should receive notification from Microsoft about this tenant. This is the only way for being notified about problems on your tenant (like upgrades or extensions that doesn’t work with a new tenant upgrade like described here.

These are quite simple rules, but you should have them clear in your mind if you want to start on the right road with Dynamics 365 Business Central extensions.

The post Best practices for starting with Dynamics 365 Business Central extensions appeared first on Simplanova.