Connection refused error on NAV when connecting to web services

When you try to access Navision Web services you may encounter the following error

“This Site can’t be reached, xxxx refused to connect”

The most common reason for this error is the NAV Service is not enabled for SOAP/OData.

To enable these services, open the Microsoft Dynamics NAV Server Administration tool and select the SOAP Services Tab/ OData Services Tab  and make sure the property is set to true

Enable SOAP Services and Enable OData Services to true, if you are using SOAP you just need to enable SOAP and vice versa.

You can also use the Powershell Cmdlet

Set-NAVServerConfiugration to enable the services for example to enable OData you use the following cmdlet

Set-NAVServerConfiguration -ServerInstance <ServerInstance> -keyname ODataServicesEnabled -keyvalue true

Replace <ServerInstance> with the name of the Microsoft Dynamics NAV Server instance on which to set up OData services.

Check the following link for more examples

https://msdn.microsoft.com/en-us/library/dn135246(v=nav.70).aspx

One other reason for this error is because the port is blocked and you need to create an inbound rule to allow it.

Please check this below the article you need to do the same for the web services port

https://docs.microsoft.com/en-us/dynamics-nav/how-to--create-an-inbound-rule-in-windows-firewall-for-the-port-of-microsoft-dynamics-nav-web-client

If you have any other tips or suggestions, please do share them in the comments below.

Share:

Read more..

"The date is not valid" in Navision 2009 SP1 or R2

Today I got a request in which the client was getting "the date is not valid" error when they are trying to authorize credit card using Navision Webservice. They were using chargelogic add-on and exposed a codeunit in which it has functions to authorize credit card.

When I first saw that error my initial thought was it is something related to settings in customsettings. config file. So we changed "WebServicesDefaultTimeZone” setting to use "Server Time Zone". But unfortunately that did not fix the issue and we kept getting the same error. Then I used my debugging skills to find the part of code where the error was happening. Once I debugged it I found that they have some customizations to improve performance in which one of them was to use single instance codeunit to get data from setup tables. Instead of using normal statement table.GET statement they stored all these get statements in separate functions in a single instance codeunit and they called this codeunit whenever they wanted to use GET statement for setup tables.

Share:

Read more..