Not too long ago, one of my customers had an issue with the RTC that we needed to debug. Instead of using the Visual Studio debugger, this customer was used to reproducing the problem in the Classic client, and debug the process there. The perception was that running the Visual Studio debugger was very difficult, and they would not be able to read the C# code. I showed them how easy it is to enable the debugger, and how the C/AL code is always part of the C# code in the form of comments. As I was talking to folks at NAVUG Forum and Convergence, I was very surprised to hear that even seasoned NAV professionals are still not using the Visual Studio tools.
The information about how to use the debugger is available here in MSDN online, and it has been discussed many times in the online forums. Since I’m a visual learner, I decided to make a YouTube clip that shows you how to enable the Service Tier for debugging, and how to attach the Visual Studio debugger to the server process.
In NAV 2013, Microsoft has introduced some very nice new features to make designing Page objects for the RTC much easier than we were used to in NAV 2009.
Remember the good old days, when we had a wysiwyg designer for the Form objects, and we could put anything we want, anywhere on the form? This made for some really ‘creative’ (ahem) solutions, but essentially we were used to having complete control over the look and feel of the forms. When the RTC was introduced, we got the first step into a completely independent display target. Instead of defining x and y positions, display elements are now defined by metadata, and the display target should then be smart enough to interpret the metadata when the object is rendered. The intention was to ultimately have a situation in which it doesn’t matter where the page is displayed. The page object itself can be identical, and the display target then decides how to display certain elements based on the capabilities of the display target. For instance, the RTC displays exactly the same page as the Web Client or the Sharepoint Client, they just display the same page differently.
Unfortunately, when all you see is metadata, developing Pages becomes a very abstract exercise. Since there is no direct connection between the development tool and the rendered object, what we had to do was save the object, and hope for the best from there. We had to actually run the page to see what it would look like, and finding individual elements was a very painful thing to do. Lucky for us, the NAV team in Denmark cares a great deal (a GREAT deal) about what we think of the product, and they are VERY proud of the tools. When they were receiving many complaints about the Page Designer, they decided to enhance the development experience in NAV 2013 and address some of the most-frequently-complained-about issues. In my opinion the result is a HUGE improvement over NAV 2009.
What I want to do is focus on two new capabilities in the Page Designer. The first one is the ability to preview the Page right from the Page Designer, without saving the object first. My favorite feature of this capability is that there is a link between the ‘metadata designer’ and the ‘page previewer’. When you click on an element in the ‘metadata designer’, it is highlighted in the preview, and vice versa. You can see a rendered version of the metadata before saving it, and have a visual clue of what you are doing. The second (there is an ‘A’ and a ‘B’ here) is the ability to add columns to the Page object, through a Grid Layout and/or a Fixed Layout. These two new types of group elements make it possible to display multiple columns on the Page.
The NAV 2013 online help has a lot of good information about Page design, with walkthroughs and other tutorials. I’ve created a YouTube video in which I take you through the various screen elements of the NAV 2013 RTC, and then into the Page Designer to show you these new capabilities. I hope you’ll enjoy the video, and hopefully you’ll feel a bit more confident in using the Page Designer.
We’ve never had a debugger quite this powerful and versatile. Debugging NAV 2013 is Easy!
By nature I am a pessimist. In any situation I tend to look for problems and point them out to everyone. Since my goal of pointing out the problems is always to SOLVE them, and leave the situation in a better state than I found it, I personally consider my natural pessimism a very positive attribute. One of the things that feeds this pessimism is previous, similar situations. One example of such a situation is the release of a new version of NAV. When this happens, the NAV developers are always hoping that the tools have improved, and for well over a decade, one especially sore point has been the debugger.
When I first started as a Navision developer, version 2.5 had just come out, and most of the customers I worked on were still on earlier versions. The debugger in those days was TERRIBLE. Even then, coming out of a job as a VBA developer, I knew that there were much better alternatives, and I was always surprised just how bad the debugging experience in Navision was. Granted, there have been significant improvements since the 2.5 days, but the worst day in NAV development history surely must have been when NAV 2009 came out, and the only way to “debug” the RTC was the workaround with the Visual Studio debugger (see this video on how to make that work). Given all of these previous experiences, let’s just say that I was realistically pessimistic for the NAV 2013 debugger, and my expectation was actually a continuation of this downward trend ;).
As I’ve said many times before, the NAV team actually cares a great deal about the development experience, and for years they had been wanting to address the development tools. They were well aware of the problems, but the priority to do anything about it was always too low to make it into a new release. With the discontinuation of all the Classic components, however, this changed and there finally was ample priority for a new debugger. The results of years of very hard work are very impressive, and in my opinion the NAV team has delivered something that is well beyond anyone’s reasonable expectations. The new debugger is a great tool, one that gives the NAV developer a lot of flexibility. Not only can we break into any type of session on any Service Tier (given the proper setup), we can even change the appearance of the debugger, and customize it to our own personal preferences.
This is another one of those things that I’ve been very anxious to share, and I am very happy that I finally had some time to put together a YouTube video and write this blog entry. Please enjoy the debugger, and I hope you are as happy with it as I am.
With NAV 2013, Microsoft has added the capability to expose data from your NAV system as OData Web Services. Where that differs from regular Web Services (which in the NAV Server management snap-in is now identified as ‘SOAP Services’), is that OData only exposes data feeds, and within the context of Dynamics NAV is read-only. Click here to read all about OData, and here for an overview of OData in NAV 2013.
I’ve put together a new YouTube clip to show you where to find the OData Web Services in the NAV Server Management tool and the Web Wervices table from the RTC, as well as a couple of examples of how to consume them. As you will find out fairly quickly in this video, I have a LOT to learn about OData. I wanted to share what I do know though, and give you an idea of where to start looking.
This provides a new way to expose data from NAV, in an industry standard way, although I am sure that true OData experts will find missing pieces. It is another possibility for us to expand the reach of the ERP application that we know and love. I hope you enjoy the video, and that you will be inspired to start learning about it, and maybe even get some ideas about how to use them for your business.
After reading this blog and watching this YouTube video, you should have enough information to start figuring out how to use XMLPorts to import flat text files, even when this file contains data for multiple tables.
When I first got started as a NAV developer, I was assigned a senior whose job it was to educate me about what it takes to be an effective NAV developer. Whenever I had a question he would always challenge me to figure it out myself, while maybe giving me a tiny little push in the right direction. At first I thought that was very annoying, but it forced me to develop what is probably the most important skill as a developer: the skill of “figuring out how stuff works”. Once he was satisfied that I had spent an adequate amount of time and brainpower to a problem, he would take the time to give me a lesson. Sometimes he would make these lessons up on the spot, because he had to figure it out himself. Those lessons are my favorite memories of my time learning how to be a NAV developer, and oddly enough most of them weren’t even about syntax or objects, but about “how to figure stuff out”.
Every day, I make my rounds through the online communities, in search of questions to answer. Sometimes, I find a question that makes me wonder myself how something works. When this happens, I take a standard NAV database, and spend some time in the evening hours to figure it out. The past few days there’s been a question about how to import data for multiple tables into the RTC from a flat file, using an XMLPort. Now, at ArcherPoint all the developers attend a weekly conference call, and one of us presents a technology, or some tips on how to do certain things. We had recently held one about XMLPorts for the RTC, so I felt confident that this one would not be too big of a problem for me.
While my wife took my daughter to dance class, I worked on a couple of XMLPorts for the RTC, to import Purchase Invoice information into NAV. The YouTube clip below describes the results of those efforts. Hopefully this will help you understand how this works.