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!
Hello Vjeko,
Very interesting webniar on Azure functions from AL, however more so for the NAV devs than for the .NET devs I believe, I’m the latter myself.
For me the whole talk about functionality moving to the cloud raises some questions about NAV addins.
I’m interested in knowing where this new “no DLLs” approach leaves addins which would previously be created with a interface (.NET assembly), manifest file and HTML/JavaScript resources.
How would one expose an interface with functions and events for a NAV dev if everything is supposed to run from the cloud (Azure or any other cloud service)?
Hi Peter,
NAV add-ins come in two flavors: server add-ins and client add-ins. Server add-ins we do not really call that way, we simply call them .NET interop. Client add-ins are .NET add-ins and JavaScript add-ins. Azure Functions are a replacement only for server add-ins, not for client add-ins.
Regarding client add-ins, you have .NET add-ins and JavaScript add-ins. .NET add-ins are not supported in web clients, so you should have abandoned that ship a long time ago anyway. Which leaves us with JavaScripts add-ins, and your concern of how are we going to use them since they required a .NET assembly with a declaration of an interface inside? The interface is only used to help C/AL “understand” what the add-in can do, so C/AL can create event triggers with proper parameter type declarations, as well as to ensure compile-type safety of invoking functions in JavaScript. Once development is over, you don’t need that interface anymore, you don’t need to ship it to servers or clients. If you think about this, you don’t really need to have .NET involved in that at all, and in my opinion having to have a .NET interface to declare a C/AL<->JavaScript interface was a bad design decision. Making an educated guess here, the .NET interface part of JavaScript control add-ins will be replaced with some sort of JSON declaration where you’ll use JSON to declare the methods and events. That said, we won’t lose JavaScript control add-ins and they will still be available to us. You will not need to consider Azure Functions to replace client add-ins.
Hope this helps.
Yes, I was referring to client JavaScript add-ins with the .NET assembly defining the interface (methods and events) for the NAV developer to use.
I’m eager to see how the JavaScript part is going to trigger an event in NAV once the .NET assembly is no longer part of this type of add-in.
Whether I’m confident it will go the way that you predict, with some sort of JSON setup for this, I’m not sure, but I do hope so 🙂
Do you know when we’re no longer going to be able to create this type of client JavaScript ad-in (with .NET assembly describing interface for methods and events) and web resource (containing manifest and HTML/JavaScript)?