Discussion: What are your experiences with integrating NAV with an external system?

Business Central/NAV Developers Forum
1

Hi everyone,

I know the question is very broad, but feel free to narrate anything related to your experience of integrating NAV (2013 or later) with an external system.

If you desire to have a more structured answer, here are some aspects that I am curious about:

  • A short description of the reason for integrating the two systems;
  • How easy / painful was to perform the integration;
  • On which technologies did the external system rely;
  • Whether you feel that NAV’s constraints pushed you to over-engineered the integration;
  • Whether you required a Developer License to perform the integration or a Customer License sufficed.

By external systems I mean: Intranet sites, Internet e-Commerce sites, Office Suite (especially Excel), console / desktop applications, scripts, databases.

By integrating I mean: using Web Services (SOAP, OData), XMLports, Queries, Codeunits, databases, files and various integration techniques to connect NAV to the external system and / or vice-versa.

Also, please let me know how can I change the question to be more comprehensive, or please edit it yourself if possible.

Thank you!

[Side note: this is a cross post from reddit, but it better suits this place]

2

Hi Andrew (much nicer to have a name, than just xvizcjhrjv),
You’re right. That is a rather broad topic. And I’m sure that almost any Navision developer at some point have done an integration to an external system. So it should give them all a change to say their opinion. I hope they will.

I have worked with Navision development for over 25 years and there have always been integration’s in NAV projects. So I think I have (or been on projects where we) integrated to almost everything possible. From EDIfact, DB2, SAP, call-centers, POS etc. to exchange rates (before it was standard), external warehouses/custom edi to employee time stamp machines etc. I did my first eCommerce web shop in 1997 - it was ugly and actually worked, even if it did perform lousy.

As a NAV developer we may not even be thinking about it. Most of the integration’s are standard in NAV and the users and consultants handle that themselves. Unless there are extra needs.

Most of the “integration’s” I have done over the years are simple file integration’s. You export a file, and import a file. CSV files used to be the most common, but now XML starts to be the most common. I use XMLPorts, whenever it fits, which means mostly when exporting. When importing, then I find that its often faster to import via dot net in a codeunit. Especially if you have a good design pattern you can reuse (something you always should have in your “toolbox”).

The last 3-5 years the general integration’s have become “more advanced”. By that I mean now its no longer enough, that we handle the file in and out of NAV in batch mode. NAV needs to handle much more of the process directly. That goes both when it comes to custom integration’s, as the ones standard in NAV.

Just look at NAV 2016? The functionality we are getting now (and even more to come in NAV 2017) are a lot more focused on integration to “external” (even if they are part of Microsoft) applications like Dynamics CRM, PowerBi, Office 365, as well as the “data exchange framework” allowing you to directly integrate to banks etc.

Today we have so many different ways to INTEGRATE that we could never stop discussing the different integration options, their pros/cons etc. But that is ok.
I will come with some more concrete examples, but not until I have had my lunch.