ArcherPoint Dynamics NAV Business Central Developer Digest - vol 331
Changes to execution of Job Queue processes and Git terminology changes are discussed in this edition of Developer Digest.
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.
Changes to How Job Queue Processes Execute in New Versions of NAV/BC
Michael H says: “I love how Kyle Hardin is always posting knowledge nuggets in Yammer, so I thought I’d post something I learned yesterday. 🙂 In older versions of NAV, processes on the Job Queue would execute using the credential designated “Log On As” in the service tier properties (Microsoft.Dynamics.Nav.Server.exe and the older nassql.exe). We had to ensure the credential running the executable existed as a user in NAV with appropriate permissions. In newer versions of NAV/BC, processes on the Job Queue execute using the credential on the Job Queue Entry record. So, if a user modifies the record, e.g., setting the status of a JQE to “Ready” Status, their UserId() will be stamped on the JQE record, and subsequent executions of that process will execute under that credential and associated permissions. I suspect the reason why this happens is because users can schedule reports to run later, at a certain day and time (inventory valuation, for example), and those executions will use that user’s permissions.”
Kyle responds: “On the BC developer Yammer group, there was a question about which compiler (version of VSIX) you should use for on prem. The recommendation used to be that you should stick with the version that came with your installation kit, but Microsoft isn’t back-porting any bug fixes or improvements, so you are just stuck. They have since changed their recommendation to this: We versioned the compiler from the beginning (via the app.json version property). While we ship VSIX on the DVD/artifact, we recommend using the latest AL VSIX on the VS Code Marketplace to get new features and bug fixes, and we only test/bug fix on the latest VSIX.”
Git Changes the Initial Branch Name
Matt T informs: “One little change that slipped under the radar was made by Git last year. They are retiring the term ‘master’ as the initial branch name. Instead, it will be named ‘main’. Azure DevOps and the Git Repos there have recently started to adopt this. So, as we create new projects, you’ll see ‘main’ instead of ‘master’. What’s the difference to you? Absolutely nothing from the perspective of how you do your work. But I don’t want anyone to be confused.” Learn more about this change from Git.
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.