If there wasn’t one already, someone should have invented Belgium. There are two things in this world that I love, and probably shouldn’t (and an oversized red speaker’s shirt I got from Luc today did a darned god job at concealing the unlucky consequences of overly indulging in both of them): beer and chocolate. Boy, do Belgians know their beer and chocolate!
But they know their NAV, too, and after NAV TechDays 2011, which have just ended in Antwerp, and two days of top NAV content, I can only say – great job, Luc and the team, and please make it a tradition.
If you attended my presentation about .NET interoperability, then there are a couple of demos I couldn’t deliver due to time constraints, and I promised to blog it. So, here we go.
It’s about streams. You already know that in NAV there are two data types, InStream and OutStream, that allow you to stream data in and out of generic sources or destinations. They are a fantastic tool, because they require you to know nothing about the type of source or destination, and you can store and retrieve data without having to care if the data comes from Internet, or a BLOB field, or is it written to a file, or transported over an XMLport. Stream makes it abstract and allows you to simply handle the data, and make the object itself care about the specifics.
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.