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.
This webinar, which is organized in cooperation with NAV-Skills, will cover the theory I scratched in my last blog post here, but will cover some more stuff. On top of a little more substance and structure than covered in my blog, it will also give you an opportunity to ask questions and make fun of me in front of an audience. Last opportunity for this before Directions US
So, grab your seat by registering here. It’s free, but even if it wasn’t, you should still be there. Don’t let me find you absent, you are not excused!
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?
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.
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?
Progress often doesn’t look like progress at all when it first arrives.
When on July 3, 1886, Daimler Benz presented his first car, it had a 0.75 horse-power engine that could reach a top speed of 16 km/h. It was able to cover 45 km on a single fuel tank, and it could only take two passengers. Compared to best horse-driven carriages of the day, especially taking the availability of stuff you could use as fuel, this was hardly a progress. Horse-driven carriages bested this car on all fronts, and by large margins.
Imagine what the world would look like today should Daimler Benz heeded the naysayers and mockers of his day, and they were not in short supply.