ArcherPoint Dynamics NAV Developer Digest - vol 216
The NAV 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 experts and devotees around the world. We hope these insights will benefit you, too.
Using .NET with Business Central on-premises
Suresh Kulla informs the team: “Today, I have Installed Business Central locally not using Docker. It still refers to the name, ‘Dynamics NAV.’ This is little confusing, and there is lot of discussion in the community about it. I am thinking they will change this when they release the final version. The look and feel of the RTC is the same as NAV 2018.
Bill W adds: “Yes, Microsoft is encouraging the use of the Web client over the Windows client. The new wrinkle is that things will look slightly different in the new BC teal interface as they’ve moved role centers around. According to program manager Mike Cardona, Business Central creates multiple opportunities for partners to provide apps and consulting services.
Kyle notes: “Sounds like NAV 2018 needs to be the last time we use the RTC. Suresh, maybe you should attempt to only use the Web client. Still…no .NET is a major problem.”
Suresh replies: “For Dynamics Business Central on-premises, people might still want to use the Windows client because it is available, although I do agree we might have to change our mindset and start using the Web client. And, as an FYI, you can use .NET for on-premises, but not for the SaaS version.”
Kyle responds: “I do not think you can run .NET in the Web client no matter where the server is, on-premises or cloud.”
Suresh shares: “They have made a change in the June 2018 update. Check it out.”
Matt T chimes in: “I could be mistaken, but I believe it depends on what the .NET library is. If you want your string and datetime libraries, that’s fine. Writing files and restarting services and accessing SQL databases directly, not so much. Once we start moving more towards AL, I think you’ll find that you don’t need it for the most part.”
Kyle adds: “As long as they have AL functions that replace things like getting directly to SQL and file manipulation, that works. In 2018 at least, all of the file handling codeunits that come out of the box still use .NET.”
Matt replies: “They will never give you a codeunit wrapper to let you access SQL directly. Why do you need it?”
Kyle answers: “Getting data in and out of old versions of Dynamics NAV. Integrations with external systems like warehouse management systems or industry specific revenue or purchasing systems. These are just use cases I’ve done from the past three years. Things on the outside can’t always do SOAP, and SOAP is clunky, slow, hard to code, and has poor authentication. ODATA is difficult to filter and control NAV data inserts. Reading and writing files is full of risks and it is hard to track failures. Another good use for .NET is calling external web services, whether SOAP or REST. That Bing Maps distance API that I did uses it—actually, it uses the base-NAV functionality in CU1297, which uses .NET. I will make a point to get the latest version of BC running locally so that I can see what they have done to that codeunit. I assume that Microsoft has stated that you can’t use CU1297 in BC-Cloud?
Suresh, what did you do about a dev license? Did you apply for a personal one from Microsoft, or are you using an ArcherPoint development license?”
Suresh answers: “I used the ArcherPoint license.”
Bill reacts: “Matt Street is facing the same issue with CSM functions in AL. Almost every single function in CU1297 is internal so it can’t be used with an Extension…These classes will be your best bet at replacing .NET.“
Suresh adds: “As part of the RC1 release for Dynamics Business Central, not all the functions are Internal; there are few that are external. Anyhow, you can easily consume the web services using the classes available in AL. Please see Kauffman’s example of AL support for REST web services.”
Matt T notes: “I think for Business Central on-premises, it would be a little different. You can set your app.json target to internal as well as on the service tier. By default, they are an Extension. Or you can use the new variable types for WebRequests, WebResponses, Json, XML, etc.
If you are interested in NAV development, be sure to see our collection of NAV Development Blogs.
Read the “How To” blogs from ArcherPoint for practical advice on using Microsoft Dynamics NAV, and contact ArcherPoint if you need assistance with Dynamics NAV.