MS Dynamics NAV Integration: How to Access NAV

Posted by Michael Bock on Sat, Feb 11, 2012

how to access navRapidiOnline supports many different NAV versions - all the way back from the Navision 3.70 (and even older versions too) and up to the latest MS Dynamics NAV 2009 R2 releases and MS Dynamics NAV 2013 - so there is not one single method that is best for all these versions.

Therefore RapidiOnline supports a total of 3 different ways of accessing NAV and so we can use the best way or ways in any given situation. I will go through all these 3 different NAV supports below.

Accessing NAV through C/Front

The first way of accessing NAV is through an interface called C/Front. C/Front is a database level interface to MS Dynamics NAV. It is supported both by the native NAV database server and for MS-SQL based installations. Its the same interface as the Classic NAV Client is using to access NAV data, so its rock solid and very fast. It is the Microsoft recommended way of accessing data in the NAV database and all Calculated fields and filters are supported in C/Front (Microsoft does not recommend that you use a direct access to the MS-SQL database).
The C/Front interface is supported in all NAV versions (except NAV 2013).
We recommend always to use the C/Front interface to read data from MS Dynamics NAV as this is by far the fastest way to read data, so huge amounts of records can be read in a short time. We also have buildin support for reading only what was changed since last run by using timestamp and this makes an integration very stable and fast running.
We also recommend C/Front when it comes to writing or updating many record to NAV and where there is no or very little business logic attached to the tables to be written in NAV.

Accessing MS Dynamics NAV through the Navision Application Server (NAS)

The second method we have to access MS Dynamics NAV is through the Navision Application Server (or NAS for short). The NAS Server is like a classic NAV Client but just without a user interface, so all the business logic in NAV also runs in NAS (actually you can code any functionality in NAS). This is a big advantage as you can leverage all the code that is already in NAV (including all your customizations) and so you can be sure that data are checked and validated as if a user was entering the same data.
Our NAS Support work from version 3.70 (which was the first release where NAS was relatively stable) and comes with codeunits that integrate with the Customer, Item and Sales Order objects. These codeunit can be copied to make support for other objects in NAV.
On the technical side, our NAS support is done with a Microsoft Automation Server plugin to NAS that handles all the communication with our central server and converts the data directly to/from our internal binary format and to fields in NAV tables - this means that a programmer working with the C/AL code that runs in NAS, does not have to worry about data conversion or XML documents etc. (as they would have to when using for example Biztalk) - this is much easier. The data transfers are controlled by the scheduler that is build-in to RapidiOnline centrally, so all that logic related to when what is run, is taken care of by the central RapidiOnline setup.

We recommend to use the NAS connector when you need to write complex objects to NAV that have a lot of business logic attached to them. For example for creating Sales Orders in NAV. You also need to have an IT organization that can support keeping the NAS server running as it is not so stable and typically needs restarting once a week or so.

Accessing MS Dynamics NAV is through Web Services

The third and last method for accessing MS Dynamics NAV is through Web Services. Web Services is available in NAV from MS Dynamics NAV 2009 R2 and is a very good and stable successor for the NAS Server.
Microsoft have chosen to make it possible to expose (or publish) any Page object that you have in MS Dynamics NAV as a WebService with some standard functionality. This means that in general you just have to do a few clicks to expose a page as a Web Service and that we can then read, update, create or delete data in the corresponding object (which is very good). It also means that the WebService mimics the functionality of the Page which means that sometimes you have to insert an empty record first and then send an update request to add information (this is the case with the SalesOrder page for example) and this can be quite annoying. Anyway its a big progress from the NAS based approach but hopefully it will be improved in NAV 2013.
We recommend to use the WebServices to create data in NAV where its important that the business logic is running to generate numbers or copy data from other tables/objects - like creating new Customers or Sales Orders. To some extend we would also recommend it to update data in NAV (again only when its important that the business logic is run). For reading data from NAV, we still recommend to use the C/Front based interface above.

There are of cause other ways to integrate with MS Dynamics NAV. You can for example import/export data from files (ASCII or XML files) or you could read/write directly to the MS-SQL database. We dont do this  - we prefer to provide a good and stable solution to our customers.

This concludes my walkthrough of the different ways to access MS Dynamics NAV, thanks for hanging on to the end and hope you enjoyed it.



Want to learn more about RapidiOnline and how we connect to different systems? Check out some of our archived webinars.

View Webinar on how to integrate your with MS Dynamics NAV

Tags: Data Integration, Pre-2014 Posts, Salesforce - Microsoft Dynamics NAV Integration

Sharing is Caring