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 (maybe, 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:

pure-cPure C# pure-calPure C/AL

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 absolutely true. The answer will be the subject of one of my next posts.