.NET

Another NAV TechDays is over, and again, needless to say, it was a splendid conference. Thanks to everybody who attended one of my sessions about .NET Interoperability: the pre-conference workshop for beginners, the session for beginners, and the advanced, or as I like to call it, the “Black Belt” session.

Oh my. Has it really been *THAT* long? Obviously, yes. Some folks have asked me if I stopped blogging. No, I did not. I just took a way long break from it (which will likely resume the instant I hit the Post button), as I was busy working on other things such as How do I videos for NAV (you can…

If you ask me what the top addition to the NAV technology stack over the past few years is – it’s .NET interoperability. A lot of folks, maybe you as well, would disagree, and say it’s Web services. They are important. But if you are a NAV developer, Web services don’t make your life any easier.

With .NET Interoperability around, it’s very likely you’ll be synchronously calling external web services from C/AL, to exchange data. I won’t go into discussing whether or not this kind of architecture is good (my own position is that it isn’t), you may end up having situations where your C/AL code simply makes a synchronous call to external systems, such as web services.

Web services in NAV have an interesting feature: they are stateless. For a system which is pretty stateful otherwise, this feature can be outright annoying. You must get used to it, and then make sure you never ever write code as if there was any state preserved on the other end.

.NET Framework is full of programming conceptual gems, that are now at the fingertips of us poor C/AL folks. One of those is generics . However, the C/AL support for generics at the first glance seems rather limited, and the help file says that you can’t specify data types, and that all generics will be instantiated with System.Object as their type.

Passing strongly-typed data to NAV Web services can be trickier than it seems. If you are lucky, you can make your method accept strongly-typed parameters, and you are good to go. However, if you just can’t avoid sending text data, your text must be encoded in EN-US format, otherwise it will cause problems (see this ).

Fasten your seatbelts, you are in for the next round of Web Reference vs. Service Reference, which brings an unexpected twist to the story. After giving reasons why not to use Web References, I’ll now put my devil’s advocate ’s hat on, and try to have you change your mind.

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.