My Take on Using Docker

This past week, there was another post by my good friend Arend-Jan Kauffmann about using Docker directly on Windows 10 (what are you still doing here? Go read AJ’s post!). He had previously written about using Docker in a Hyper-V VM, and he has helped me understand how this all works a number of times. Just to be sure I mention this here, you can read all about the technical details on Tobias Fenster’s blog but that goes over my head very quickly.

The reason why I am writing this is because I am very reluctant to make the step to install Docker directly on my laptop. What works for me at the moment is where I have Hyper-V enabled on my laptop, and I have a VM with just Windows Server 2016 (creating one with Windows Server 2019 is very high on the todo list). My Docker is installed in a snapshot of that VM, and that is where I do all of my development work. I wrote about this before, read it here.

See… I am the king of screwing up my computer. If there is anything, ANYTHING, that will mess up my computer and render it absolutely useless, I WILL find it, and I will kill my computer (I am hearing that in Liam Neeson’s voice by the way). I have had to re-install my laptop so many times because of things that went wrong. When I have a problem like this in my VM, I don’t even spend any time trying to figure out what went wrong (that gives me a headache just thinking about it). All I need to do is delete the snapshot, create a new one, and I’m back up in a matter of minutes. All my dev work is in repos that I sync regularly, so I never have to worry about losing any work.

I’ve read about Docker straight on Windows 10, and it sounds very nice and easy to use. At the same time, I read blog posts and even Tweets that mention damage to the host OS from normal Docker operations, and I just KNOW that if I try it will happen to me. My reluctance to use Docker on Windows 10 directly does not come from wanting to stay in the past, but it is more from the knowledge that I’m going to screw up my computer.

Maybe I’m too cautious, but for now I will stick to my setup and continue to use Docker inside a VM. It works for me, and for now that’s good enough.

Translations for Business Central Apps

My struggle to get the new translation files right has been real and too long to recount on this blog. When I finally got it right, it felt like it was more of a coincidence than actual skill to finally get it done.

It started with the app submission checklist, where one of the requirements is to “include all translations of countries your extension is supporting”. The app that I was working on was targeted for the US market, so all I needed was a translation file for ‘en-US’. The page on docs that explains translations explained what I needed to do. Or did it?

Turning on the translation feature in the app.json file and replacing all ML captions and such was easy enough. The trouble begins when you run into the details.

As soon as you rebuild the app, VSCode generated the default translation file in a new folder called ‘Translations’, and the translation file will be called “<YourAppname>.g.xlf”. Because the development language is ‘en-US’, this generated translation file is also specified for the ‘en-US’ language.

The translation page on Docs specifies that you need to copy the generated file “to avoid that the file is overwritten next time the extension is built”. Each time that you build the app it will re-create the generated xlf file. What that means is that you need to make a copy of the translation file and use the copy to do your actual translation work.

So I did make that copy, and because I was working on a US only app, I felt I was done with my translation. I had the generated file in my workspace, I had a copy of it for the ‘en-US’ language, I thought I was good to go. Alas, the app submission failed because they could not find any translation file in my app. Something was missing from my translation file.

The generated file only has nodes for “source”, which comes from all of your text strings like labels and captions and comments and such. The translation itself is in a node that is NOT included in the generated xlf file, you have to create that. The name of this node is “target”, and this is where the actual translation goes for each source element.

So, I copied and pasted all of the source nodes, made target nodes out of them, and by this time I had a direct line to the validation person at Microsoft, who was willing to hop on a Skype call and look at my workspace. He was also surprised to see that my workspace DID have the translation file, while the app file that I sent to him did not. As it turns out, the target node needs to have an attribute called “state” with a value “translated”.

In order to get the translation file in its proper state, you should use the proper tool, and I found that the Microsoft Multilingual app toolkit editor is the easiest one to work with. It puts the right elements into the xlf file, and when I used that tool, my app file was finally accepted.

How Do I Videos

My company, Cloud Ready Software, was commissioned late last year to create some short ‘How Do I’ videos on how to accomplish a bunch of simple technical tasks in Business Central. In total we created about a dozen videos, and they were all published on the “Dynamics 365” channel on YouTube. This channel has a TON of video content about all sorts of topics related to Dynamics 365 in general. Business Central is actually not a main topic in this channel, they are mostly focused on Sales, Marketing, Operations.

Anyway, I wanted to put links to the videos that I recorded in a blog post, so it would be easy to find them. As a result of these videos, we’ve been commissioned to create 30 hours of real training material for Business Central. Yes you read that right… THIRTY HOURS!!!! That’s almost a whole week!!!! Unfortunately, these larger videos will be published in the Dynamics Learning Portal, which is a subscription service inside PartnerSource. You have to have PartnerSource access and also pay extra to be able to access those videos.

I’ve already brought up in an internal meeting that it would be really cool if those videos could be public, and I did not get shot down. I doubt that they will be though, but I will make it a mission to mention this at every step of the way. I’ll keep you posted. On to the videos…

The first one is an easy one, how to add a field in an extension:

Next, how to add a field with a foreign key relation to another table:

Next, how to add some AL code to an extension:

Then, how to add upgrade logic to an extension:

And finally, how to connect to a web service:

Extensions V1 vs V2

You might have heard people talk about “Extensions v2”, and maybe that doesn’t make a whole lot of sense. Let me take a few minutes and try to explain the concept to you.

Back in 2015, Microsoft announced the concept of extensions to us, in this blog post. I remember reading this article, and being thoroughly confused. At the time I was not in a technical role, and I had let my technical knowledge slip for just a minute it seems.

Extensions v1

