3

I want to write a .NET application that will interface in realtime with Dynamics NAV 2009 and 2013. The application will have to read and update entities such as customers and stock items.

Using the provided webservices seem to be the best candidate as a point for integration, and I've tried some basic tests reading, updating and creating items using webservices based on Pages and a .net client.

Unfortunately, I am very new to Dynamics, and I have some questions that probably reflect that lack of experience.

First - webservices can expose either Page or Codeunits. Is Page the correct option to use for interfacing to say - create a customer?

Secondly - My understanding is that Dynamics NAV is rarely deployed without customisation. Would a typical customisation in NAV e.g an addition of a field involve changing a standard Page, and will this change then be reflected in the webservice definition?

John Slegers
  • 45,213
  • 22
  • 199
  • 169
Sean Williamson
  • 33
  • 3

1 Answers1

5

You are right - given your requirements, webservices are probably the best option for interfacing with NAV.

Regarding your first question: page web services know how to handle concurrency, and, thanks to the way Visual Studio encapsulates them, expose rich types that you can interact with from your .NET code. All the basic CRUD operations can be carried out using the exposed methods. For a more detailed comparison between codeunit web services and page web services, please refer to http://msdn.microsoft.com/en-us/library/dd355398.aspx.

I think most developers choose not to publish the normal pages (the ones aimed at the NAV Windows Client; previously known as the Role Tailored Client), but instead, create separate, tweaked pages for publishing as a web service. But, if you prefer, I guess you could add your custom field to the standard page and publish that as a web service.

Hope this helps! Good luck! :)

Jan Hoek
  • 702
  • 5
  • 13