Wednesday, 6 June 2007

Dynamics NAV 5.0 - Send to Application Feature - The Continuing Saga

Did you ever start something and wish you hadn't?

I thought it would be fun to blog about Dynamics NAV 5.0. I thought it would be easy to write a short posting following the investigation of new features. Why oh why did I start with the send to application feature? It has turned out to be far more work than I had expected. Oh well...

First of all, I would like to mention that I have already written too many posts on this subject. You can see them all by clicking the Send to Application Label on this blog. I won't say how many there are because, no doubt, I will need to add more when I finally figure things out.

I think I should mention Mark Brummel's Reporting from TechEd 2007 posting in which he says:

One of the issues with the office xml interface is that the changing of the stylesheets is very difficult unless you like reading xml schema's.

Fortunately they have changed that and added a stylesheet manager that allowes you to create them in a wysiwyg way. Great! It will be released shortly but there is no official date.

If you have been reading my posts on this topic, you will know that you probably already have a wysisyg editor for the stylesheets needed to transform xml data to Word documents - that is - Word itself. The more I look at the results of using the wml2xslt transform inference tool and compare this to the example stylesheets supplied with NAV 5.0, the more I think that maybe this is not going to work - it looks as though someone really did code this sample stylesheets by hand. I still can't get elements from within the same node to appear in different parts of the document. If anyone has any ideas, please post a comment.

Now the reason I am writing another post on this topic is the changes I suggested making to codeunit 403 will break the standard stylesheets that come with the CRONUS database. Oops.

I have figured out a way to create the stylesheet without hacking the codeunit that also leaves the existing stylesheets in their current working form.

To start with - don't edit codeunit 403 to add the xmlns attribute. Instead, generate the Customer Raw xml file as described but then open the xml file in notepad and manually add the xmlns="NAV" attribute at the end of the Object opening tag.

