A couple of months ago, when I asked my friends on Facebook and Twitter if anybody knows how to move a WordPress blog to another domain, everybody said that I was crazy. You don’t do these things, they said. And yet, when they heard the reason why I was about to leave my old domain, everybody agreed.
NavigateIntoSucess.com has served me well. I moved my public WordPress website to this custom domain very early on. It has become a kind of a brand. But it is a pretty long name. You can easily mistype it. It’s difficult to remember it if you only occasionally stumble upon it. It doesn’t at all relate to me as a living person behind it. So I decided to move it all to a fresh new domain: vjeko.com.
MSDN has started running a series of the How do I… videos for Microsoft Dynamics NAV 2013 (feed here). The idea is to showcase a technical feature in 5-15 minutes. The project is still ongoing, but a number of videos have just been released and announced on the Microsoft Dynamics NAV Team Blog.
The project is a joint effort by Plataan and Microsoft, and I participated as a technical expert in charge of seven videos. I’ve already recorded five of them, out of which three are online.
You can find the links below, and please come back to this page as I’ll update it as more videos are published.
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.