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.
Long time, no see, eh? Life and work sometimes kick in and that’s exactly what they did to me recently. I am not complaining, but I would have been happier, too, if I had been more active here.
Now that I am, in fact, here, let me announce the Invoking Azure Functions from AL in Visual Studio Code webinar that I will deliver next Tuesday, August 29, at 16:00, Central European Time.
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!
See you in the cloud!
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
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.
Continue reading Is Visual Studio Code really an improvement