There is so much to blog about when you are a Dynamics NAV developer, it’s almost unreal and I can imagine that a lot of bloggers don’t know where to start.
I am in that situation and very fortunate to have found something to hold on to.
Many of you will remember the post on my blog How I fell in love with ForNAV and some of you might have seen some of the webinars I did for ForNAV.
I don’t work for ForNAV, technically they are my customer, but as with all my customers I feel as if I am part of the team. I guess it is the work situation I am most comfortable with.
You can follow the project here on GitHub.
As you know ForNAV is a report designer and most of the development work (actually all of it) is done outside of AL. Well, until now.
With the designer being finished we got a lot of questions to build reports that are optimized to work with it. This makes sense since ForNAV has a lot of controls that don’t exist in classic reports and neither in RDLC. So you can convert all you want but your converted reports won’t make use of the design patterns.
Also it’s a public secret that Microsoft did not do a whole lot of optimization to the reports after they have been converted from classic to RDLC and my are 20 years old from a design perspective.
The webinar that I did where I build a customer top 10 list in a few minutes is a good illustration of this situation.
Based on the situation the idea was born to create a set of reports which are optimized to work with ForNAV and follow the Dynamics NAV DNA about simplicity and design patterns and I got asked to make them. Go figure.
More important for you as a loyal reader of my blog, I got permission to blog about every step of this process. How cool is that?
Most of the blog posts that I wrote, especially the tips and tricks, are based on real life scenarios without mentioning the project I was working on.
Is this advertisement for ForNAV? Well, I hope so because it is a great product.
The list of topics that I want to cover is pretty wide. The project is going to be open source so we will start with Source Code management. I’ve decided to use GitHub based on experience and being impressed by the Microsoft AL project.
Our reports should work with as many localizations as possible from a single code base which means automated testing is mandatory. I don’t want to spend most of my time running reports and comparing them to test if the values are ok.
To do this we will use PowerShell, the Testability Framework and SQL Server.
I am going to leverage as many design patterns as possible. I’m also using reflection and polymorphism.
ForNAV works flawlessly with NAV design patterns and you will see a lot of them being used in reports and the NAV objects.
We are not going to touch existing code, yet we want to execute our reports and processes after you’ve installed our product. For this I’m going to leverage events and extensions. If you want you can install the product as an extension. This also means I will ship upgrade codeunits with each version which you can also use if you don’t install ForNAV as an extension.
One of the best features of NAV 2017 is the assisted setup, tooltips and general simplification. When implemented correctly this minimizes support and maximizes growth.
Implementing Notifications and Setup Wizards is not only useful when you want to go to AppSource, it is also useful when you want to create a highly repeatable solution that people can install on prem.
Last but certainly not least, all of the code will also be available in VS Code and the optimized AL language. I’ll investigate the conversion tool that Microsoft has announced for one of the next updates of the development preview.
Now I know that I am infamous for not finishing my blog series and I guarantee nothing.
You can however expect the first blog post this week, hopefully even two.