views:

717

answers:

3

Go bounty!

This question has earned me a tumbleweed badge (7 views in 7 days!), which is somehow a strong confirmation that Navision has a very limited market share, which - I suspect - should be a confirmation Navision is neither all that great piece of software...

But hey... that's what we got as a back-end, so I am ready to fight with this. :-O

If there is some daring navision developer who is able to shed light onto this... the bounty is there for you! :)


Original Post

I have recently implemented a rather complex e-commerce system that interacts with a legacy back-end based on Navision 5. So far the exchange of data between the two platform has happened via XML files, but this method is quite clumsy and very much prone to mishaps.

Our needs are:

  1. To expose certain elements of the business logic of each platform to the other one (for example: "what's the total amount ever purchased by this customer?", "what are the products currently on offer?", "how many new customers have registered on the website?", etc...).
  2. To have mechanisms of feed-back / validation for the various transactions (for example: "Here's the a new order from customer X" ... "Ok, got it, the order will now start to be processed" ... "Ok, copy that, bye!").
  3. If possible, avoid playing around with files, but keeping all of this happening in terms of calls/ports/services...

The most natural way I could think of would be to integrate the two systems via webservice, but Navision 5 does not support this natively. So I did my "due diligence" and found a few things on MSDN including this article and this other one.

According to these articles it should not be that difficult to create a webservice on Navision 5, but when I suggested this solution to the team in charge of the legacy system, they told us that it is "pure theory" and they do not know of anybody who ever implemented it.

I have no reason to doubt their word, but mileage can vary... and I thought that maybe in the SO community there are professionals from other countries who actually implemented something similar and are available to share their experience.

So, my question is two-folded:

  1. Is there anybody who has tried this at home and would be available to share a bit on what have been the greatest difficulties, if the final result is reliable, if they think the outcome is worth the effort, etc... ?
  2. Is there anybody who faced a similar problem but solved it with a different approach and that would be available to present their solution ("I never did it myself, but if I had to do it I would do it like this..." type of answers are also welcome)?

Thank you in advance for your time! :)

+1  A: 

Where I work, we were able to use one of the web services from NAV 6 to integrate with SharePoint, so you can look up a customer or record and show it in a web part in SharePoint. I know your question is about NAV 5 in particular, but I have only seen this working on NAV 6. And I wasn't the developer who worked on this, so I don't have any more specifics I'm afraid.

Did you try asking on mibuso.com? They're much more Navision-focused.

Paul Fedory
Indeed Nav5 and 6 are deeply different, as far as webservice integration is concerned... thanks anyhow for the link, that I will check out sometime tomorrow. :)
mac
+3  A: 

I too will chime in with a not-too helpful answer about Nav 6 :)

I've just completed a project using Nav 6. Suprisingly, the webservices are VERY easy to expose and consume. It's really a trivial matter to go find a object in the webservices interface and tick a box to tell it to expose itself.

Unsuprisingly, the webservices don't work as you'd expect, you have to often use some trial-and error to get objects and properties to persist, as it's really touchy as to the sequence of events you use to save and object. And each object seems to work slightly differently. eg: To create a customer, I eventually found out that you have to create and save a blank customer, massage this new record with a codeunit, then fetch the record and then write the customer's attributes and save again. I expected to just create a new customer(), set the attributes and save in one quick swoop.

I guess you're not too keen on upgrading to Nav6, but off the top of my head, Here is how you could simulate web services:

Sharepoint can already consume and expose webservices, so that tier isn't a problem. Nav 5 doesn't have them 'naturally', but you could cook up your own program that acts as a webservice 'broker' - you're already getting info into and out of nav, via mostly XML. You could build this broker to take input as the xml files and massage them to use in a webservice call. You could even forgo the XML and write and read directly from the Db, as all the Nav info is stored there anyway. So here's what I'm thinking:

NAV <-> SQL SERVER <-> New 'broker' webservice <-> Sharepoint

Or if you already have the NAV API down pat and want to resuse your XML:

NAV <-> XML files <-> New 'broker' webservice <-> Sharepoint

If you are using XML and use filewatchers, the latency shouldn't be too bad, usually filewatchers pick up on a drop or change in milliseconds.

Hmm, but I'm thinking you are probably supposed to use BizTalk for stuff like this: NAV <-> BizTalk <-> Sharepoint

But I don't know how easy it would be to set up BizTalk to communicate with Nav. I'll bet that it's pretty straighforward to get comms working, but this is speculation.

In any case, I don't know how helpful this post is, but maybe it gives you a few ideas to go with.

Cheers, Lance

Lanceomagnifico
Thank you for your time and for your ideas (+1). I am not a Nav developer myself but if I got you correctly, your second option "nav-xmlfiles-broker-sharepoint" is about the same than presented in the articles I linked in the question (on which I have been told "pure theory"). Unluckily, so far this is the only possible choice for the customer as they do not want to invest money in new licences and the Navision version they have runs on the discontinued proprietary DB (so: no SQL) and no chance to pay for BizTalk either. They also do not use Sharepoint as a web layer but Drupal (FLOSS).
mac
-macIMHO the NAV <-> XML files <-> New 'broker' webservice <-> Sharepoint (replace sharepoint with Drupal) would probably already leverage your existing processes, since you are already outputting XML and probably consuming XML with Nav.I'd use Microsoft.Net to create a webservice 'broker' to be the communication hub, but I am assuming that Drupal can consume and expose webservices itself, so that it can talk to the broker.There's not really much theory here - if you are already importing and exporting the data from Nav and Drupal, inserting a 'broker' layer to competently handle comms...
Lanceomagnifico
should be fairly straight forward. But if you are looking to replace the XML export/import on the Nav side (not just beef it up), The the article you mentioned (http://msdn.microsoft.com/en-us/library/ms952079.aspx) shows how to use MS Message Queuing to replace your XML import/export stuff.Actually, when I was just beginning our last project, they *were* going to use Nav 5, so I also looked at implementing the MSMQ solution, but the customer got a sniff that Nav 6 was comming out, and waited to purchase it instead.
Lanceomagnifico
Like I said, the webservices in Nav 6 are trivial to expose. I never did try to get it to consume anything - everything is pushed from the website to Nav, so we have the .Net website doing all the work.Cheers,Lance
Lanceomagnifico
@Lance - Thank you for the extensive answer. You are confirming somehow my feelings that it should not be that difficult to follow this approach... yet my problem is not understanding how this technology works, but convincing the team in charge of it that is relatively simple to implement. :(
mac
+1  A: 

When you say expose business logic, does this include executing AL code (e.g. a CodeUnit)? If you only need to perform queries against the database you could use NODBC & System.Data.Odbc or the CFront .NET API. Either of these can easily be wrapped using a .NET web service, and both support the native NAV database. To pass messages back you would still need to use COM, as described in the first article you mention.

Any of the above are entirely possible, and relatively easy depending on your proficiency in .NET, COM and NAV.

The second article you linked to describes using the NAS. I'm no expert on this, but I think this might require a special license granule. Before spending time implementing anything its worth checking whether your license includes the NAS, CFront or NODBC.

Alex Peck
Thank you for this answer, that unforunately came when the bounty was just over! :-O To answer your question: **Yes, I would need to expose some CodeUnit with the webservice**. Nevertheless your comments about the alternate solution might be of some help in some limited cases, so , thanks a lot for that! (+1)
mac