Skip to content

ArcherPoint Dynamics NAV Developer Digest - vol 147Developer Dude

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.

Will Azure Functions Replace .NET Interoperability Code in NAV 2018?

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.

Leadership Lines

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.

Blog Tags: 

Comments

Comment: 

MS them self say that .Net is not going away totally. It will still be accessible on on-premise installations. As there will always be companies that either can’t have their data in the cloud because of legal reasons or very secret/sensitive data. Like certain companies in the banking sector or ships that won’t have internet access constantly.

And there are things you can’t do on Azure PowerApps. F.ex. integration with on-premise fingerprint scanners that require .Net Interop or remote control of industrial machines. Both things I know is used in the field, by personal experience.

Comment: 

Admin posting on behalf of Matt Traxinger: 

Absolutely, .Net will never die completely and there will always be specialized types of customers. For me, it’s about giving customers the most options, both now and in the future. Overuse of .Net interop within NAV virtually guarantees that a customer will never be able to switch away from an on-premise deployment without what could be a large refactoring effort. Also, in my opinion the windows client isn’t going to be around much longer. And there are a lot of .Net interop things that don’t work with the web client. To me it’s all about making sure our customers have options and minimizing potential upgrade pitfalls. Moving away from .Net interop seems to be the best choice for the majority of customers.

Comment: 

Soon in my book is in 10 years. As long as the Web Client cant use the same amount of hotkeys, then you will never get a bookkeeper to use it. For now it is purely for light weight use.

As I said, there will allways be people that either can't or wont use cloud services. And as long as there is some that can't, there will be some that won't.

Read ArcherPoint's Blog Follow us on Twitter Follow us on Facebook Follow us on LinkedIn Link to our RSS feed Join us on Google+ Watch us on YouTube
Get Help Now