Blog

If you try exposing Page 5 Currencies as a Web service in Microsoft Dynamics NAV 2009, and then consuming this web service through a .NET application, you are almost guaranteed to encounter some unhelpful and generic XML errors that give you absolutely no clue about what exactly, where and why, went wrong.

Here’s an example of the error:

There is an error in XML document (1, 3634).

The error took me a while to debug and pinpoint the source, but in the end I managed to find a neat solution which I find worth sharing here, just in case somebody out there is scratching their had over it.

To catch a gist of what I’m talking about, publish page 5 as a Web service in NAV, and give it Service Name “Currencies”, then create a Visual Studio application, and add a web reference to the newly exposed web service, and name it NAVCurrencies. Then add these two lines of code:

Currencies_Service csrv = new Currencies_Service();
csrv.ReadMultiple(new List().ToArray(), null, 100);

You’ll get the error of the same species as above.

The error is obviously somewhere in the XML document that was returned by the Web service, but where exactly? After some plain XML querying of the Web service (thanks Freddy for an indispensable and priceless series about connecting to NAV Web services from different environments), I’ve determined that the XML is returned and parsed correctly by MSXML, which means the document is correctly formatted, so I was fairly sure at this point it was a data validation issue.

And it was so.

Somewhere in the XML document returned by NAV, there was a value of 1e-05, innocently sitting in a Unit_Amount_Rounding_Precision field. Gotcha!

So, NAV obviously formatted a value of 0.00001—a fairly common beast in the Currencies table, especially in the field Unit-Amount Rounding Precision where it is the default value—as a scientific notation (float) instead of a regular decimal number.

So, the error almost obviously lies far beyond anything a regular Joe could go about and fixing: you can’t just go and change the way the NAV Web service formats the value, and you can’t modify the way how .NET interprets the value. Or can you?

Actually, you can.

All you need to resolve the issue is to do a little hacking of the reference files created by Visual Studio at the point when you declared a web reference to the NAV web service. In Visual Studio’s Solution Explorer, click this icon (Show All Files), and expand all the nodes of the NAVCurrencies web reference. You should find two important files there:

• Currencies.wsdl, the WSDL definition of the Web service interface; and
• Reference.cs, the C# class containing the implementation of the Currencies Web service functionality

You need to edit both of these documents. First, go to the WSDL file, and search for Unit_Amount_Rounding_Precision. You should find this:

<xsd:element minOccurs="0" maxOccurs="1" name="Unit_Amount_Rounding_Precision" type="xsd:decimal" />

Change the type to “xsd:float” and save the file, this one is done.

Then, open the Reference.cs file, and search again for Unit_Amount_Rounding_Precision. There are two important instances you need to take care of:

private decimal unit_Amount_Rounding_PrecisionField;

and

public decimal Unit_Amount_Rounding_Precision {…

In both of these two instances replace keyword decimal with float. Save the file, and that’s it.

This in itself will not just magically resolve the issue totally – you are still probably need to take care of the fact that this property is now float, not a decimal, but in normal NAV usage it should not make any problems. The two biggest problems are that:

1. You have to repeat these manual corrections every time you update the Web reference in Visual Studio (which is required if you do any modification to the page object in NAV); and
2. You have absolutely no guarantee that this error is not going to pop-up elsewhere and suddenly, at which stage you will have to manually fix the Visual Studio reference (not to mention the fact that this error can manifest itself first only in production, and months after the project went live).

I truly hope this solution helps you and saves you hours of wandering in the dark.