The ForNAV standard reports are in public preview. We have just released CTP2 and now we want to start testing them with Visual Studio Code. In order to do that we have to convert them to AL objects.

Microsoft is kind enough to provide tooling which you can find on the June update for the developers preview.

https://blogs.msdn.microsoft.com/nav/2017/06/20/nav-development-preview-june-update/

The tool is a small .exe file you can find in the same folder as your finsql.exe and called txt2al.exe. It is documented on MSDN.

https://msdn.microsoft.com/en-us/dynamics-nav/newdev-txt2al-tool

The tool takes a NAV txt object but it has to be exported using the MS-DOS command prompt using a special option.

Because it is a lot to write down I’ve actually recorded a 30 minutes video and posted it on YouTube. This video shows the commands, shows the differences in beyond compare and tells you how to make the tool run, test and put it on GitHub using a folder structure that makes sense. At least in my opinion.

Here is the video

And here is the text from my Convert.Bat file

finsql.exe Command=ExportToNewSyntax, File="D:\CAL\fornav.txt", Database="Demo Database NAV (10-0)", ServerName=.\NAVDEMO, filter="ID=70000..79999", Logfile=D:\Log_ExportFile.txt

pause

txt2al --source=D:\CAL\ --target=D:\AL\ --rename --extensionStartID 70070000

pause

One of the quirks of working with extensions is that you cannot run an object from the object designer. This is true for V1 and V2.

With V2 you can start an object (page) after deploy but this only works once and only in the WebClient.

If you just quickly want to check our a page or codeunit in the Windows client you can write a codeunit against an object that does not exist.

An example is the TowersOfHanoi app that Microsoft ships as example. This does not have a page extension to execute itself.

Works all the time.

Want to learn more about extensions? Contact me today!

Wizard pages are working on a revival from being almost forgotten. They were first introduced as form objects in Navision 3.0 as part of CRM. I instantly fell in love and started to create them for my own add-on.

Wizard pages have a few great advantages to normal pages and let’s go over them.

1. Save Button – Even though it is not called “Save” the Wizard page is one of the few options in NAV you have to populate data, validate it and cancel the operation without a hassle.
2. Overview – Essentially Wizard pages have fast tabs just like Card pages but the tabs are only displayed one at a time giving a clearer overview
3. Validation – Wizard pages allow the programmer to clearly validate the contents of each fast tab before continuing to the next fast tab. Much more precise than normal database validation since with a wizard you can asume, program, for a really specifical order of entry.
4. Explanation – On each page (tab) of the wizard you can write half a bible explaining to the user what to do. Be careful not to over do it since people these days are not used to sit down and read text anymore.

Almost lost

We almost lost wizard pages when Microsoft introduced the Role Tailored Client. There are only a few of them in the standard Application and the ones that do exist were in a part of Navision that Microsoft could not care less about since someone in Redmond had this briljant idea of replacing NAV CRM with Dynamics CRM which resulted in the name change of our module ro RM.

Fortunately for us some large partners had quite a few wizards in their ISV solutions and Microsoft “hacked” wizards in last minute using the Navigate page type.

Then we almost lost them again with the introduction of the Web Client. Again the Navigate Page was outscoped and the “Navigate Page” was changed to a Worksheet leaving only wizards as Navigate Pages.

Are you still with me here?

Now as part of the Saasification (a word that I hate) of NAV they are back and as always Microsoft is talking about it as if they’ve invented the freaking wheel, but they are over a decade old and the design pattern has not changed. Another proof of how smart the “old” patterns of NAV are and their validity.

Enough Navision history, get on with it…

For my ForNAV App I also wanted to make a Wizard page, just to prove how easy it is to make them and to be able to write this blog. I also firmly believe that wizards have nothing to do with “Saasification” but should be a normal part of any ISV solution.

Step 1 – Copy with pride

Wizard pages are suprisingly simple. The page itself is built on the table that you want to populate with the “SourceTableTemporary” property set to yes.

This gives a few restrictions. You cannot just build a wizard page on any table since many of the normal NAV tables have code in Validation triggers that assume you are doing something for real. If this is the case, or if you have a more complicated wizard you can make a decidated table and use that for your wizard.

DO NOT ABUSE TABLES! I cannot stress this enough. I tell it in every patterns class that I teach. Never, ever abuse any table as temporary table. Even for bespoke customer scenarios just create new ones. They are free, because Microsoft won’t check the customer license. We are not writing data to SQL.

For my wizard page I’ve stared with the Email Setup Wizard page (1805). This is a two step wizard page that has the base plumbing you need and if you copy it you make your life easier than starting from scratch.

Step 2 – Clean Up

The next step is to change the SourceTable property to your table (ForNAV Setup for me) and clean up the fields you don’t need. There is a bunch of stuff you don’t need and the compiler will help you find it.

After this step you should have somthing like this:

You now have a clean wizard with two steps. The images are already there but they only show up in the Web Client.

Step 3 – Change the descriptions

You need to change the explanations in the wizard. You don’t want your wizard to say, “Hey, welcome to email setup, let’s make it work”. You rather want something like this:

Step 4 – Change the code

You need to write C/AL code, which is cool, because C/AL is a great language.

First of all, you need to read the current values so the user get’s a headstart.

And you need to comment out some code temporarily until you’ve figured out what you want to do instead

Step 4 – Add your fields

