ArcherPoint Dynamics NAV Business Central Developer Digest - vol 326

ArcherPoint Dynamics NAV Business Central Developer Digest - vol 326

This edition of Developer Digest features a detailed discussion of installation versus upgrade codeunits in Microsoft Dynamics 365 Business Central.

The Dynamics NAV and Business Central community, including the ArcherPoint technical staff, is made up of developers, project managers, and consultants who are constantly communicating, with the common goal of  sharing helpful information with one another to help customers be more successful.

As they run into issues and questions, find the answers, and make new discoveries, they post them on blogs, forums, social media…so everyone can benefit. We in Marketing watch these interactions and never cease to be amazed by the creativity, dedication, and brainpower we’re so fortunate to have in this community—so we thought, wouldn’t it be great to share this great information with everyone who might not have the time to check out the multitude of resources out there? So, the ArcherPoint Microsoft Dynamics NAV Developer Digest was born. Each week, we present a collection of thoughts and findings from NAV/BC experts and devotees around the world. We hope these insights will benefit you, too.

Installation Versus Upgrade Codeunits: Where Should Your Setup Tasks Go?

Tom H poses this scenario: “I’ve been known to write one-time C/AL reports to take care of setup tasks when I move a project to production for a customer—stuff like changing Report Selections to use a custom Sales Order report or setting fields in some setup tables. 

Thinking about how AL deployments work, would it be advisable to put that kind of code in an upgrade codeunit? It seems like it could be used to do the same kind of thing, although I don’t know upgrade codeunits well yet.”

Kyle explains: “There are two kinds of codeunits in play (ignoring test codeunits): installation ones and upgrade ones. Installation ones are the correct type for what you are trying to do. But the way we do version numbers, always incrementing every build we do, will make upgrade codeunits always fire just like installation ones do. I still think installation codeunits are the correct way to go. I have toyed with the idea of allocating a single codeunit for this task, but just update the code in there as necessary. I don’t want to litter the customer database with unused (and now obsolete) codeunits.”

Bill notes: “I have two codeunits that handle the install/upgrade tasks. Upgrade CU with the OnUpgradePerCompany trigger. If you’re upgrading data, you want to know or control for the version you’re coming from. The current/future version doesn’t matter. You really would only want the data upgrade to happen for that specific old version. So, a version 1.0.20200101.20000 gets data upgraded, and if it’s any higher version then it doesn’t. Use ModuleInfo to get the currently installed extension version to check as you’re installing the upgraded extension and control that upgrade code only runs once.

codeunit 70004 “SEN Upgrade” {     Subtype =
Upgrade; trigger OnUpgradePerCompany(); var         Module: ModuleInfo; begin         NavApp.GetCurrentModuleInfo(Module); // Our version numbers are in the following format: Major.Minor.Build.Revision if Module.AppVersion.Major = 1 then; if Module.AppVersion.Minor = 0 then; if Module.AppVersion.Build = 20200922 then; if Module.AppVersion.Revision = 20000 then; end; 

Matt S adds: “In CSM we have a codeunit that outputs a text file codeunit object to load the same data that is in the current DB instance. We stopped using the result codeunit to load the data when we separated out the apps by integration (Amazon, Magento, Shopify), but what we do now is use the output to paste in the data to our now individual app data load codeunits. It is very valuable since all our request variables and mappings for response processing are all database driven.”

Bill then shares this: “Ok, looks like there is an even better way to do this: Upgrade Tags. Which has, apparently, been around for a LONG time. Copy Company and Initialize Company calls a SetAllUpgradeTags method, which looks like it will set all of the previous tags in the new company, so the routine doesn’t run again.” 

Learn more about this in Microsoft’s articles, Upgrading Extensions and ALAppExtensions Upgrade Tags.

If you are interested in Dynamics NAV and Business Central development, be sure to see our collection of NAV/BC Development Blogs.

Read the “How To” blogs from ArcherPoint for practical advice on using Microsoft Dynamics NAV and Dynamics 365 Business Central.

Trending Posts

Stay Informed

Choose Your Preferences
First Name
*required
Last Name
*required
Email
*required
Subscription Options
Your Privacy is Guaranteed