by Vjekoslav Babic on March 5, 2013
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.
[click to continue reading…]
by Vjekoslav Babic on February 21, 2013
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.
[click to continue reading…]
by Vjekoslav Babic on September 30, 2012
![MP900406779[1]](http://navigateintosuccess.com/wp-content/uploads/2012/09/MP9004067791_thumb.jpg "MP900406779[1]")
Have you ever needed to connect to the Web services of one NAV instance from another one? If so, I bet that the approach was something like this: you created a .NET class where you defined a Web or Service reference to the target instance, and then you consumed that .NET class using .NET Framework interoperability. It was kind of clumsy, inflexible, but it worked.
How cool would it be if you could do something like this:
WITH WebService DO BEGIN
CONNECT(‘http://localhost:7047/DynamicsNAV70/WS/CRONUS%20International%20Ltd/Page/Customer’);
INIT;
SETVALUE(‘Name’,'Test Customer’);
SETVALUE(‘Blocked’,Cust.Blocked::Ship);
SETVALUE(‘Credit_Limit_LCY’,10000);
CREATE;
MESSAGE(‘I just created Customer No. %1 in another NAV instance.’,GETVALUE(‘No’));
END;
[click to continue reading…]
by Vjekoslav Babic on June 25, 2012
Marketing is nice as long as it matches the reality. With Microsoft Dynamics NAV 2013, Microsoft has promised a lot of improvements, but how well does NAV 2013 stand the reality test?
Apparently, outstandingly well.
Over the past two days, I have intensively tested NAV 2009 and NAV 2013 through a series of five different tests that measure different aspects of NAV data handling. My conclusion is clear: NAV 2013 is faster than any NAV you have ever seen, including the Classic client on the native database.
Continue reading to find out more about my findings and testing approach.
[click to continue reading…]
by Vjekoslav Babic on February 22, 2012
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.
[click to continue reading…]
![MP900406779[1]](http://navigateintosuccess.com/wp-content/uploads/2012/09/MP9004067791.jpg "MP900406779[1]")
