Once an object has been published, we may want to see exactly what is available as a web service. As web services are intended to be accessed from the Web, in the address bar of our browser, we will enter the following (all as one string):

http://<Server>:<WebServicePort>/<ServerInstance>/WS/ 
<CompanyName>/services

Example URL addresses are as follows:

http://localhost:7047/DynamicsNAV/WS/Services 
http://Arthur:7047/DynamicsNAV/WS/CRONUS International Ltd 
/Services

When the correct address string is entered, our browser will display a screen similar to the following screenshot. This screenshot is in an XML format of a data structure called WSDL (WebServicesDescriptionLanguage):

In this case, we can see that we have two NAV SOAP Services available: Codeunit/Radio_Show_Management and Page/Radio_Show_Card.

To see the methods, which are NAV functions, that have been exposed as web services by publishing these two objects, we can enter other similar URLs in our browser address bar. To see the web services exposed by our codeunit, we can change the URL used earlier to replace the word Services with Codeunit/Radio_Show_Management. We must also include the company name in the URL that lists the methods WSDL.

To see the OData services, change the URL to one in the form, as follows:

http://<Server>:<WebServicePort>/<ServerInstance>/OData

From that entry in our browser, we get information about what's available as OData. OData is structured like XML, but OData provides the full metadata (structural definition) of the associated data in the same file as the data. This allows OData to be consumed without the requirement of a lot of back and forth technical preplanning communications:

The actual consumption (meaning "use of") of a web service is also fairly simple, but that process occurs outside of NAV in any of a wide variety of off-the-shelf or custom applications that are not part of this book's focus. Examples are readily available in Help, the MSDN library, the NAV forums, and elsewhere.

Tools that can be used to consume NAV Web Services include, among others, Microsoft Power BI, Microsoft Excel, Microsoft SharePoint, applications written in C#, other .NET languages, open source PHP, and a myriad of other application development tools. Remember, web services are a standard interface for dissimilar systems.

As with any other enhancement to the system functionality, serious thought needs to be given to the design of what data is to be exchanged and what functions within NAV 2017 should be invoked for the application to work properly. In many cases, we will want to provide some simple routines to perform standard NAV processing or validation tasks without exposing the full complexity of NAV internals as web services.

Perhaps we want to provide just two or three functions from a Codeunit that contains many additional functions. Or we may want to expose a function that is contained within a Report object. In each of these instances and others, it will be necessary to create a basic library of C/AL functions, perhaps in a codeunit that can be published as web services (generally recognized as a best practice).