Navigate Into Success: Invoking Azure Functions from AL

[Blog bot]

Источник: http://vjeko.com/invoking-azure-functions-al/
==============

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/azu...tions-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.



First, let’s create a new Azure Function. Being a JavaScript junkie that I am, it will of course be a JavaScript function. I’ll start from here:



Then, I’ll create a simple function with anonymous access, just for sake of simplicity:



And then, I’ll put some code in my “meaningOf” function:



As simple as that.

Then, I’ll copy the URL of the function by clicking Get function URL > Copy.

Next step is to create some AL code to consume this function. For that, I start with > AL: Go! and then replace the content of the HelloWorld.al file with this:



As you can see, calling RESTful services with the new Http API, that’s now available at AL language level is amazingly simple:

1. Declare an HttpContent variable. This will hold the body of your request.
2. Declare an HttpClient variable. This will place the request to the Azure Function.
3. Declare an HttpResponse variable. This will receive the response from the service.

And then, with a few simple lines of AL code you write the request to the body, post it to the Azure Function URL, receive the response from it, and then read the result into a variable. As expected, this reveals the life’s truth:





Now, invoking these functions is easy and they seem to be fast, too. However, how fast exactly are they?

There is a simple rule – your function must be deployed close to your NAV instance for it to be as fast as possible. If you run your NAV and host your Azure Function app in the same data center, you can expect some decent performance. However, if you host your NAV in US, and your Azure Functions in Japan, then your performance will be sluggish at best.

What exactly is “decent performance” and what exactly is “sluggish” can be easily quantified. I have deployed my NAV in an Azure VM in West Europe, and then deployed three Azure Function apps in West Europe, North Europe, and Australia South-East. Then, I have invoked this function a hundred times and I got these figures (averages of three runs):

• West Europe: 2.792 seconds
• North Europe: 13.045 seconds
• Australia South-East: 147.371 seconds

Obviously, there is overhead that’s related to HTTP communication. But depending on what exactly you do, 28 milliseconds per invocation may not be such a big deal for something that doesn’t really have to be invoked constantly. Having an occasional invocation here and there will provide imperceptible speed difference as compared to local, in-process .NET invocation. So, scenarios such as barcode generation, encryption of larger chunks of data, regex validation, bitmap manipulation, or anything else for that matter that you do once per business process, will all behave as fast as they used to. Actually, they won’t, they will be some 28 milliseconds slower, but users won’t perceive that.

However, that’s 28 milliseconds when you are doing everything in the same datacenter. Once your function and your NAV instance are a bit farther away, the latency kicks in and everything is not so wonderful anymore. This means that to have fantastic responsiveness, you’ll have to maintain copies of your functions in multiple datacenters.

And now it’s time to debunk a myth. A lot of people think JavaScript is “interpreted” and many more believe JavaScript does not perform as fast as “real languages”. So, now that I have an environment that can match JavaScript with “real languages” head to head, I’ve created a C# copy of my function, just to see if I would see significant performance improvement of C# over JavaScript.

Here’s the hero:



Guess what? I didn’t. Guess what else? I actually saw performance penalty of C# over JavaScript. Honestly, I didn’t see this coming, but it seems that Node.js is apparently one hell of a powerful runtime environment. Want numbers? 3.206 seconds for 100 invocations. That’s roughly 15% performance improvement over C#. Lovely Now don’t JavaScript-is-not-a-programming-language me anymore.

Before I close, let me share a dream I had last night. I had a dream that AL code makes invoking Azure functions even simpler. You see, HttpTrigger is just one kind of triggers for running JavaScript, and perhaps a way can be found to create a different kind of triggers, one that can respond directly to an AL invocation from a D365 application using a more tightly integrated language feature than HttpClient invocation. I’d love to see a possibility to invoke Azure functions with simply doing something like Result := CallAzureFunction(‘Name’, parameters…)

A man can dream, right?

Words of wisdom for the end? Not much. Azure Functions are both simple and powerful way to replace your .NET interoperability stuff with something very similar. They don’t perform as fast as in-process .NET does, but depending on what exactly you do, you won’t feel it a tiniest bit. And with a little bit of imagination, you can do crazy things with them. Crazy things.

Read this post at its original location at http://vjeko.com/invoking-azure-functions-al/, or visit the original blog at http://vjeko.com. 5e33c5f6cb90c441bd1f23d5b9eeca34The post Invoking Azure Functions from AL appeared first on Vjeko.com.




Источник: http://vjeko.com/invoking-azure-functions-al/