Nav 2009 Web Services Authentication issue

GreyGhost

Hi,

We have a client running Nav 2009 and have developed a fully integrated web site (ASP.net), which we are about to launch.

During testing connectivity has been established to their site with a desktop client to site VPN. This has worked fine and response times have been a few seconds for all calls to the web services.

Unfortunately when we deploy to the live web server, which connects to the clients site through a permanent site-to-site vpn connection, every call to the Nav web services takes about 14-15 seconds to return.

Having spent a ludicrous amout of time analysing the connections, bandwidth etc, it appears that the slow response is connected to the authentication process. If we remove the credentials from the web service request we get a response in under 1 second.

Does anyone have any insights or suggestions as to how we might be able to overcome this issue, because the site cannot go live as it is, and the project is now overdue.

Thanks.

ara3n

The only suggest I can give you is to get 2009 sp1 executable and try it with NTLM authenication.
You can also authenticate without using Active directory.

GreyGhost

Hi Rasheed,

Thanks for the tip.

We have also had the following suggestion from Microsoft, which I'll share for the benefit of anyone else with the same problem:

For NAV 2009 there is a hotfix which will allow you to run NTLM without having to do an upgrade to NAV 2009 SP1:
KB971989 You cannot connect to a Web service when you connect a Web site by using the Microsoft Dynamics NAV 2009 Web service interface in a non-Microsoft development software environment
https://mbs.microsoft.com/knowledgebase ... -US;971989

Cheers,

Ian

ara3n

Hello Ian

Let us know about the performance improvements.

GreyGhost

Hi Rashed,

So the hotifx which MS suggested has been applied and we are now able to authenticate wiht NTLM instead of Kerberos, however unfortunately, this has not made the slightest difference to the time taken for the response to reach the web server.

We can cearly see from tracing the requests and responses using wireshark that there is a delay of 15 seconds every time we send the request packet that inlcudes the authentication details before we get any response. All other packets receive near instantaneous responses.

We have referred this back to MS Nav support and are waiting to hear furher.

I have also had a response to my similar posting on the MS Dynamics NAv forum (https://community.dynamics.com/forums/p ... aspx#42497) which suggest forcing the authetication to use TCP rather than UDP.

I think we may try another route and eliminate the VPN, although that will mean that the clients NAv web services need to be opened to all internet traffic. We can at least eliminate the VPN as being the issue.

Thanks again fro your help.

Cheers,

Ian

ara3n

As far as Opening to all to all Internet traffic. You can limit to accept connection from specific IP Address. That will eliminate a lot of issues.

You can also use a web service proxy.

http://mibuso.com/blogs/ara3n/2009/05/0 ... b-service/

GreyGhost

Hi Rashed,

Just to let you know that worked - with SSL of course.

Cheers,

Ian

ara3n

So VPN was the issue?

Chris86

Hello,

I know this topic is very old, but we've a similar problem with our NAV Webservice - SharePoint environment. Instead of the example above we have a direct connection and no VPN.

The problem is pretty the same. While calling the NAV Webservice about 60-80% of response time is spend by authentication. We tried different configurations (with NTLM and Kerberos) but nothing worked for us.

Did anyone solved the authentication problems with NAV Webservices?

Thanks for your support
Chris

Marijn

Hi Chris,

Do you mean you're also having response times up to 15 seconds like the topic starter? If that's the case you have a problem I never ran into.

But what response times can be considered normal? I do not know how to properly benchmark these, but let me give you some figures.

I am running a NAV 2009R2 demo application and a PHP/Apache ZF powered application on my laptop on WIN7. NTLM is set to TRUE in the CustomConfig file. When I call for an unfiltered customer list (about 80) using a hyperlink in a browser the response is rendered in about 1 second.

When I do the same for contacts, which are about 400, the response time jumps to 3,8 seconds.

Now imagine a live situation with thousands of records.

Considering the fact that these reponse times include the processing at the front end in the browser (Javascript), the PHP backend, the SOAP protocol parsing and the authentication I think these reponse times can be considered lightning fast, even on a local machine.

A client application should of course deploy a decent caching strategy. Users get irritated at 0,8 seconds. There's no point calling the same webservices with the same params over and over again. These responses can ben cached. Especially posted documents, like posted sales invoices which never change by nature, are ideal candidates to be cached.

Also, if the client application displays lists, a paginator should be used. You don't want to call for 400 records while only displaying 10 at a time. Navision is a bit bitchy when applying a paginator, because it doesn't work with an offset and limit but with a relative bookmark key. Most client side frameworks I am aware off do not offer a solution for this out of the box.

Just recently, I have been working with a Sharepoint developer creating some NAV-CRM functionality (SP1). The reponse times were about as good. It really depends on what you want to achieve and how.

Chris86

Hello Marijn,

Our problem is the slow response time (up to 30 seconds). We traced the webservice calls with wireshark and it looks like 60-80% of the resonse time is spend by authentication.
The response time in NAV for getting or writing data is absolutely ok and we're pretty sure, thats not the problem.

Chris

Marijn

That's not ok. I suggest you write some code to call a NAV webservice from NAV. Try to read an item or something in a different company and see if you still have those long response times.