Now you can follow the previous instructions for creating the Customer Seed xml file (although I still haven't figured out how to use same elements in different parts of the document.)

Finally, use Notepad to open the Customer Seed xsl file (the transform that is generated by the wml2xslt utility) and find the xmlns attribute for the "NAV" namespace. When I tried this, it was ns0 as follows:

... xmlns:ns0="NAV"

Use search and replace to replace all ocurrences of "ns0:" with "" (ignore the quotes so you are replacing it with blanks.) Save the edited xslt file and you're done.

You should now be able to use this xslt file to transform the NAV xml as required - and all your standard stylesheets will still work. Phew!

Monday, 4 June 2007

Dynamics NAV 5.0 – Send to Application Feature – Part 4

This is the last part of a series of postings on using the new send to application feature in Dynamics NAV 5.0.

In Part 3 I showed you how to use Word to create a seed xml document that can be used to create a transformation template. It was late in the evening when I wrote this and there were a couple of mistakes in the posting. I had implied that you could take the SalespersonName element from the Customer element and move it down to the bottom of the letter. Unfortunately when I worked through my own example this did not work (the XSL does not include the text as expected.) I am sure there is a way to do this but I do not know how. If you are reading this and you know about such things, why not post a comment?

In this post, I will show you how to create the XSLT from the seed document you created in Part 3. The first thing you need to do is download the transform inference tool from the Microsoft downloads site. The download will install the tool: a command-line executable with some documentation. I accepted the default install path so, for me, it was installed in "C:\Program Files\Microsoft Office 2003 Developer Resources\Microsoft Office 2003 WordprocessingML Transform Inference Tool\".

In Part 3
I wrote about creating a seed document. If you have not done that, you will need to go back and follow those steps before being able to use the transform utility. I am assuming that you have a seed document stored as “customer seed.xml”.

Open a command prompt and change directory to the location of the inference tool. Type the following command:

WML2XSLT "c:\customer seed.xml"

Since we have two namespaces in our seed document, you will see a dialogue box asking you to select the namespace you wish to use for the transform.

Tick the option for the namespace you put your NAV document in and hit OK.

Now take a look at the location where you stored your seed document. You will see a document with the same name but a with a ".xsl" extension.

The quickest way to test your XSL is to take your raw xml file and edit some of the data (try changing the customer name). Then save the raw xml file and open it in Word. When you open an xml file in Word, it prompts you for a style sheet to apply. Select the style sheet you created from your seed. You should now see a Word document that looks like your seed but with the changed data values from the raw file.

If everything is working properly, you can now import this style sheet for use with the send to application feature. For details on how to do this, go back to Part 1. Note that our transformation uses elements that are only available for the Customer card export, so when you import this style sheet, do it as a style sheet for form 21 only. You should also ensure that the application for the style sheet is Word.

That’s it. I don’t know if this is the best way of creating your XSLTs but it certainly works for me. The nice thing is that I don’t need to know the XSLT language in order to create the transform (which I think will be true for the majority of people that will need to create new templates.) I must stress that this series of postings is made with no warranty or support. If you follow this, you’re on your own. If anyone finds a better way of creating XSLT transforms for use with Dynamics NAV then I would like to know – please post a comment.

Sunday, 3 June 2007

Dynamics NAV 5.0 – Send to Application Feature – Part 3

This is my third posting on the new send to application feature in Dynamics NAV 5.0. After my initial introduction, my second post explained how to create an XSLT that would show the raw xml produced by NAV.

In this post I am going to show you how you can use a graphical editing tool (that you probably already have) to create your own XSLT. You will need the XSLT we created in Part 2 so if you haven’t read that yet, I suggest you jump back and start there.

I have read a few posts on this topic asking whether there are any tools that can help you create XSLT transformations without having to hack xml in a text editor. You may be surprised to learn that Microsoft Word (2003 or 2007) can be used to format your raw xml file to create a seed file and a transform inference tool (provided by Microsoft) will then create the XSLT for you.

There is one little snag (isn’t there always?) The transform inference tool (what a great acronym that makes ;-) needs the raw xml file to have a namespace attribute. Unfortunately NAV does not include a namespace attribute in the xml document it creates so the first thing we need to do is change the code that generates the xml so that this attribute is added.

Open up Codeunit 403 - Application Launch Management and press Ctrl-End to get to the bottom of the code. The third-to-last function is called AddElement and is used to add all of the elements to our raw xml file. In this example, I am going to use a namespace of ‘NAV’ – but you could use anything, provided it is not used by other XML documents (this is why you often see a URL in the name space.) Add a new line in the code so it looks like this:

ChildNode := ParentNode.ownerDocument.createNode('element', NodeName, '');
ChildNode.text := NodeText;AddAttribute(ChildNode,'xmlns','NAV'); // My new line to set the namespace attribute.

CreatedChildNode := ChildNode;

Now we get to the point where you’ll need the XSLT we created in Part 2. Hopefully you have this hooked up to export to Internet Explorer. I am going to create a new letter template to be generated from the customer card so, first of all, you need to export a customer record to give us our raw file. Launch the customer card (Sales & Marketing > Sales > Customers) and click the Send Options button on the toolbar. Select the Internet Explorer application and the Style Sheet we created in Part 2. Hit the Send button and you should see Internet Explorer launch with an XML document.

In the image, I have collapsed the Control element to show the Customer, WorkDate, Salutation, LetterBody, ComplimentaryClose, CompanyInfo, and DecimalSeparator elements. You’ll notice that the Control element has a different namespace to the other elements (it shows xmlns=“”.) This is because the Control elements are already in the DataXML document when our codeunit 403 runs so it does not get the xmlns attribute added by our line of code. Since we are only going to use the extra elements and not the control elements, let’s not worry about this.

I would expect there will be some changes to the way NAV creates this XML document in the future. As you will see, Word does not work very well with empty elements where the data is actually stored within the attributes. I would not be surprised if the Control elements are changed so that value attribute is actually the text of the control node rather than being an attribute. I would also expect that a namespace attribute will be added – but who knows? Maybe Microsoft has some other grand plan for making it easy for users to create their own XSLT transformations.

From within Internet Explorer, save the XML file as “customer raw.xml” and open the file in Word. I am using Word 2007 but I am pretty sure the same features are available in Word 2003.The first thing you will notice is a whole bunch of empty tags. The first time I saw this, I figured I was doing something wrong – until I realised that the values of the form controls are attributes and Word does not display the attributes in the Word document.

We can get rid of these Control elements. Double click the first Control tag and press Delete. You should now see the Object element with the Customer and other elements beneath it.

Now you can format this document how you want. Create tables, add graphics, etc. When you move data, be sure to copy all of the tags. For example, if you want to put the customer’s name, you would need to ensure it is still within the parent tags of Customer and Object.

Above you can see my re-formatted document. I find it easier to work with the format with the XML tags displayed. Then I remove the tags by removing the tick from the Show XML tags in the document. It looks like this:

Save your document in an xml format when you’re happy with the layout. In Word 2007, this means saving as a Word 2003 xml Document. Make sure you remove the tick from save data only. If you don’t remove this tick, your transformation won’t work. I find it easier to save my document with a name “customer seed.xml” as this lets me easily identify which file contains the raw data and which is the seed for my transformation.

That’s all for now. In my next post, I’ll show you how to take your seed document and generate the XSLT you’ll need for NAV to generate these documents for you.