Can NAV Web Services being connected through static IP

derrick

Hi experts, would like to check, the scenariou:
- NAV Server running in Europe, the machine with static dedicated IP, Network Domain A.
- Web Application Server running in US, Network Domain Z.

Can the Web Application getting access to the NAV Web Services?

tlarson

I'm assuming by 'Web Application Server' you mean a server that is running a custom web application you have developed that connects to Nav 2009 web services. That is:

Domain Z - Web Application Server
Domain A - Nav 2009 Web Services, Nav 2009 Server

Yes, this will work. Make sure that you set up the Nav 2009 Web Services with a SSL certficate, set a domain name to point to its IP address, and set your firewall to only allow connections to the web service from Domain Z.

Then, your custom web application can be set up at Domain Z and point to Domain A for the web service.

However, you will need to consider bandwidth and latency, as they could pose some problems for your web application, depending on your SLA.

Tim

derrick

Thanks, Tim.

Do you have any documents, reference, or guidelines on this?

tlarson

I don't know that there's any one document that could cover this, as it covers a broad array of things. But I can try to provide several links that might help.

I would recommend making sure you're running on Nav 2009 SP1 - it has a bunch of enhancements that will make this easier.

1. Set up the three Nav 2009 tiers in Domain A
- http://msdn.microsoft.com/en-us/library/dd301254.aspx
- https://community.dynamics.com/blogs/na ... -2009.aspx
- http://blogs.msdn.com/nav_developer/arc ... setup.aspx
- http://blogs.msdn.com/nav/archive/2009/ ... -2009.aspx
Make sure that you edit the CustomSettings.config file to point to the correct database. You will need to start the 'Microsoft Dynamics NAV Business Web Services' service. Make sure this service is running as an account that has enough permissions in Nav to do whatever it is your web application needs to do in Nav.
FYI, setting up the SPN stuff will very likely be painful unless you're really familiar with Kerberos. To make things simpler, you can install the web services layer on your SQL server, making all of the SPN pain go away. But this solution is not as scalable. The best practices analyzer for dynamics Nav was recently released which can help with the SPN pain, though. I'm not familiar with SPN or Kerberos, and I never got it to work, but there are several articles out there that aim to help with the SPN setup. Google is your friend.
Make sure that the Web Service service is set to start automatically.


2. Develop your web application that will connect to the web service. I would recommend starting with it in Domain A, just to make sure that firewalls and the internet and DNS don't cause any trouble.
- http://www.webmonkey.com/tutorial/Exten ... 009-Part_1
- http://www.packtpub.com/article/extendi ... 2009-part1
- http://msdn.microsoft.com/en-us/library/dd301179.aspx
You will need to create and publish web services from within Nav (you must use the Classic client to do this
- http://blogs.msdn.com/nav_developer/arc ... rvice.aspx
- http://dynamicsuser.net/blogs/navdev/ar ... rvice.aspx
Check the Application Event Log on the server running the 'Microsoft Dynamics NAV Business Web Services' service to find the URL for the Nav web service that you will need to make Nav calls. (FYI, this is a WCF service). Typically, you will connect to something like this: http://servername:7047/DynamicsNav/ws/M ... e/Services. The port number and 'DynamicsNav' are configurable in the CustomSettings.config file.
At this point, servername will probably be a local, internal IP address or internal server name. Make sure that this is a configurable element in your web application so that when you move your web application you can change the URL of the web service it's connecting to.
If you have a Company Name with spaces or other characters in it, see http://blogs.msdn.com/freddyk/archive/2 ... 9-sp1.aspx
(As a bonus, here's an article about debugging when developing against the web service tier: http://blogs.msdn.com/clausl/archive/20 ... -2009.aspx)


3. Get a static IP address assigned to Domain A. Or you could use a Dynamic DNS service, but dynamic DNS will be much less reliable.


4. Register a domain name and point it to this static IP address. Or you could put an entry in the hosts file (C:\Windows\System32\Drivers\etc\hosts) on the machine in Domain Z that is running your web application.


5. Create a self-signed SSL certificate on the machine where the web services are running.
If you are running Server 2003:
- Download the IIS kit and install the selfSSL tool from http://www.microsoft.com/downloads/deta ... laylang=en. (Or, you could install this package somewhere else and just copy SelfSSL.exe to the web service server).
- Open a command prompt from Start - Programs - IIS Resources - SelfSSL
- run this command:
selfssl /T /N:cn=www.MyWebServiceDNSName.com /K:1024 /V:1000
- Of course, replace http://www.MyWebServiceDNSName.com with whatever DNS you registered in step 4
- When it asks you if you want to install it on site 1, say 'y'. If you don't have IIS6 installed, it will give an error - this is ok. The certificate should be in the Personal Computer certificate store and will be valid for 1000 days. You can see if by opening the Certificates MMC panel (start - run - mmc, then add snap in for certificates on local computer).
I'm not sure exactly how to do this for Server 2008, but it will likely be different due to UAC


6. Run httpconfig.exe (from http://www.stevestechspot.com). In the SSL tab add an entry. Give it the IP address and port you want SSL to be listening on (I would recommend 443), choose a certificate, and click OK. Then click Apply. Don't forget to click Apply.


7. Open CustomSettings.config for the Nav Web Service (C:\Program Files\Microsoft Dynamics Nav\60\Service\CustomSettings.config). Change the SSL setting to true and the port number to the same port you chose in step 6.


8. Restart the web services computer (otherwise the parts you changes in step 6 won't take effect).


9. Set up your firewall that is protecting the web services computer to allow for port 443 (or whatever you chose in step 6) to get through to the web services server. I would recommend setting it up to only allow traffic to come in if it is coming from Domain Z.


10. Go to the web application server on Domain Z and try to browse (using a web browser) to the URL for the web service on the web services computer in Domain A. Make sure it comes up before moving on. Please note that if you are not using port 443, you might have to change the browser configuration to allow it to show the page (particularly with Firefox).


11. Put a copy of your web application in Domain Z on the web application server, and make sure it's pointing to the public DNS name you created in step 4 on the port you created in step 6 to the folder/etc. that you discovered in step 2.

derrick

Tim, you are so helpful. Thanks a lot.

derrick

Hi guys, I am bringing back this topic.

Does anyone has proved that this kind of environment is workable, the way of Tim kindly suggested or any others?

I am not particular in Networking, please help! Thanks in advance.

AdrianAkers

Well we have built a custom Web App running only within the same domain, but the configuration of the Web Services is all handled in our Web.config file. I am not sure about running this over SSL but would think that you could setup the NAV web services to achieve most of this. You could then have SSL with the requests to your custom Web App and SSL to your NAV web services internally. I can imagine that setting the delegation up across 2 separate domains would be a pain and maybe getting some advise from Microsoft would be your best route hear. We have the solution installed with the 3 tiers over 3 computers and also have Kerberos and Delegation working within the same domain (although this install was a pain at the time...)