In this step you need to add your fields and you need to decide how many steps you need. In my case two steps are fine, but the standard naming of the two steps in the email wizard are specific so I decided to simply rename them to Step1 and Step2. This allows me easier to copy and paste stuff to next wizards and makes the pattern more repeatable.

In my case I have two fields I want to setup

Step 5 – Add other stuff

In case of the ForNAV App I also want to change the values in the Report Selection so the Sales Invoice changes to the ForNAV Sales Invoice. This is an optional step although it does not make a lot of sense not to do it.

To add this in the wizard I need to create a variable and put that on a step

Step 6 – Finish and Store

The last step is to store the data in the real table and execute aditional code. In my case I need to replace the reports when this option is selected.

Off course, ReplaceReportSelection is a method of the Setup table, and those of you who were in my workshop will know that (TRUE) means HideDialog.

Step 7 – Assisted Setup

Wait, you said that Step 6 is the last! True for this blog, but you can also connect your wizard to the Assited Setup for Dynamics 365. This will be another blog.

The Result

The result is a nice step-by-step wizard that allows you to easily setup the App with some guidance.

Connect it

In my previous post I’ve created a Notification and I want the notification to run the wizard. I also want to run the wizard if somebody imports the fob file and runs the report from the object designer.

Lastly I want to have a default setup so I don’t want to go through the setup each time I do some playing around.

For this I’ve created an interface codeunit that I can run from everywhere. It asks me if I want to use default values or run the wizard.

This Codeunit I run from each ForNAV report and from the Notification.

Wizard Pattern

So here you go! You have the wizard pattern. Enjoy! Any feedback is appreciated.

This afternoon (May 2nd 2017) we are hosting a webinar with NAV-Skills about the Testability Framework. Luc van Vugt will be the presenter and I will do an attempt to moderate.

The testability framework has been with us for a long time and was introduced in one of the last versions of the classic client. Even though it has been with us that long it never got widely adopted either internally by Microsoft and the partner channel.

Until now.

With NAV2017 Microsoft seems to have found a formula that works to ship their tests (18.000+) and partners are looking at how to implement them into their own solution.

This week there was some discussion on Twitter on the testabilty framework. Let’s look at some of them.

So there seems to be a general consensus on the value of the framework.

How to start

One of the questions I hope Luc will answer today is how to get started. What surprised me a little at start was that most of the MVPs seem to have started with the Microsoft tests while I started to write my own test not looking at what Microsoft did and it made me question my approach.

I think the answer can be found in what type of solution you have. Are you making changes to the existing NAV code or are you programming sollely on top of the application.

Recently I’ve created the ForNAV Navision part and I created a test codeunit to verify if the code works and this test codeunit saved my ass a few times already. But for this app I did not touch any of the standard code or influence the standard flow.

What I advise to partners, when they ask me, is to run the standard Microsoft test but not to make changes to it. Once you start changing the Microsoft test codeunits you have to maintain your changes.

I hope after the webinar this afternoon that this was good advise.

If you write your own code as isolated units you can write your own tests against it which is why it is called unit testing. The standard Microsoft code is not written in a modern way but written tightly integrated like everyone did in the 1990ies with ERP applications. This is why the Microsoft test codeunits are sometimes hard to understand. The engineers who created the tests did a great job but their lives would have been easier when the standard code was more componetized.

The standard Microsoft tests should just work and are not to be touched. Write your own unit tests for your own units.

So I am looking forward to this afternoons webinar to see if it will change the way I think about the approach I have been following so far.

I’m building an App to work with ForNAV. If you haven’t you should read earlier posts first or watch the YouTube channel.

New Blog Series | Building the ForNAV App

Step 1 – Renumbering | ForNAV App Building

Notifications

The next step I will blog about is how to make notifications work for you.

Why Notifications?

Notifications are very useful when you want to ask something from the user without sitting on their face and be rude.

I am going to use a notification to indicate that ForNAV is installed but not yet setup. This can happen if people install the fob or if they activated the extension.

This will be the notification users will see:

To show this notification I have created 4 codeunits:

• ForNAV Notifications
• ForNAV Notification Actions
• ForNAV Initialize Notification
• ForNAV Notification IDs

ForNAV Notifications

Let’s start with the first and look at the code:

You can see I have an EventSubscriber that subscribes in my case to OnFindPrinter in Codeunit 1. Some people like to subscribe to Activity Pages of Role Centers but what if someone uses my App in a database with new rolecenters.

ForNAV is a report tool so why not remind them to setup when they do printing.

In fact, Microsoft should provide a generic handle for notifications like this.

Anyway, I throw a notification, but I don’t want to show the notification when the setup if already done, or if the user does not want to setup ForNAV and disables the notification.

The notification has an ID and two actions. “Yes” would be the prefered one or “No” if for whatever reason they don’t want to do the setup.

ForNAV Notification Actions

The Actions are handled in a seperate codeunit. The first action starts the setup process which uses a wizard. More about that in the next blog.

The second action checks if the notification exists in the MyNotifications table and disables.

ForNAV Initialize Notification

NAV 2017 has a table that stores notification preferences. This is table 1518 My Notifications and the Page that belongs to this table supports the “Discovery Event” pattern. This means I can hook into this page and “insert” myself the first time this is possible.

I can do this using the “InsertDefaultWithTableNum” function.

ForNAV Notification IDs

The last codeunit is a silly one, it returns the GUID as a string. This GUID is used in three different places in my code and I don’t want to change it in three places when I have to.

That’s it

Let me end with a teaser for the next blog, a Setup Wizard. This is what you get when you hit “Yes” on the notification.