Last summer, when I posted my first article I though blogging is very easy, and I’ll post an article every week. Actually, it’s not that easy. Anyway, after few months here is the article, I promised: a 100% generic web service client for NAV.
I was looking for a way to automate all my web service calls without managing, deploying, and struggling with all Dlls generated by Visual Studio. I was hoping to use
CU 1290 SOAP Web Service Request Mgt. like described here. I quickly noticed that it is not working if the web service comes from another NAV Database (due to SOAP version used natively by NAV). So, I started looking around how Visual Studio generates Dlls I was used to use. I found the answer in this wonderful article from msdn.
This introduction begins to be longer than expected. So, let’s get into the bare bones of the topic.
As you guessed, I tried to translate the msdn article using .NET interoperability in NAV. The result was astonishing. I let you admire the similarities:
The C/AL code remembers me this great article. My first reaction was: What the he**, I’m writing code like the great Vjekoslav Babić.
Now, let me explain how it works. The CU uses four functions:
1- InitClient: compiles the WSDL on the fly and prepares a ready to use client (proxy, dll… or whatever you want to call it) in memory.
2-InitCallMethod: prepares the method to call with its parameters.
3- CallMethod: invokes the method and retrieves the web service result.
4- GetObjectValue: use the web service result in whatever way you want (result may be simple Text,Decimal… or complex Customer Record…).
Here is an example:
and this is the result:
Enough talking, you can download the code here gws-with-examples.
Some readers may say:
But this needs to compile the client every time; this is huge for the memory
This is true. The answer will be the subject of one of my next posts.