The “Invoking Azure Functions from AL using Visual Studio Code” webinar is over, and it was a pleasure delivering it for you, folks. There were 350+ people registered for it, and over 200+ people attended it. With those kinds of stats, who wouldn’t want to deliver more of these?
So, I can promise to prepare a couple of more Azure Functions from AL seminars, covering different kinds of topics, including handling binary data, XML, advanced JSON, and similar. Stay tuned.
In the meanwhile, if you didn’t have a chance to watch the session today in prime time, you can access it on YouTube: https://www.youtube.com/watch?v=Wp13-nfVoEg&feature=youtu.be
Thanks to Mark and folks at NAV-Skills and Liberty Grove for making this possible.
One elegant way of replacing your .NET interoperability code with something else is by using Azure Functions. Sounds good in theory, but what does it take in practice? And what are Azure Functions, anyway?
Let me not take too much latitude, and let me just say that Azure Functions are a way of running simple pieces of code as a service that you can invoke like any other RESTful web services. And of course, they run in Azure. To learn more about them, follow this link: https://docs.microsoft.com/en-us/azure/azure-functions/functions-overview
Creating them is as simple, as invoking them, so let’s get started with an extremely simple demo that will illustrate how amazingly powerful they are, and why they are a perfect solution for replacing your .NET code with something better.
Continue reading Invoking Azure Functions from AL
I said a word or two about progress last week. Apparently, VS Code is not the only place where we take a small step back to be able to make a huge leap forward; .NET might seem like another one.
You know it, right? You know that if you want to run your .NET code in D365 for Financials, you are out of luck, and you do know that this applies to as much to Microsoft .NET Framework out-of-the-box types as it does to your own, custom-built .NET assemblies. If you don’t know that yet, then let me bring you up to date: In your D365 apps built on Extensions “v2” technology, you won’t be able to use anything .NET; you simply won’t be able to compile AL code that includes a DotNet variable declaration.
This is neither fake news, nor is it news per se. It has been known at least since October last year when Microsoft first presented AL Language extension for VS Code during Directions US in Phoenix. Soon after the VS Code session there was a round table (in all honesty, I have never seen a table, let alone a round one, at any of round table sessions at any conference) on the topic of .NET future, and the mood was grim. At first everyone thought it was a bad joke, then all held hopes high that Microsoft is simply “feeling the pulse” to see how the channel would react to such a disturbing change. But soon it became obvious that .NET interoperability is on its way to be gently ushered out of the (relevant) technology stack of NAV and that we should start getting ready for the day when it’s not there anymore.
So, what is the current state of .NET in NAV, what is the future of it, and what can you do about it?
Let’s take them one by one.
Continue reading State of .NET Affairs