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.
The post Invoking Azure Functions from AL recording available appeared first on Vjeko.com.
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!
The post Webinar: Invoking Azure Functions from AL in Visual Studio Code appeared first on Vjeko.com.
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.
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:
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):
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.
Here’s the hero:
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.
The post Invoking Azure Functions from AL appeared first on Vjeko.com.
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.
It’s very simple, in fact. We still have .NET and we have it wherever we need it. It is still there, but it’s on its way out.
For the sake of this article, let me split all our development work (“us” being “partners, VAR or ISV, in the channel”) into two categories: extension development, and all other development. And then, let me split the extension development into two subcategories: extension “v1” development, and extension “v2” development. Once we have the field set, you can at least know what exactly I am talking about.
Now that we have the stage set, let me immediately address the “all other development” category. If you are in this category and this category is all that interests you, then you have no reasons to worry. Actually, you have a ton of reasons to worry, just they have nothing at all to do with .NET. As far as .NET goes, nothing has changed for you here, and nothing is changing here, and nothing will most likely change for a possibly very long while here. As long as Microsoft keeps publishing downloadable RTMs and CUs that you can install on or your customer’s box, you will be able to declare, compile, and run DotNet variables of any sort.
Now, I don’t know it for a fact, but I can make an educated guess: when (not if, but when) we get VS Code for general development, not just extension “v2” development, I would dare believing that you will still be able to declare the DotNet variables and deploy code that uses them to non-D365 boxes.
But this is not what you should be doing. You should be shifting your development effort towards extensions, so let’s take a look at what we have there.
All Extensions “v1” development is done in the classic Development Environment and when building the “v1” .navx file you can naturally use the DotNet variables and select types either from .NET Framework assemblies or your own custom assemblies. However (and a big one at that)…
If you are targeting D365 with your “v1” extension, then you must only reference the approved (whitelisted) types and namespaces from the .NET Framework library, and you may only make your own assemblies a part of the .navx file if your own C# code references the approved types and namespaces. If you directly reference a non-approved (blacklisted) type (for example, types from the System.Reflection namespaces) then Microsoft may reject your extension during the validation process. So, you can still use .NET interoperability, but only for “safe” (supported) things.
Which types and namespaces are unsupported, and which aren’t? It’s all explained in the Appendix B of this document: Develop the technical aspects of your app. The wider context of the entire validation process can be found here: https://docs.microsoft.com/en-us/dynamics365/financials/about-develop-extensions
When it comes to building “v2” extensions using VS Code, then the situation is plain and simple: you cannot use the DotNet type. It’s terrifyingly simple, in fact:
As long as your code uses a DotNet variable, you cannot compile it. End of story.
And you should not really hope for a big change to happen here, because it in all likelihood won’t. This is an intentional decision by Microsoft, and not some not-yet-developed-but-still-on-the-table feature that you keep your fingers crossed finds its way into RTM. It is as much off the table as it can possibly be.
Well, first of all, you can come to terms with the fact that as far as Extensions “v2” are concerned, .NET interoperability is gone, and is gone for good. And trust me here: it hurts Microsoft as much as it hurts you. Remember, Microsoft did not remove .NET interoperability because there is an evil conspiracy to annoy partners, and they are now secretly toasting to the cunningness of the idea. No, not by far. The .NET interoperability was probably the most important addition to the development stack ever, and Microsoft is fully aware that removing it will hurt a lot, and that it will hurt partners who won’t be able to achieve everything they could, and that it will hurt Microsoft who will have weaker technology integration across their own technology stack, as compared to what they had before.
Why did they do it, then? They did it because they absolutely had to.
.NET, while extremely useful, is extremely dangerous when being completely open in an environment such as D365. While everything is running on your box, there is not much concern about the .NET code you will run. But when it comes to running your .NET code in Microsoft’s own backyard, in D365 infrastructure, it becomes very difficult to isolate your code in such a way that it can run safely both for you and for others, while at the same time being stable and perform fast.
Consider this: in D365, it’s not just your app that runs. It’s the base app and hundreds, perhaps thousands of other apps, randomly installed by D365 tenants. A malicious app could attempt to pull sensitive data from other tenants. Or it could intentionally try to bring the server down. That part can (somewhat) easily be controlled and malicious apps are less of a problem. It’s the poorly engineered ones with sloppy code that could pose a much higher risk: your badly written .NET code could consume all the resources on the server, it could attempt invalid access to the file system, or do a number of things that make the NST hang. When managing C/AL code, the granularity at which you can manage it is user sessions, you can end individual user sessions and solve the problem. However, with .NET code, the granularity at which you manage it is NST – once an assembly is loaded, and goes berserk, you must restart the NST to fix the issue, and this is unacceptable, because there may be hundreds of tenants using the same NST in D365, and you must not cause downtime to them.
All in all, it would have been mighty difficult for Microsoft to enable us to keep using .NET without exposing them to all the risks that come with having an open architecture that allows you to run your own .NET code in there. They could have easily spent their entire VS Code or Extensions “v2” budget just trying to keep this alive, and they would still probably not be able to do it in a satisfactory way.
So no, don’t hope for the moment when Microsoft comes to their senses and decides to give us our .NET back, because it’s not going to happen. And again, Microsoft is not happy that it has to be the way it has to be.
And no, I am not trying to sell this to you as “an amazing new opportunity”, like a rookie marketer, no… This is crap and I hate it and oh how much I’d have loved if it hadn’t come to this.
But the sooner you make peace with the fact that you won’t have .NET interoperability in “v2”, the sooner you will able to move on and see that the world is not really that black when you cross this hill.
I am not saying it’s going to be all pink; I am merely saying it is not going to be as black as it looks.
You know, Microsoft is neither naïve, nor malicious. They understand two things: we all (Microsoft, and the entire D365 partner ecosystem) are in the same boat; and we either all succeed and win together, all we just all sink to the bottom together. There is no scenario where Microsoft survives, and the partner channel perishes (at least as D365 goes), nor is there a scenario where partners survive, and Microsoft goes down (again, at least as the D365 business is going). The thing is: very few people need a vanilla ERP, or at least vanilla NAV. D365, in its pristine vanilla flavor is still both too complicated and too generic to be usable directly out of the box. Very few companies are happy with what they can get out of the box, and NAV was never a success because of what it could provide out of the box, but because of high flexibility which allowed high degree customizations which in turn could enable achieving high degrees of fit. Degree of fit D365 for Financials provides to a company using vanilla D365 is too low to be compelling, certainly at the price level where it is (and will be, unless you can once get it for free). The only way customers will be satisfied with D365 is if the apps and solutions provided by partners (us) provide end-to-end, deep vertical support for industry-specific business processes.
That said, for us all to succeed (not just for Microsoft to succeed) we must be able to write those compelling vertical apps and populate the App Source with many (preferably vertical) apps as possible as soon as possible.
And trust me, Microsoft is aware that their decision to remove .NET interoperability from Extensions “v2” stack is not going to make it easier for us to provide those apps, but a great deal more difficult.
So, they’ve decided to make things – those that used to be possible only through .NET interoperability – possible in other ways. Like, for example, giving AL language-level support for them. This has resulted in the providing the support to invoke RESTful web services directly from AL, with built-in AL types, rather than having to go through an interoperability layer. So now you have HttpClient, HttpContent, HttpHeaders, HttpRequestMessage, and HttpResponseMessage types available as AL types. Declaring them and using them is much simpler than it was with their DotNet equivalents. The same has happened with AL support for JSON. Since most RESTful web services simply return JSON, you now have JsonToken, JsonObject, JsonArray, and JsonValue available as AL language-level types.
If you ask me, I’d trade DotNet equivalent types for these AL built-in language types any day. Interoperability is always clumsy. And even though you can typically get more functionality from .NET interoperability than you can get from a built-in type (because for interoperability Microsoft only has to expose existing functionality, where for built-in language-level support they have to specifically program all types and members to be consistent with the entire AL language), the simplicity and safety of using a built-in type (in my opinion) wins over more complex, and possibly less safe, interoperability types.
And the best of all is, Microsoft won’t stop at these nine types for HTTP and JSON that they already support in AL. They are also working hard to provide functionality to us for other areas of .NET that are as safe to use as anything can ever be, and that we need badly, but are now inaccessible. Imagine things like collections, more powerful strings and date/time types, regular expressions, encryption, things like that. Microsoft did not commit to delivering these, but as I said – they not only want to make our life easier; they need to make our life easier – so they are actively looking into how to provide support for those areas of .NET interoperability that we depended upon the most. And they are very open about it – they will gladly accept your input on that, through their AL language github project. If you need to support for some .NET functionality at the language level, don’t hesitate to navigate to http://github.com/Microsoft/AL and then ask a question in the Issues section. Microsoft will treat these as questions, not as feature request, and certainly not like bugs, but at least they will gain a better visibility into what it is in the .NET framework that partners absolutely can’t live with. Without us, that’s an impossible question for them to answer.
In the very worst scenario of all bad scenarios, you have some .NET functionality that will never be provided as a built-in AL-language feature so you cannot possibly hope to use it, and this makes it impossible for you to build your extension. If this happens to you, you are still not out of luck.
One way to solve your problem, which is both very simple and is the Microsoft-recommended way to go about it, is to use Azure Functions. They are very easy to develop and maintain, their performance is fast, especially in D365 because it also runs on the Azure stack, they are scalable, and they are not that expensive to run. And most of all – they can be written in C#, which means that your investment into developing custom .NET assemblies is not entirely wasted, and that transitioning from assembly-based C# code into serverless, cloud based C# code is going to be a fairly simple thing to do. As long as your .NET code was stateless, you won’t have any significant problems to migrate your C# code over to Azure, and even if it wasn’t entirely stateless, you can still retain state in Azure functions if you want to. The cherry on top is that you can invoke those functions from AL language directly.
As you see, it’s not exactly pink, but it’s not entirely black either.
As a matter of fact, I am excited about this new world, because it also opens up a lot of opportunities.
No, I am not. I believe every word I said.
For a person who had built a lot of .NET-based stuff targeting NAV, and then had to maintain all that stuff across various deployments, .NET was a mess. Making your assemblies available on every machine that needs access to them is not as simple as it looks in the help files and how-to videos. And your C/AL code is certainly less portable and less contained with all those dependencies to stuff very external to it. Any time you had to move a solution with heavy dependencies on .NET, you could expect problems. And no, putting the assemblies into the database was not the solution; it was merely a different kind of repository for assemblies, no more, no less (actually, less, in my opinion, because it did come with caveats).
Not even having the possibility of having those external dependencies is a very good thing for the quality, portability and maintainability of your AL code. When everything is in AL files, and nothing lives in external assemblies that have to be handled separately, it’s so much easier to maintain all your code, both during development and during deployment. And even when you use Azure Functions, which are obviously not “contained” in AL, they are not a complicated kind of a dependency – they are merely a web service out there. When you move the code that depends on those from one box to another, there is nothing you have to do with the Azure functions specifically.
To wrap this up, if you don’t care about extensions, and you believe you never will, then you have nothing to worry about as far as .NET goes. You can continue using it happily ever after for as long as there is classic Development Environment available, and very like even into the foreseeable future.
But if you care about extensions, you should abandon the .NET stack even if you are firmly in the “v1” boat. “V1” will be gone come winter, and then – if you still have DotNet variables around – you’ll suffer. You should get ready. You should start replacing your DotNet variables with built-in AL types where you can, and you should let Microsoft know about which types you need where there are none yet in the AL language. And you should migrate all your custom .NET into Azure Functions if there is no way you could live with that being simple and pure AL.
And still, if you are in the first group, the one that has nothing to do with extensions, and still believes that sitting happily on stair 1 or 2 of Freddy’s architecture staircase is a smart thing to do, you can benefit from moving away from .NET. Why? Because that way you are 100% future proof. If at any point Microsoft cuts the support for .NET altogether, even for on-prem development in VS Code when it finally arrives, you won’t have issues migrating your code from C/AL to AL. And if, at any other point, you decide to turn your solution – whatever it is – into a D365-ready extension, then you’ll be happy it contains no DotNet stuff in there.
One final note – seeing .NET being on its way out of the NAV technology stack hurts me personally quite a lot. If you have followed my blog, you know that I absolutely love .NET, that I have dedicated so many posts to getting the most out of this amazing technology integration, which has always left quite a bit to be desired, but has still been an indispensable part of our arsenal for the past 8 years. But as I said in my last post, progress often requires you to take a step back so you could make a big leap forward, and I see .NET departure as being one necessary step to make AL a beautiful language it deserves to be.
The post State of .NET Affairs appeared first on Vjeko.com.
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.
When Motorola built its first mobile phone in 1973, it weighed 2 kg. The first commercial version that followed ten years later weighed 0.78 kg, could muster 30 minutes of talk time or 6 hours of standby, and cost nearly 4.000 US$. Adjusted for inflation, it would be like 9.500 US$ today. Not to mention that there was virtually no network coverage. A landline phone was nearly infinitely better: you could talk as long as you wanted without ever having to stop to recharge, and it was available everywhere. You even had a payphone on every corner.
Today, when I see a person using a payphone, I can only assume they are being told where to deliver the ransom money.
Both the cars and mobile phones proved to provide vast improvement over the technologies they set out to replace. But at the outset, it certainly didn’t look that way. When first cars and mobile phones appeared, horse carriages and the landline phones have had reached their peak potential already. The potential of cars, and mobile phones, though, immensely surpassed anything either Daimler Benz, or Motorola, could have imagined back in their day.
Thanks for bearing with me this far, because I now owe you a big explanation: what do cars and horse carriages and 2-kg mobile phones have to do with NAV and .NET?
When the AL Language extension for VS Code was first presented, to many people it certainly didn’t look like progress. Gone were the GUI (should I say gooey) designers, and suddenly everything was text based. With classic Development Environment, a non-developer could create a handful of tables with properly designed relationships, together with list and card pages, in literally no time. Suddenly, you feel like you require a computer science degree to be able to write code that creates all this, and it takes four times the time to achieve the same.
Couple of days ago during the session on the AL Language development using Visual Studio Code, a training participant said that Visual Studio Code was a huge stepback, and that using that tool feels like going back to stone age.
Is this what progress is supposed to look like? Well, as a matter of fact, yes, this is precisely what progress looks like when it first arrives.
You see, progress does not look like this:
Progress looks like this:
And while the AL Language extension for Visual Studio Code at this point provides as much progress over classic Development Environment as the first car provided over horse carriages, these are the first steps only, and while the Development Environment had reached its asymptote a long time ago, Visual Studio Code provides vast potential for improvement over time.
Here’s why I believe the switch from classic Development Environment to Visual Studio Code is the best thing that happened to us in a long while.
To put it simply, Visual Studio Code is an open technology, classic Development Environment was as closed as a cannonball. So many aspects of VS Code can be customized to your liking, starting with color schemes, icon sets, and going all the way to automating it to your heart’s desire. Openness comes in many shapes and flavors, so let’s see.
They are insane improvement over the classic coding experience. They simplify creating larger blocks of code from repeatable patterns. Microsoft has provided a bunch of useful snippets already, but the beauty of it is that you can create your own snippets for absolutely anything. If invoking them through IntelliSense is too much of a hassle for you, then you can bind individual snippets to keyboard shortcuts.
One of major obstacles to developing NAV in multi-developer teams, but also a solid pain in that body part that I’d rather not name for political correctness, is the fact that classic Development Environment does not provide any at all source control capabilities. None. Zilch. Zippo. Yes, you can automate it using PowerShell, and there are amazing efforts by NAV community to provide this or that kind of process that looks like SCM from far, but none of these approaches are integrated, nor are they foolproof.
Visual Studio Code handles it hands down, directly from its UI. And if you are unhappy with how it does it out of the box, there extensions, a dozen a dime, that make it even better.
Oh, did I just mention extensions? Visual Studio Code is an extensible product that allows you to extend nearly every aspect of it. This is probably the #1 reason why it’s so popular. There are extensions for nearly anything you can imagine, ranging from language modules, compilers, to debuggers and source control management tools. There is barely any imaginable development task or language for which you won’t find support through a VS Code extension. As of time of writing of this blog post there are 3.266 individual extensions and they are popping up like mushrooms. There are more than 50 new extensions every week, and you can develop your own if you want.
Let me give you some ideas of things that could be meaningful tasks in NAV development.
For example, you could do simple things such as object renumbering, or organizing object files into logical folder hierarchy per object type. Why not automating validation of certain pre-defined rules or best practices, like variable naming? Or perhaps going berserk, and automating creation of list and card pages from tables. Or whatever other crazy *** (excuse my Valyrian) crosses your mind.
While there may not be an AL Language debugger yet, there is no reason why someone (khm, khm, Microsoft, khm…) wouldn’t provide it eventually. Once there is full support for AL Language, we may get a full-blown debugger that integrates with Visual Studio Code and provides some real debugging capabilities. Funny thing is, a millennium broke since NAV came about, and people retired after having spent a career developing for NAV, and yet we have never ever had a decent debugger. No, no, don’t get me started. The debugger integrated into the Windows client is not a decent debugger. It’s a very coarse approximation of a fuzzy idea of a prototype of something that kinda sorta looks like a debugger.
Should we have had Visual Studio Code seven years ago, and should Microsoft have invested as much time in developing a NAV debugger in VS Code as they have invested in developing the one we have today, we would have had a very decent debugger that would kick aaaa… that thing. But this last sentence doesn’t really make much sense, it’s totally hypothetical, but still. A man can hope, and I hope for an AL Language debugger integrated into Visual Studio Code.
One of the greatest things about the AL Language extension is that you can participate in its development. Simply go to https://github.com/Microsoft/AL/ and take part in the discussion, submit issues, ideas, or questions. Microsoft really follows the discussions there, much unlike they did with Connect (Remember Connect? Well, forget Connect). I have personally submitted four bugs and one enhancement idea, and not only they have all been accepted, but the average response time by Microsoft was a couple of hours, and for some of them it was practically instant. Amazing.
One more area where you can participate is submitting snippet ideas. Simply fork Microsoft’s repository, make your changes to the snippet definition file, and submit a pull request. There have been 44 pull requests, most of which were accepted by Microsoft. Amazing. (I am repeating myself, I know.)
Okay, I rest my case here.
I am really excited about the AL Language being supported in Visual Studio Code, and I am looking forward to the day when it’s the only development environment we have for our AL code. Until then, engage, and trust the progress curve. It’s inevitable.
The post Is Visual Studio Code really an improvement appeared first on Vjeko.com.