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. They are a good horse. A winner.
The reason why I am doing this is because I want to share the problems I encountered over months of working with Web services intensively, as well as the solutions or workarounds I identified.
Today, on the repertoire we have another security-related glitch, which has been confirmed to me by Microsoft, but as far as I know there has not yet been a hotfix for this.
Bug #4: accessing Web services in multi-company scenarios.
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.
Hello, bug #3: accessing WSDL without database-wide permissions.
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.
Being buggy doesn’t mean it doesn’t work. It only means you need to twist and bend your code to achieve things which you would expect to work out of the box. During development of Stratus, we had to make a series of workarounds in Web services to achieve simple goals, and I decided to share those bugs (and workarounds) with you, to help you be more productive in your Web services based projects.
So, here we go for bug #1: lowercase codes in primary key.