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:

pure-c
Pure C#
pure-cal
Pure 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:

how-to-use

and this is the result:

example1

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.

This blog is available also on Microsoft Dynamics NAV Community