Freddys: Connecting to NAV Web Services from the Cloud–part 2 out of 5

[Blog bot]

If you haven’t already read part 1 you should do so here, before continuing to read this post.

In part 1 I showed how a service reference plus two lines of code:

var client = new Proxy1.ProxyClassClient("NetTcpRelayBinding_IProxyClass");
Console.WriteLine(client.GetCustomerName("10000"));

could extract data from my locally installed NAV from anywhere in the world.

Let’s start by explaining what this does.

The first line instantiates a WCF client class with a parameter pointing to a config section, which is used to describe bindings etc. for the communication.

A closer look at the config file reveals 3 endpoints defined by the service:

<client> 
   <endpoint 
     address="sb://navdemo.servicebus.windows.net/Proxy1/" 
     binding="netTcpRelayBinding" 
     bindingConfiguration="NetTcpRelayBinding_IProxyClass"  
     contract="Proxy1.IProxyClass" 
     name="NetTcpRelayBinding_IProxyClass" /> 
   <endpoint 
     address="https://navdemo.servicebus.windows.net/https/Proxy1/");
var client = new Proxy1.ProxyClassClient(binding, endpoint);
Console.WriteLine(client.GetCustomerName("10000"));

Again – this sample would require the Windows Azure AppFabric SDK to be installed on the machine connecting.


How to connect without the Windows Azure AppFabric SDK
As I stated in the first post, it is possible to connect to my Azure hosted NAV Web Services using standard binding and not require Windows Azure AppFabric SDK to be installed on the machine running the application.

You still need the SDK on the developer machine if you need to create a reference to the metadata endpoint in the cloud, but then again that could be done on another computer if necessary.

The “secret” is to connect using standard BasicHttpBinding – like this:



var binding = new BasicHttpBinding(BasicHttpSecurityMode.Transport);
var endpoint = new EndpointAddress("