For extensions v1, development is done in good old C/SIDE. There are severe limitations as to what you are allowed to do. For instance, you cannot add values to option strings in table fields, and you cannot add code to actions on pages. I won’t get into the details of those limitations, but you must be aware of what you can and cannot do for extensions, because in C/SIDE you can do a LOT more than what you are allowed to do.

The extension itself is compiled in a so-called .NAVX file, also know as a NAV App file. To get to this package file, you must use PowerShell Cmdlets to export the original and modified objects, calculate the delta files, and then build the .NAVX file. To deploy this .NAVX file, you then must use another set of PowerShell Cmdlets.

Especially the development part can be cumbersome. There are many things you are not allowed to do, and as you build the .NAVX file, the system will yell at you when you did something wrong. There are many moving parts, and it takes a lot of discipline to get it right

Extensions v2

For extensions v2, development is done in Visual Studio Code (also known as VSCode), using the AL Language extension. Since you are no longer working in C/SIDE, only the allowable things are allowed. You simply cannot do anything that the tool is not capable of doing. You no longer have to export original objects and compare them to modified objects. Essentially, you are programming the delta files directly in VSCode.

Deploying the solution works simply by building the project from VSCode. You hit F5 and VSCode will build the package and deploys it to the service tier that you specify in the launch file. Deploying the app to a test system still happens with PowerShell Cmdlets.

Hopefully this clears it up a little bit. Once you understand the differences, it’s not so intimidating any longer.

NAV Techdays 2016 Recap

This past week was the NAV Techdays event in Antwerpen. If you don’t know what this is, head out to their website and read the ‘About’ section. This year’s edition was I think the 7th time, and it was the first time that there were more than 1,000 attendees! In my opinion, this event is BY FAR the best technical event for NAV, head and shoulders above any other event, not in the least because there are two days of pre-conference workshops.

Last year was the first time I had gone to NAV Techdays, and after the truly exhausting three days, I was utterly satisfied and I promised myself that I would do everything in my power to come back every year going forward.

My highlights:

  • Pre-conference workshops. I had signed up for Black Belt Powershell by Eric ‘Waldo’ Wauters, and for Deep Dive into Events/Extensions by Arend-Jan Kauffmann. Both days were very intense, there was a TON of new information for me, and I was utterly done at the end of both days. The knowledge that I have gotten out of these two workshops will help me stay relevant as a technical person in the NAV world. These two workshops alone were worth traveling to Europe for.
  • Extensions related sessions – I made it a point to attend as many sessions about extensions as possible, since I believe it is the most important technological development in our industry this year. Especially Gunnar’s session about migrating to Events and Waldo’s session about Extensions Best Practices were eye openers
  • PowerBI and NAV by Steven Renders was absolutely INCREDIBLE. The sheer amount of information that this guy put into his session was just unbelievable. I bet he could fill two days of proper training about all the things that he showed us. Well done Steven!

I would have liked to see the sessions about Office 365 and the design patterns session, but I can’t be in two places at the same time. Lucky for me (and everyone else) Luc records all of the sessions and puts them on YouTube. He even puts the videos in individual playlists per year, for instance you can see all videos for 2016 here.

NAV Techdays is my favorite event. The sessions, the pre-conference workshops, the super-comfortable venue, the amenities, the production, the expo area, meeting my kind of peeps in person. It feels like this is “my” event, and I hope to be able to go each and every year from here on out.

Update 11/20/2016: Slide decks available here

Update 11/23/2016: Added links to YouTube videos

The Skinny on Extensions

Earlier this month I wanted to write about what’s new in NAV 2017, and my fellow MVP and good friend Eric ‘Waldo’ Wauters beat me to it. So, my next plan was to write something comprehensive about extensions. I am signed up for a deep dive workshop next month, and I want to be well prepared. Again, as I am collecting information, this guy publishes a large post about extensions, and judging from the title it looks like it was the first of three posts. So…. instead of doing the work myself, I waited for him to post number three, and give you the links in here: Part 1, Part 2, and Part 3.

I could try and say something intelligent about these posts, but I’d make myself look foolish. After the workshop I’ll have plenty to share anyway. Enjoy 🙂

Extensions! Extensions! Extensions!

Just a quick post today about something that is probably the most important thing to learn as a NAV developer, which is Extensions.

I remember going to an event where Steve Ballmer did the keynote. It was a technical conference, and he started his talk by almost screaming “DEVELOPERS! DEVELOPERS! DEVELOPERS!”. It was meant to make the people in the audience, who were almost all developers, like the most important people on the face of the earth. He kept hammering on the point that developers were THE MOST IMPORTANT to Microsoft, and showed us all kinds of evidence that this was the case.

This past year or so has seen a big push toward this new thing in NAV development called ‘Extensions’. Rather than modifying the base code of the product, which is what most of the NAV partner channel is doing for their customers, extensions allows you to create custom functionality without actually touching the base code itself. Coming back from Directions this year, it has become clear that Microsoft is ALL IN on moving NAV development toward extensions. My fellow MVP and good friend Eric ‘Waldo’ Wauters wrote about extensions as well this week, so I won’t bother repeating that part.

What I want you to know about extensions is that as a technical NAV professional it is essential for you to learn about extensions. Your ability to keep your relevance in this industry will depend on whether you are able to effectively use extensions to develop a custom solution for NAV. Apps for Dynamics 365 are only possible with extensions, but it might even become necessary to use extensions for on prem implementations.

I’m signed up for a full day pre-conference workshop at NAV Techdays this year, which will hopefully give me the necessary skills to get that started for me. What are you planning?