Saturday, 26 May 2007
There is a magical time in a product’s life when it is perfect, and, for me, Dynamics NAV 5.1 is there. Having never used the product, I can unreliably inform you it is the best version of Dynamics NAV yet. The roles-based client is intuitive and a pleasure to use; the online help has been completely re-written with a focus on the roles within an organisation and the business processes that keep it running.
In a stroke of genius, Microsoft has completely re-engineered the application architecture in order to make all functions available to the NAV developer. Any actions that can be triggered by a user can now be triggered through code. This is probably the one non-feature I find most exciting. NAV developers can now create tools that will dramatically improve the Dynamics experience for re-sellers and end-users alike. The testing tool is a prime example of this. Similar to the Record Macro feature in Microsoft Office, it is now possible to record a series of actions, save them as a script (using your preferred language of C/AL, C# or VB.NET) and finally edit the code to produce testing programs. This will allow new features to be automatically tested to ensure they meet requirements and do not introduce nasty side-effects to other parts of the application. The application comes with a set of pre-defined localised test cases that allow Dynamics NAV resellers to develop their own applications and have total confidence that they have not broken the standard application.
Programming objects within Dynamics NAV can now be exported and imported through code (either using the built-in programming tools or via the web-service interface.) This, coupled with the fact that all programming objects are now stored internally in an open XML format, means that Dynamics NAV is now limited only by the imagination of the business community and the skills of the developers. Being able to hook into events makes it possible to write tools that will revolutionise version control within business applications. One of the sample applications illustrates this feature by waiting for customers to make modifications to their programming objects, and then sending a copy of the change to the Dynamics NAV Partner. No longer will we need to worry about lost, undocumented, or inappropriate programming changes.
These new features are available for a limited time only. Eventually, Microsoft will release Dynamics NAV 5.1 and my fantasy vapourware version will be replaced with the real thing, but until that day, I have the perfect ERP system.
Sunday, 20 May 2007
The symptoms of the problem are that the debugger for Dynamics NAV 5.0 (and earlier versions) launches but the code window is not displayed. On my machine this happened for version 5.0, version 4.0 SP3, 4.0 SP2, clean installs, you name it. The only thing I could do was close the debugger window, which caused the window to close and then be re-launched after a short pause (I figured this was because the program was getting to the next trigger. You can see similar behaviour if you close the debugger when it is working properly). I kept closing the window and eventually returned to NAV (giving me chance to turn the debugger off).
I logged this as a support issue with Microsoft but the suggestions they gave me (based upon previously solved incidents) didn't help. The premise of their suggestions was that the debugger and application communicate using TCP/IP and that something (most likely an anti-virus program or firewall client) was intercepting this communication and preventing the debugger from displaying the code.
After trying various options suggested by Microsoft, I finally got fed up and searched for the solution myself. I was quite surprised to find lots of people with the same problem - although there were a large number of postings from people that had either not found a solution or not updated their post. I think the best posting I found was on the dynamics user group (although I think the same solution was shown on MIBUSO).
For me the solution was to use Add/Remove programs from the control panel to remove a program called "Advanced Gateway Client". I don't remember installing this program and after I removed it the only difference I noticed was that my debugger worked again. Debuggered!
Sunday, 13 May 2007
In my previous post on this topic, I looked at the send to application feature in Dynamics NAV 5.0. I explained that you can send data from NAV to Word, Excel or any other application by using an XSLT template to transform the XML data into a format that the target application understands. I also introduced the WordprocessingML language that can be used to create Word documents as XML files – a feature that Microsoft introduced in office 2003.
In this post I am going to show you how to see what NAV is producing as the starting XML file before any transformation is applied. Then we'll look at the WordprocessingML schema and create a simple Word document using Notepad. If you want to see the results of your efforts, you'll need Word 2003 or 2007 installed.
The first thing I wanted to know when I saw this new feature was how it worked. I understood the concepts of XSLT and WordprocessingML and applying transformations to XML files but I had never done it in practice. I didn't know what NAV was giving us to work with. In order to be able to make my own transformations, I needed to first know what my starting point was.
XSLT is a language that can be used to transform an XML file from one format to another. I knew that I could load my own XSLT file as a template for NAV to use but I didn't know what my starting XML file would be. I would like to pretend I am some kind of XSLT guru, but the truth is I just asked some people at work. My question was "what do I need in an XSLT to make my output file a copy of my input file?" The hardest part was convincing people I was not crazy and listening patiently as they explained that there was no point in applying a transformation that would make the output file identical to the input file. I think the answer ultimately came from a Google search – but it helps to know what you are looking for.
Open up Notepad and enter this text:
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
Now save the file as "Copy All.xslt".
Since the file is so short, I will give you my expert explanation of its contents. The first line is probably really interesting. All I know is you need it - so put it in there for all of your XSLT files otherwise they won't work. It's something to do with defining this document as being a stylesheet and indicating that anything that starts with xsl: in the document will be defined in the schema that is referenced by the namespace provided. Incidentally, if you paste the http://www.w3.org/1999/XSL/Transform URL into a web browser, you'll see a link to the XSL Transformations specification. If you really want to learn about XSLT this is probably a good starting point.
The second line says find the start of the file you are reading.
The third line says copy everything without changing it.
Lines four and five are the closing tags for lines two and one respectively.
Now we have our transform, let's look at applying it to NAV. First we'll set up a new application to handle our transform. We need something that's good at displaying XML files – so I decided to use Internet Explorer.
Select Administration > IT Administration > General Setup > Launch Applications. The Send-to Programs form is displayed showing two programs: Excel.exe and Winword.exe.
Create a new record and enter IEXPLORE.EXE as the executable and Internet Explorer as the name. Press Esc to close the window.
Now I want to import my new template and tell NAV to use Internet Explorer to launch the resulting XML file.
Select Administration > IT Administration > General Setup > Manage Stylesheets. The Manage Style Sheets form is displayed showing all style sheets that have been set up for the database (oops – maybe that should have been set up as data per company since your templates are likely to contain company logos – as Microsoft would say: "this is a reseller opportunity" meaning: "oops we stuffed it up – you fix it"). In the standard CRONUS company this will mean a default stylesheet for Word and Excel (common to all forms) and a few form-specific templates (Customer Card letter template, Vendor Card letter, etc.)
Before you can create a new template, you need to select either the Style sheets common to all forms or Style sheets for this form only radio button against the Show label. For this example we want to be able to export from any form so click the Style sheets common to all forms radio button.
Maybe you are thinking you can now create a new record in the list of stylesheets – but that would be too easy. Instead, you should select the Import option from the Functions menu button. The system will display the Import Style Sheet form. Use the assist edit button to open the "Copy All.xslt" you saved earlier or type the path and file name into the Style Sheet field. Enter "Copy All to IE" into the Name field. Use the look-up button to select Internet Explorer as the Send-to Program. Click the OK button to import the stylesheet. You should now see a new line in the Manage Style Sheets form and, if all has gone well, we will now be able to test it out.
Open the Customer Card and click the Send Options button. The Program Selection form is displayed. Select our new Internet Explorer program. The Style Sheet field is showing the first style sheet that can be used for the data we are exporting. If it is not the one you want, click on the field and use the look-up button to select a different style sheet – in this example you should have only one stylesheet set up for the Internet Explorer program. Click the Send button.
If all has gone well, you should now see Internet Explorer with a new xml file displaying the information from the Customer card. Take a look at our xml file. You'll notice that the first part just gives us a hierarchy of all the controls on the form starting with Form, then Tab Control, then Tab Page, then a mixture of labels and text boxes. After the controls, we see some other sections for Customer, WorkDate, Salutation, CompanyInfo, etc. This suggests to me that there is something funny going on. How does NAV know that these things are important? We'll look at how you can create your own custom content to the XML file in a later posting.
To wrap things up, let's take a look at a simple WordprocessingML file. In my next post on this topic, I'll look at how we can create an XSLT to make a Word document in a format of our design.
WordprocessingML is a neat language that allows you to serialise an entire Word document as an XML file. The majority of the file contains tags that start with "w:". The text is typically built up from paragraphs (w:p), runs (w:r) and text (w:t) elements.
Open up Notepad and enter this text:
Now save the file as "WordML Rocks.xml". Even though the file extension is xml, the file is displayed with a WordML icon. This is because of the progid="Word.Document" property. Explorer is looking inside the xml file to determine how to display the icon.
Double click the file and Word will launch and display a document with a single line of text.
That's all for now. If you want to earn bonus points, you could take a look at the XSLT templates used in the CRONUS company and the XML files they produce.
Wednesday, 9 May 2007
Dynamics NAV has this nasty habit of stamping the version number of the client program against the database. So the scenario goes something like this:
- You have a 4.0 SP1 Client and you (and all your co-workers) are accessing your database quite happily
- You install a 4.0 SP2 or SP3 client just to take a look at the exciting new features and fire-up the new client
- The client looks at your ZUP file and finds the server and database details you last used and tries to open the database
- The client puts up a message asking you if you want to upgrade your database to a new version
- You don't read the message and click Yes because that is what all users do - it's easier than thinking
- The client puts up a second message saying "I know you didn't read the first message, because no-one ever does, but are you really sure you want to upgrade the database?"
- You don't read the message and click Yes again
- The client lets out a deep sigh and proceeds to update your database
- You get to use the new client on the database and everything is hunky-dory.
- Your co-worker with their 4.0 SP1 client tries to open the database and they see a message: "This database has been upgraded to a later version by someone who does not read warning messages, you must find that person and taunt them."
I may have changed the wording on some of these messages slightly - but you get the gist.
What I didn't know was that, according to the Ian C who posted the response, if you are using a SQL database, all is not lost. There is a dirty hack - which I must say I have not tried out - in which you can edit the databaseversionno field on the $ndo$dbproperty table. I would suggest creating a new database with the correct client just to see what the version number is - in Ian's example he talks about changing the value from 60 to 40.
I actually tried to use this today (15th September 2007) and it sort of worked. I tried to change a 4.0 SP3 back to a 4.0 no service pack. When I changed the value of the databaseversionno field to 30 the database would still only open with a 4.0 SP1. Maybe I did something wrong. What I did do is make a note of the version number used for a number of different versions:
3.10A = 13
3.60 = 14
3.70 = 17
4.0 = 30
4.0 SP1 = 40
4.0 SP3 = 60
5.0 = 80
5.0 (Build 25653 known as Update 3) = 82
5.0 SP1 = 95
Thursday, 3 May 2007
Word springs into life with a new document (called “10000 The Cannon Group PLC – Customer Card.xml”), stored in your temporary file path.
The sample document is a letter formatted to contain a CRONUS company logo and address details, Customer Address Details, Today’s Date, Salutation, etc. There is a place for you to type your letter contents.
Close Word and return to Dynamics NAV. Now hit the Send to Microsoft Office Excel button (you could use the Ctrl+E shortcut).
This time Excel opens and we are looking at another xml file. There is one Excel sheet within the workbook for each of the tab pages on the NAV form. Each sheet contains a title, the caption for the tab and the labels and data values for each of the fields on the tab page.
From Office 2003 onwards, Microsoft provided the ability to save a Word or Excel document as an XML file using their WordprocessingML or SpreadsheetML schemas. The new feature in Dynamics NAV takes advantage of this by grabbing the information on the screen and generating an XML file which it then transforms into another format by using a pre-defined XSLT (a file that describes how one XML file should be transformed into another).
You can create your own XSLT files and load them into NAV so that they can be used to make transformations. You can even specify your own applications to handle the new file, so you are not limited to using only Word or Excel.
I have two issues with this new feature. 1) Creating the XSLT file is not easy. If you have the ability to do this, you could probably have written some C/AL code to create the Word document directly. 2) Why would you use this feature? I am really struggling to think of a situation where this would be useful. If anyone has any suggestions, I would like to know.
I could only think of one possible use for this: if I wanted to write a user training document or document a test case and I wanted to list all of the fields on a form, this would be quite a neat way of doing it, but this is not a typical scenario for an end-user. Maybe I am not thinking laterally enough.
In the next post on this subject, I’ll take a look at how to set up a new XSLT so I can see what NAV is giving us to work with. Then, I’ll look at creating a Word document from scratch by making a new XSLT for WordprocessingML.