What's all the fuss with NAV Web Services?

So I've been developing in the NAV IDE for around 10 years now.  Whenever it comes to writing a little database to store something like my CD collection, personal accounts or keep a track of my mpg I have a few simple decisions.  Do I write the database in 4th Dimension (a great cross platform database I started my database career with), directly in SQL Server (SQL Std., Express or even MySQL), or NAV.  Usually the decision is quite easy - I work with NAV day in and day out, and also it is a lot easier to knock up a quick form in NAV.

What this does mean though is that I need to use the NAV client to enter and update my data.  I could of course go to the trouble of creating a .NET front-end which could read and write directly to my SQL database (assuming here of course I am always using SQL as my backend - rather than the native NAV database), but then of course I am going to lose all the lovely validation and business logic I built into NAV.  I could simply get my front-end app to write to a 'processing' table which could be monitored by NAV and then actioned within NAV, thus maintaining all the business logic, but all of this is a bit of work. 

Wouldn't it be good if I could simply call into NAV code - well with NAV 2009 and the introduction of web services we can do this to a certain extent!

We are able to expose a codeunit or a page as a Web Service from a NAV Web Service.  With this exposed we can then write our functions in NAV and make use of all the great features we know and love.

So none of this is really new... in the next days and weeks I hope to build up a few examples of this in action.  Continuing with the original theme of my blog this will also expose me to some .NET and the interaction between NAV and this framework which I am keen to explore.

Watch this space!

Comment List