Nav integration using ESB (SOA)

cavalcanti_space

Hi,
We will use Nav as backoffice and another application as frontoffice. They will be integrated using an ESB (Enterprise Service Bus) which can transfer information from each other using xml files or calling SQL store procedures. One of the proposals is to create temporary SQL tables which will store the data received from the frontoffice and then insert those data onto the NAV tables. The other proposal is to use the xml file received from the frontoffice via the ESB, call a codeunit and update the NAV tables using the XMLPorts. What do you guys think about the proposals?

Cheers

ara3n

I suggest to use the staging/temp table in 50K range. Dealing with files is messy and cumbersome.

cavalcanti_space

Hi Rashed,

According to your answer, the ESB is not necessary to integrate another application with Navision????

cheers

ara3n

No, you don't need any other system secondary system to integrate with NAV. NAV can directly integrate with any other system.

jlandeen

The staging table approach will work and if there is a lot of data that is in a very static format then it's a good approach. I find that if you're doing integrations that are more complex/dynamic then XML data files and data structures are much easier to work with as they allow you to represent a lot of possible disseperate data in 1 file/stream.

cavalcanti_space

We will exchange the following data:
Vendor
Customer
Product
Purchase Orders
Sales Orders
Sales Price
Campaings

I believe we will need a broker to exchange the data, I dont see any other method to accomplish it.
The frontoffice (POS) is current being used in about 50 stores and the data such as Sales Orders need to be sent to Nav.

jlandeen

Yeah that sounds like a full blown integration project. There are quite a few different ways to approach that. A XML Port based web service could be used to integrate with the system and provide an interface that allows the execution of business logic in NAV while submitting document type XML structures that may include serveral data items (e.g. Sales Header and Sales Lines in 1 Sales Order XML document).

This sounds like it's a fairly substantial project and a few things that I would watch out for/problems I encountered in a similar integration project:
- Sales tax: which system calculates them and how are they communicated
- Master File Synchronization: is NAV the master data store for Vendors & Customers and what business logic triggers a synch process (or is it a nightly/scheduled push/pull)

I would try to spend a good amount of time up front designing a flexible solution architecture and defining all the data flows/business logic as I found this took a lot longer then the actual development on the last project I saw like this.

ara3n

I would stay away from files if the integration this big. If the other POS system is SQL at the backend, that's a big plus, you can replicate the db to your NAV server and then do the integration from one server.

Also most POS system transaction volume is pretty high, and posting that through Sales Order process may not be the right way to integrate.
Whenever we integrate with POS system with a lot of transaction, we've implemented it through LS Retail.