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.
Saurav implies that this may be the case and shares Vjeko’s latest post that discusses what exactly an Azure function is and shows how to invoke Azure functions from AL, providing an “elegant way of replacing your .NET interoperability code.”
Michael Heydasch comments, “It will become important to develop a "library" of web functions we can call from AL code, whether they are Azure Functions we wrote or other web services, in order to replace the .NET functionality we had before. Each developer has a "toolbox" of functions we have relied upon in the past (right Faithie Robertson?); this will be no different and will be a huge step forward for AL code. And I haven't even launched the AL dev environment yet!”
Matt T adds, “Replacement yes. Required replacement, not sure yet. .NET Interop is very much dead, though.”
Kyle asks, “If .NET goes away and is replaced with Azure Functions, how will that work for customers that have their own servers, something that isn't hosted in Azure?”
Michael responds, “Create an Azure Function and publish it as a web service, or use another web service unrelated to Azure Functions. Hosting in Azure is unrelated, you're simply calling a web service from NAV.”
He further elaborates, “Appears Azure Functions is a way to process events with a serverless code architecture: an event-based serverless compute experience to accelerate your development. Scale based on demand and pay only for the resources you consume." More info: https://docs.microsoft.com/en-us/azure/azure-functions/functions-overview
Kyle chimes in, “Excellent article for a 10,000-foot view. It is as I suspected though, the Azure Functions are only in the cloud. You can call them from anywhere, even a local server, but they still execute in Azure as pay-per-view.
So a customer that is adamantly anti-cloud and wants all of their data and code execution in their own building cannot use this. I suppose they could build their own internal Azure cloud, but that seems like overkill for a mid-market ERP system.
Is this where Microsoft is going? That Azure is going to be mandatory?”
Michael responds, “Web services can be created on-premise, of course; however, if part of your workforce is remote, then security concerns are introduced by publishing those web services outside the corporate LAN.”
What do you think, Developer Digest readers? Please share your comments below.
How did Bob Dylan teach us a lesson in emotional intelligence in less than 30 seconds? By stopping to reflect on his achievement of being awarded the Nobel Prize in Literature before responding. We can all learn a lesson here: stop and think, process it all, before speaking and acting.
Stay abreast of what is new in the Microsoft Dynamics NAV community and at ArcherPoint by subscribing to our monthly newsletter, Better Business, by completing the form in our Resource Center.
And, if you are interested in NAV development, be sure to see our collection of NAV Development Blogs.