Customizing Dynamics NAV
Discover different ways to customize the application to give you and your colleagues access to the features, functionality, and data that you need most.
Dynamics 365 2019 release wave 2 plan Discover the latest updates to Dynamics 365.Release Plan | Weekly Deployment Notes
Ace your Dynamics 365 deployment with packaged services delivered by expert consultants.Explore service offerings
Connect with the ISV success team on the latest roadmap, developer tool for AppSource certification, and ISV community engagements.
ISV self-service portal
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance and Operations TechTalks | Customer Engagement TechTalks | Talent TechTalks
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.
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.
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:
If you choose to go for the “N separated extensions” road, remember that:
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.
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).
When developing Dynamics 365 Business Central extension, you can choose between two types:
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:
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:
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.
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.
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:
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.
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.
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.
Business Applications communities