Bug

A beauty of Web services is that they don’t need to care at all about who’s consuming them. Whether there is .NET on Windows, Java on Linux or some proprietary stuff on an iPad on the other end, they do exactly the same stuff.

Once upon a time, Freddy has delivered a great series on connecting to NAV Web Services from a smorgasbord of technology flavors. If you are a .NET enthusiast, like me, the obvious choice is to connect through the tools that are at your disposal in Visual Studio: the proxy classes.

Last Monday I’ve attended my second daughter’s birth, and then spent the week trying to relieve my wife as much as possible from anything but breastfeeding. As a matter of fact, I’d like to keep doing it, it was not only a great break from daily worries, but also a fantastic occasion to spend all the time available with my closest and dearest, which I am not sure when I will have next.

In my country, there’s a saying: “A good horse has a hundred flaws; a bad one has only one.” It’s bad. People have asked me why I am doing this, and if I hate Web services because I’m blogging about their flaws. In fact, I love Web services, and as I said in the first post in this series – they are great.

Soren has taught me yesterday that some of the bugs I encountered have been properly disinsected by Microsoft, so other than the workarounds I suggested, there is an option to apply the hotfix and forget about that one. Today, I’ll explain a not so critical bug, as the one yesterday, but depending on what exactly you do with Web services, it may be more than just a nuisance.

The bug with which I started this series is nothing critical. It manifests rarely, you can easily work around it. It’s in the “so what” category. But the one I’ll talk about today is a tough beast, with not-so-easy workarounds that cause as much headache as the bug itself. So, here comes bug #2: setting a date to 0D.

If something, Stratus has taught me how buggy the implementation of Web services in Microsoft Dynamics NAV is. Let me be clear from the onset: Web services are a great functionality in NAV, one of the best additions (together with .NET interop) to NAV stack in a long while. But it’s buggy.

It all started with Waldo and his Dynamics NAV 2009 R2 is not a “normal” release … beware! post two weeks ago . Waldo did not complain (much ), he explained what R2 is and what it isn’t, and it turns out that it isn’t many of the things people hoped it was.

A bug or a feature? Sometimes it’s hard to tell for sure. Web services are a fantastic tool in NAV, however, they do not always behave exactly as you would expect them to. There is one particularly annoying behavior, which just after you get used to it starts getting even stranger.

Design is one of a kind. Other phases in Sure Step are understood and accepted as good and necessary. But design, do we really do that? Is it really necessary? Who’s going to pay for it? Does the customer really need all those documents? Instead of writing documents, you could have it developed in the same, or less time.