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.
As I promised, I’m making all materials available for download here on my blog, and Luc will also make the recordings available from Mibuso.
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 look them up on MSDN and PartnerSource), working on the digital learning for NAV (which is partly available on PartnerSource already, and partly will shortly be), preparing and delivering presentations and some other things.
A month ago, I’ve delivered a session at Directions EMEA 2013 in Vienna where I’ve talked about the .NET ineteroperability and Web services tips & tricks, and presented a series of demos (13 of official ones), and then promised to make them available on my blog. The problem was – I honestly intended to make them available, I just didn’t set a deadline. I work best when I have the deadline, but even then it’s not a granted thing.
This time, in Nashville, I was a bit smarter – I’ve actually set myself a pretty demanding deadline, promising my Directions US 2013 audience to actually post this on my blog this very afternoon. So here I am, sitting at the Paisano’s pizzaria and vino terrace, enjoying the kitschy extravagance of a view of a monstrosity of a place called the Gaylord Opryland Hotel & Resort, and writing this to keep up with my commitment.
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. You are programming for Web services when your requirements tell you so, but that’s it. You don’t experience those moments of truth, when it dawns on you, when you go eureka, slap your forehead and say: now this is something I solve with Web services! Not quite.
But with .NET interoperability, it’s a different story. If you know how to harness its power, there is no single project you’ll ever want to go without using .NET. It opens the door to the most powerful development framework for Windows, and it makes many impossible things possible, in pure C/AL.
There are two kinds of things in this world. Those that .NET Interoperability can do, and those it can’t. Microsoft has been steadily improving it since the initial release in 2009 R2. However, there is still much to be desired. Those small things that you cut in C# in seconds, and twist your brain inside out for hours before you realize you can’t do it in C/AL. Some of them may be in a backlog somewhere in Vedbæk, but I don’t know that, so I decided to compile a list of top 10 things I believe C/SIDE should support, and it doesn’t.
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.
Any external call is an expected point of failure. An important question you must always have in mind when calling external functions is transaction integrity. When writing code that targets only NAV, the structure of code is largely irrelevant, as long as you are not using COMMITs (which is another thing you should avoid at all costs). However, as soon as you introduce external calls, the structure becomes critically relevant. Critically relevant.
I’ve talked about this during my 2012 NAV TechDays session, and I promised I’d blog about it – so, here it goes.
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.
The reason for this is simple – there is no actual protocol that you use to communicate with NAV through SOAP. Calls are ad-hoc, essentially atomic, each one can accomplish a great deal of things in a single go, and it makes programming a whole lot simpler. The price you pay is the state. Once you close the connection, the session ends and the transaction commits (or rolls back). Next call starts from scratch.
If you need to preserve any state between the calls, whatever that state might be, you are toast. NAV simply doesn’t support it out of the box. A common misconception is that single-instance codeunits help. They don’t. The single instance is always single per session, and since each call is an isolated session, it means that each single instance codeunit dies at the end of the call.
Pretty annoying, isn’t it?
Well, it is, and it isn’t. I won’t argue about validity of situations where you need to preserve state across multiple web services calls – I am going to show you how to do it when you need it.
And what I’m going to show you works in both NAV 2009 R2 and 2013.
.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. However, with Microsoft Dynamics NAV 2013, there is a very simple way which allows you to use generics with other data types, as well. So, if .NET Framework Interoperability interests you a slightest bit, here’s a solution. The example below will be for the System.Collections.Generic.Dictionary<,>, and I will show how to use instances of the Dictionary<,> object with any desired data type, without having to pull in any external assemblies.
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).
What the heck, just encode the data as EN-US, right? Not quite. There are a myriad of reasons why data can come in non-EN-US encoding, one of which is this: it’s the Web services, for Pete’s sake – anyone or anything can call them.
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.
It’s simple: there are situations where Service Reference won’t work as expected, and Web Service will.
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.
To make it short: if something works on one platform and fails on another platform, it’s not the fault of the Web service being called, it’s the fault of the caller platform.
As I said in the last post, there are two ways, or platforms if you wish, native to .NET Framework, which you can use to connect to any Web services. And they don’t work exactly the same.
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.
A proxy class is a class which wraps a Web service functionality into a strongly-typed .NET object, and allows simpler communication through Web services. It hides away all intricacies of SOAP communication, authentication, serialization and deserialization, and exposes simple, easy-to-use objects. Every NAV Web service results in a series of proxy classes, and in Visual Studio the generation of those classes is as simple as clicking a mouse a couple of times.