Another NAV TechDays are behind us, and as always, this one was a blast, too. So many people, so much enthusiasm, such great energy and positive vibe, no wonder Luc fills up the conference to the last seat every year.
Last year it took me nearly a month and a half to find time to sort my materials and publish them on my blog, and I won’t let that happen again. So, while waiting for my flight back to Zagreb, I decided to be productive, rather than just get lost in something on my Kindle, so here it is.
I won’t be publishing the slide-deck directly, as Luc will soon publish both the slide deck, and the session recordings on Mibuso and YouTube, so you’ll be able to get your hands on that part. What I am publishing, though, should be quite enough for you to get your hands on my Azure Functions demos:
- https://github.com/vjekob/TechDays2017 – repository containing the .NET bits for image manipulation demo I presented, together with the source code for the Azure Function that consumes it.
- https://github.com/vjekob/TechDays2017AL – repository containing the AL app source code that “trust me, it works” on the latest Docker-based build of NAV 2018 “Tenerife”. This repo contains the FOB file of all the C/AL changes that were a part of my presentation.
After the session completed, Waldo told me that the one thing he learned from me in this session was: “trust me, it works” Apparently, he was a good pupil, because he used the line as many times in his session, as I did in mine Well, admittedly, I said it too many times during the session (once being already too many, and I believe I’ve used the line three times in total). Well, what else should I have said, when things that do work just don’t happen to work in front of the big audience. While I do hope you learned more than that line from the entire 90-minute session, here’s what went wrong.
My first hunch was that what went wrong was Docker. Perhaps NST, running from within its Docker container, couldn’t talk to a port opened locally, but that couldn’t have been the case because when I attempted to access my local Azure Function through Chrome, everything still seemed stuck. So, the culprit was something else.
Then I got a hint from my friend Bart, who said that the problem – in fact – was that I had an active selection in the command prompt window started by the Azure Function local demo environment. Apparently, if you select anything in the command prompt window in which the local Azure demo environment runs, all threads hang, until the selection is taken away. I have just tested that claim and can confirm it – when there is no active selection, everything works fine, but as soon as you select anything, everything stops.
Now, I did select in that window, because I was copying the function URL out of the window, but the selection must have gone away the moment I pressed Enter. However, I managed to repeat the problem just now by simply clicking in the window once, which selected a single character in there, and likewise made the Azure demo environment to stop responding. A stupid glitch to ruin a perfectly working demo. So – trust me, it works!
Another thing I failed to show because of the lack of time was that after the update by Git continuous integration, the function has truly changed its behavior. Well, you can verify it yourself at any given point of time, because I have decided to leave all my Azure Functions out there for you folks to play around and try out. While there is certainly not much value in it, you can access them if you want to benchmark the performance of your network towards a specific Azure data center, so here are the endpoints:
- Australia: https://testtechdaysau.azurewebsites.net/api/HttpTriggerCSharp1?code=RNyieBaEwoG0MjTNeLkLQy0imoCEu9ZbEef5t8pZpEi1hgeHh9otUA==
- Ireland: https://testtechdaysie.azurewebsites.net/api/HttpTriggerCSharp1?code=SMgUp66yuNyuzcpOdNs2LfaVG/K7xPjp3c7Yf/V6BgBsWYuoNhzkOw==
- Netherlands: https://testtechdaysnl.azurewebsites.net/api/HttpTriggerCSharp1?code=mpdE9BonP62A0Tx70LgSiV8s9v6scLPUKdzbVxA/umx16AdS9EhgJw==
- Singapore: https://testtechdayssg.azurewebsites.net/api/HttpTriggerCSharp1?code=2ehKvo/BjREhyWHZsR48lGVdzDNmeGeIeShAwr9/eJb0qU3zsB2hYA==
- Central US: https://testtechdaysus.azurewebsites.net/api/HttpTriggerCSharp1?code=hreuIPCp1shCpEnYNF3pNQo5A9vcaBDCrMTbvV3tmEafC8UuCNPuew==
I will keep those endpoints alive for as long as nobody here decides to take a revenge on me and writes a script that causes any of these to actually cost me any money. So, gentlemen, and gentlegirls, please behave
For some other demos I was showing, Azure Portal was just painfully slow, and it still is today while I am writing this post, and there was nothing I could do about it. When you are demoing Azure while using Azure Portal, you must count on it not being the fastest thing in the world. Still, I hope you managed to get the gist of it all and learned about how good, and useful, and – above all – how easy to use Azure Functions really are. Good luck with Azure Functions, and – trust me – they work!
This Post Has 7 Comments
Blaming Docker??? 🙂
No way!!! 🙂
Of course, Docker works like clockwork. But yes, I was too quick to judge. So, Docker is acquitted of all charges, and I’ll be more careful next time not to click too much around the command prompt window 🙂
Wasn’t Bart the one telling you about the selection/freeze?
You are absolutely right. I corrected this. I sincerely apologise to Bart. Correct credit is given now.
Pingback: Trust me – it works! NAV TechDays 2017 Wrap-up - Vjeko.com - Dynamics NAV Users - DUG
Would it be possible to invoke a Nav soap webservice within a azure function?
For example PowerApps only support rest api so i would like to call Azure function endpoint in the app which will inturn call a navision endpoint for a codeunit.
Didn’t try it yet, but from all I know about Azure Functions, I don’t see why it wouldn’t be possible. But I’ll definitely try and check.