Skip to main content
Submitted by Suzanne Scanlan on 31 January 2020

ArcherPoint Dynamics NAV / Business Central Developer Digest - vol 278

The NAV community, including the ArcherPoint teArcherPoint Dynamics NAV and BC Developer Digest Blogchnical 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 experts and devotees around the world. We hope these insights will benefit you, too.

Don't Ever Check the "Delete Table Records Before Processing" Option

Kyle shares this wisdom: “RAPID advice: Don't ever check the option, ‘Delete Table Records Before Processing’ in a rapid package table. Here’s one scenario:

Package has 100 rows 

Apply (records are deleted) 

30 package errors 

Fix the errors 

Apply 

Now you have a table with 30 records because the first 70 were deleted during the second apply. Always delete records yourself so you control what and when.”

Making an Event Subscriber Procedure Public

Kyle asks: “Is it OK to make an event subscriber procedure be publicly callable?

[EventSubscriber(ObjectType::Table, database::"Sales Line", 'OnBeforeUpdateUnitPrice', '', false, false)] procedure OnBeforeUpdateUnitPrice(var SalesLine...

I removed the local procedure definition so I can call that code from other places, not just during an event.”

Matt T replies: “I guess in theory, but I think it would be better to create a normal function that is global and then call that both from the subscriber and wherever else you want to.” 

Bill W adds: “Similar to a hook, the subscriber should call a procedure. I don't think you put code directly into the subscriber function. Technically, it's just an attribute to a function, so I don't see why it wouldn't work this way and also answer to the emitted events.” 

Using SaaS Help Files in a Business Central On Premises Installation

Kyle offers this good news: “Developer Tip of the Day: If you are using Business Central On Premises, you do not have to install a Help Server. You can configure it to use the SaaS version, at least in BC15. Find the navsettings.json file in the web content (see image below). Comment out the help server lines and add BaseHelpUrl. 

//"HelpServer": "corp-nav-app02.servername.com", 

//"HelpServerPort": 49000, 

"BaseHelpUrl": "https://docs.microsoft.com/dynamics365/business-central/", 

This should work for the web clients for BC14 and BC13, too, though you will have to figure out what link the online help needs to use.”

Read the full article on Configuring the Help Experience for Dynamics 365 Business Central.


Figure 1 – The navsettingsjson file can be found on the desktop

Making the Case for Continuous Development Deployment

Matt T. on deploying code: “I thought I would share a story on the value of small, continuously integrated development from over the weekend. I am still in the habit of queuing up a bit of development and deploying it all at once. Despite all of the things we have in place, sometimes this still doesn't work. Our solutions can compile and test locally, even build successfully. And we can still go to deploy and get the dreaded ‘internal server error’.  

This is a more painful problem on SaaS as you don't have access to the server, and those types of events are not exposed to the telemetry we do have access to. You are pretty much stuck going object by object, then integrating that object into the last successful deployment. Remember, while it might be contrary to what we are used to, there is no reason we can't deploy an incomplete solution as long as it doesn't change other system functionality.” 

Bill W. notes: “There should be more of an error in the deployment status page. Did you get anything else for the error message? Make sure the Docker image you're using matches the environment you're deploying to. Normally, there are not many differences between SaaS and on premises, but SaaS is a moving target. Right now, I'm looking at a tenant that has a base application installed at a version higher than I can get in the latest Docker image. There needs to be major improvement in this area.”

Matt T replies: “Ha, that was the detail :)   

Deployment failed. Errors: App ID : 7209eeaf-ff5c-41cb-8c48-3c7367709089 Message : { Failure status code InternalServerError returned } - Job Id : 573a2e50-4e84-492f-8ed4-84ed1f55a721 

The code that caused the issue was a new page extension to the Sales Shipment Lines. I was only adding a field to display. I haven't figured out why yet.” 

 

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.

Blog tags