Navision / Microsoft Dynamicsバージョン5のWebService…またはその他？

Question

賞金に行く！

この質問は私にタンブルウィードバッジ（7日間で7回のビュー！）を獲得しました。 ナビジョン 市場シェアが非常に限られているので、私は疑う - 私は疑う - ナビションはそれほど素晴らしいソフトウェアでもありません...

しかし、ちょっと...それは私たちがバックエンドとして得たものなので、私はこれと戦う準備ができています。 ：-o

これに光を当てることができる大胆なナビジョン開発者がいる場合...賞金はあなたのためにあります！ :)

---

オリジナルの投稿

私は最近、Navision 5に基づいてレガシーバックエンドと対話するかなり複雑なeコマースシステムを実装しました。これまでのところ、2つのプラットフォーム間のデータの交換はXMLファイルを介して発生しましたが、この方法は非常に不器用であり、非常に傾向があります。事故に。

私たちのニーズは次のとおりです。

1. に ビジネスロジックの特定の要素を公開します 他のプラットフォームへの各プラットフォーム（たとえば、「この顧客が購入した総額はいくらですか？」、「現在提供されている製品は何ですか？」、「ウェブサイトに登録している新規顧客の数」など..）。
2. に フィードバック /検証のメカニズムがあります さまざまなトランザクションの場合（たとえば、「ここに顧客Xからの新しい注文があります」...「OK、それを手に入れて、注文が処理され始めます」...「OK、それをコピーしてください！」）。
3. もし可能なら、 ファイルで遊んではいけません, 、しかし、このすべてを呼び出し/ポート/サービスの観点から続けています...

私が考えることができる最も自然な方法は、WebServiceを介して2つのシステムを統合することですが、Navision 5はこれをネイティブにサポートしていません。だから私は自分の「デューデリジェンス」を行い、MSDNでいくつかのことを見つけました この記事 と このもう1つ.

これらの記事によると Navision 5にWebサービスを作成するのはそれほど難しいことではないはずです, 、しかし、私がこの解決策をレガシーシステムを担当するチームに提案したとき、彼らはそれが「純粋な理論」であり、彼らがそれを実装したことがある人を知らないと言った。

私は彼らの言葉を疑う理由はありませんが マイレージは異なる場合があります...そして、私は多分SOコミュニティには、実際に同様の何かを実装し、彼らの経験を共有するために利用できる他の国の専門家がいると思いました。

だから、私の質問は2つあります：

1. 持っている人はいますか 家でこれを試しました そして、最終結果が信頼できる場合、彼らが結果が努力する価値があると思うなら、最大の困難であったことについて少し共有できるでしょうか...？
2. 同様の問題に直面したが、別のアプローチでそれを解決し、それが彼らの解決策を提示することができる人はいますか（「私はそれを自分でやったことはありませんが、もしそれをしなければならなかったら、私はこのようにやるでしょう...」タイプ答えも大歓迎です）？

よろしくお願いします！ :)

Answer 1

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

Answer 2

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.

Answer 3

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.

Answer 4

You can actually do a "technical upgrade" of NAV 5 to NAV 2009 and then use the native webservices. Meaning replacing the exe-files and the entire application (but not the objects, which will still be version 5), and a couple of other tricks. But it works, and thus you have 2009-webservice-functionality on your NAV 5 :-)

Answer 5

For the benefit of anyone googling this, if you're still on Navision 6 with the native database, a good way of connecting it is via the windows message queue.

You can write your own web service that puts XML requests into the queue and then wait for the reply to pop up. On the Navision side, you have one clients that pulls the queue and puts answers into the reply queue. There's a special non-GUI client called NAS for that.

I've been using this approach for 15 years to connect booking engines to out Navision back end. It works very well and has the advantage that you can peek at requests before they reach Navision, so you can protect your back end from too many or faulty requests.

The only problem with this approach is that the COMMIT command within Navision is super expensive. It's difficult to serve high volumes of requests. As soon as the back end needs committing, you are down to just a few requests per second. This may be fine for low volume.

For high volume you need to implement caching or getting some of the business logic out. For me it was getting hit by price comparison websites, so here the solution is serve those from web services written in Python and only pass on the requests if someone buys something...