From the Microsoft Dynamics 365 Business Central and NAV Blogs: Extensions; Custom reports; UI testing; Purchase orders

This week, on the Dynamics 365 Business Central and NAV blog roundup:

• Developing Microsoft Business Central extensions and apps in a team – follow up
• Working with custom report layouts in Business Central or NAV
• Indeed UI testing is slow
• Generate purchase orders in NAV

Developing Business Central extensions and apps in a team – follow up

On Waldo's Blog, Waldo (a.k.a. Eric Wauters) noted that last July he wrote a blog post about the challenges when "working in team on apps."

In this post, Wauters explained how his company is tackling those challenges today and whether the assumptions he made previously really worked. However, he stated that he wasn't going to reiterate the challenges and suggested that readers revisit his previous post.

The first issue he talks about is object numbers:

I hate object numbers, and the fact we still need to use them. The dashboard app that I talked about really works. It has been a very small effort to build something that defines: apps and dependencies; modules (or functional areas) within the app; and manage number ranges for modules.

You can read the rest of his follow-up blog post and find out if his previous assumptions worked here.

Working with custom report layouts in Business Central or NAV

On the ArcherPoint blog, Tom Hunt stated that one of the goals of Microsoft Dynamics Business Central or Dynamics NAV developers is to minimize the work required during an upgrade.

Hunt explained that report customizations can be done more efficiently by using a custom report layout instead of modifying an existing report. He said it is easier to upgrade, and it's not really any more difficult than modifying the layout of the existing report.

In his post, Hunt discussed the limitations of the custom report layout, how to make a custom report layout, and why users would want one.

You can read about working with custom report layouts here.

Indeed, UI testing is slow

On the Van Vugt's dynamiXs blog, Luc van Vugt stated that compared to non-UI, or so-called headless testing, UI testing is indeed slow.

He stated that was one of the major reasons why Microsoft added the testability framework to Dynamics NAV in 2009, replacing the NAV Test Framework (NTF).

NTF was a C# based test framework that allowed you to script test in C# against the NAV UI. Having 40+ country versions to handle, and a couple of major releases, running thousands of UI tests took simply too long to check each country-version build.

Van Vugt stated that at the time, he learned that UI tests took about 10 times longer than an equivalent headless test.

You can read more about UI testing here.

Generate purchase orders in Dynamics NAV

FREE Membership Required to View Full Content:

Joining MSDynamicsWorld.com gives you free, unlimited access to news, analysis, white papers, case studies, product brochures, and more. You can also receive periodic email newsletters with the latest relevant articles and content updates.
Learn more about us here

Get full access

or login