New April Hotfix and more changes for VAT
Check out the latest updates to Microsoft Dynamics GP 2016 and 2018.
Dynamics 365 2019 release wave 2 plan Discover the latest updates to Dynamics 365.Release Plan | Weekly Deployment Notes
Ace your Dynamics 365 deployment with packaged services delivered by expert consultants.Explore service offerings
Connect with the ISV success team on the latest roadmap, developer tool for AppSource certification, and ISV community engagements.
ISV self-service portal
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance and Operations TechTalks | Customer Engagement TechTalks | Talent TechTalks
Hello GP Community,
A big topic that we are getting a lot of discussion around is regarding the Workflow Actions that you can include in your Workflow email notifications. We are seeing a lot of customers setting this up to get the Approve and Reject actions in their notification, but there's a general lack of knowledge in how to get this working so that you can click the Approve button and approve the document when you're anywhere in the world, not just when you're connected to your local network. The intent of this blog post is to give an overview of the various pieces involved with this process, so that you're able to approve documents from outside the network.
The main thing dictating whether you’ll be able to approve from outside your network is the hostname that you enter into Workflow Setup for your GP Web Services. If this hostname is publicly resolvable, and the port is open, the approval will work. If you’re just entering the NETBIOS name of the Web Services server, then the approval will only work while connected to the internal network. This post is going to cover the components needed to set up a publicly resolvable hostname for use with Web Services.
The first concept to cover is DNS, which stands for Domain Name Servers. DNS is how internet addresses are mapped to IP addresses. DNS servers are the backbone of any enterprise network, and they're the backbone of public internet as a whole. When you type www.bing.com into the address bar of your Web Browser, that request goes to a public DNS server (usually provided by your ISP) which responds with the proper IP address of the server hosting the Bing website. Once your browser knows the IP, it can connect and display the site.
The same concept applies to internal networks, the only difference being that Active Directory has its own DNS server that is used to assign IP addresses to computers on the network. When you try to open a file through a network drive, the DNS server of your local network is what provides the proper IP address of the file you're accessing. If a local DNS server cannot resolve the request, then it will forward on the request to another DNS server until it reaches a server that can provide the IP, otherwise a 404 error is returned.
The next concept to cover is the Web Services service that is required for approving via email. During the install of Web Services, you are not prompted for nor allowed to change the hostname on which the service is bound. The config files are written using the NETBIOS name of the server on which it is installed. NETBIOS name resolution requires that you be connected to the same domain and share the same DNS server as the Web Services server. In a ‘flat’ network, this is very simple.
In the Workflow setup, you are prompted for a URL at which Web Services can be reached. In a flat environment, you’d just enter the NETBIOS name of the server. However, for the links to be resolvable from outside the domain (where NETBIOS name resolution doesn’t work) you’ll have to have something different set up. You have to own a domain, and you have to set up a PTR record on the domain you own to forward that PTR traffic to the static IP of your network’s firewall. You then have to open and forward port 48620 traffic to the Web Services server. The external request now looks like this.
For NETBIOS name resolution to work, there simply needs to be an A Record in DNS on the domain to map the local IP to the NETBIOS name. This record is created when you join a machine to the domain, so this happens automatically. Any machine joined to the domain can be reached at their NETBIOS name or their FQDN, which is NETBIOS.DOMAIN.COM. Point being, you cannot use a NETBIOS name if you want the request to be approved from outside their domain. Public DNS servers do not have NETBIOS name records for a local machine on your private network, this is where the requirement comes for having to own a public domain name, one purchased via a public registrar. Once you own the public domain name space, then you can either just use the entire domain label for Web Services, but most would want to use a PTR record, so the traffic could flow via label.domain.com instead of taking the entire domain. You may want your website on domain.com, and web services on web.domain.com.
Once you have a publicly resolvable hostname, this is what you will enter into Workflow Setup and then the emails will be generated with this public hostname.
The final concept to cover is to bind the service itself with SSL, since the traffic would be routing via public internet. We definitely recommend doing this, the steps to do so can be found at the following post:
You'll just need to get a certificate for the public hostname that you set up, follow the blog post to bind this certificate to your service, and then enter this hostname into Workflow Setup and check the "Use SSL" option.
Dynamics GP Systems Support
Business Applications communities