If you ask your Microsoft Dynamics NAV partner about interfacing other systems into your NAV system, chances are they will say ‘does that other system support web services?’ So what are web services and why are they the interface method of choice?
Well in the same way at you can type a web address into your internet browser and get a particular page up in your browser, you can type a web services address and access or update particular information using web services. Working securely across your local network, or the full internet, they allow different systems to talk to each other in real time.
What this means is that an external system accessing your Dynamics NAV system via web services can get and update information in real time. That means that, for instance, it can get the number of an item in stock and the current sales price for a particular customer exactly the same as a user accessing the system through the full Dynamics NAV client.
Then if it tries to do a sales order for that item for a particular customer and that item is blocked the web service will send the external system exactly the same error message as if again they were using the full windows client.
The advantage of this real time nature cannot be underestimated. Compared to the batch update method of importing or exporting a file (which may have an invalid value that an administrator then has to sort out) it makes interfacing immediate and seamless. In fact the third party system using the web service is effectively just another type of client to your Dynamics NAV data like the standard Windows, Web and Tablet clients are.
Not only can Dynamics NAV be updated via web services, it can also use them to access or update information in other systems. So for instance with Dynamics NAV 2016, it will talk to Dynamics CRM using CRM’s web services to make sure that as soon as certain information is updated in NAV, it’s also updated in CRM. Because web services are just a type of URL that CRM can be, CRM Online based on Microsoft platform or CRM on your own servers, you just change the ‘address’ you put into NAV’s CRM integration setup table.
So NAV doesn’t have any web services published by default. If you want to see if any have been published on your system simply type web services into the search box in the top right hand corner and access the web services table from there. This also now gives you the ‘web address’ for both the SOAP and OData formats of the published web service. Copy these into your browser of choice, enter your credentials and see the difference for your self.
If none are published note that you can publish any page, query or codeunit. Personally I think creating a specific codeunit with the functions or calls needed is good practice. Having a XMLport as one of the parameters on those function calls allows huge amounts of data to be passed in and out as securely and effectively as possible.
Certainly web services are the interface method you should use if possible. In the future I suspect all systems will support them and any system worthy of being called modern or current does now.
Note
This post is part of a 6-part series. A link to all the posts in this series are below;
- Why Do You Need to Understand the Technical Structure of Dynamics NAV
- Part 1: Clients & Servers, Executables and Objects & Databases in Dynamics NAV
- Part 2: Object Types, Tables, Pages, Reports, XML Data, Code Units, Query Object Types and Menusets in Dynamics NAV
- Part 3: Object Numbers, Object Licensing in Dynamics NAV
- Part 4: Web Services – interface method of Choice in Dynamics NAV
- Part 5: Companies and Per Company or Per Database Tables in Dynamics NAV
- Part 6: Multi-tenancy – What Does it mean?
