Navision / Microsoft Dynamics 版本 5 上的 Web 服务......还是其他？答案

【问题标题】：Webservice on Navision / Microsoft Dynamics version 5... or else?Navision / Microsoft Dynamics 版本 5 上的 Web 服务......还是其他？
【发布时间】：2023-04-05 10:17:01
【问题描述】：

去赏金！

这个问题为我赢得了一个风滚草徽章（7 天内 7 次观看！），这在某种程度上有力地证实了 Navision 的市场份额非常有限，我怀疑这应该是确认 Navision 也不是那么棒的软件......

但是，嘿……这就是我们作为后端所得到的，所以我准备好与之抗争了。 :-O

如果有一些大胆的 navision 开发人员能够阐明这一点......赏金就在那里！ :)

原帖

我最近实现了一个相当复杂的电子商务系统，它与基于 Navision 5 的遗留后端进行交互。到目前为止，两个平台之间的数据交换是通过 XML 文件发生的，但是这种方法非常笨拙和很容易发生意外。

我们的需求是：

将每个平台的某些业务逻辑元素暴露给另一个平台（例如：“该客户购买的总金额是多少？”、“目前提供的产品有哪些？ ?”、“有多少新客户在网站上注册？”等...）。
为各种交易拥有反馈/验证机制（例如：“这是来自客户 X 的新订单”...“好的，知道了，订单现在开始处理”...“好的，复制一下，再见！”）。
如果可能，避免玩弄文件，而是让所有这些都发生在调用/端口/服务方面...

我能想到的最自然的方法是通过 web 服务集成这两个系统，但 Navision 5 本身并不支持这一点。所以我做了“尽职调查”，在 MSDN 上找到了一些东西，包括 this article 和 this other one。

根据这些文章在 Navision 5 上创建 web 服务应该没有那么难，但是当我向负责遗留系统的团队提出这个解决方案时，他们告诉我们这是“纯理论”，他们不知道有谁实施过。

我没有理由怀疑他们的话，但是里程可能会有所不同...我认为也许在 SO 社区中，可能有来自其他国家/地区的专业人士实际实施了类似的东西并且可以分享他们的经验。

所以，我的问题有两个方面：

如果最终结果可靠，如果他们认为结果值得努力等等……？
有没有人遇到过类似的问题，但用不同的方法解决了它，并且可以展示他们的解决方案（“我自己从来没有做过，但如果我必须这样做，我会这样做...... ." 类型的答案也欢迎）？

提前感谢您的宝贵时间！ :)

【问题讨论】：

标签： web-services integration microsoft-dynamics navision

【解决方案1】：

我也会附上一个关于 Nav 6 不太有用的答案:)

我刚刚使用 Nav 6 完成了一个项目。令人惊讶的是，Web 服务非常容易公开和使用。去webservices界面找一个对象，打个框告诉它暴露自己，真的是小事一桩。

不出所料，Web 服务并没有像您期望的那样工作，您必须经常使用一些试验和错误来使对象和属性保持不变，因为您用于保存和保存的事件顺序非常敏感目的。每个对象的工作方式似乎略有不同。 eg：要创建一个客户，我最终发现你必须创建并保存一个空白客户，用代码单元处理这个新记录，然后获取记录，然后写入客户的属性并再次保存。我预计只需创建一个新客户（），设置属性并快速保存。

我猜你不是太热衷于升级到 Nav6，但我想，这是你可以模拟 Web 服务的方法：

Sharepoint 已经可以使用和公开 Web 服务，因此该层不是问题。 Nav 5 没有“自然地”拥有它们，但是您可以编写自己的程序来充当 Web 服务“代理”——您已经通过主要是 XML 将信息输入和输出导航。您可以构建此代理以将输入作为 xml 文件并对其进行按摩以在 Web 服务调用中使用。您甚至可以放弃 XML 并直接从 Db 写入和读取，因为所有导航信息都存储在那里。所以这就是我的想法：

NAV SQL SERVER 新的“代理”网络服务 Sharepoint

或者，如果您已经准备好 NAV API 并希望重新使用您的 XML：

NAV XML 文件新的“代理”网络服务 Sharepoint

如果您使用 XML 并使用文件观察器，则延迟应该不会太差，通常文件观察器会在几毫秒内检测到下降或变化。

嗯，但我认为您应该可能将 BizTalk 用于以下内容：导航 BizTalk 共享点

但我不知道将 BizTalk 设置为与 Nav 通信有多容易。我敢打赌，让通信正常工作非常简单，但这是猜测。

无论如何，我不知道这篇文章有多大帮助，但也许它会给你一些想法。

干杯，兰斯

【讨论】：

感谢您的宝贵时间和您的想法 (+1)。我自己不是导航开发人员，但如果我理解正确，您的第二个选项“nav-xmlfiles-broker-sharepoint”与我在问题中链接的文章中介绍的大致相同（我被告知“纯理论”）。不幸的是，到目前为止，这是客户唯一可能的选择，因为他们不想投资新许可证和他们在已停产的专有数据库上运行的 Navision 版本（因此：没有 SQL），也没有机会为 BizTalk 付费.他们也不使用 Sharepoint 作为 Web 层，而是使用 Drupal (FLOSS)。
-mac 恕我直言 NAV XML 文件新的“代理”网络服务 Sharepoint（用 Drupal 替换 sharepoint）可能已经利用了您现有的流程，因为您已经在输出 XML并且可能使用 Nav 使用 XML。我将使用 Microsoft.Net 创建一个 web 服务“代理”作为通信中心，但我假设 Drupal 可以使用和公开 web 服务本身，以便它可以与代理通信。这里没有太多的理论——如果你已经从 Nav 和 Drupal 导入和导出数据，插入一个“代理”层来胜任处理通信......
应该相当直截了当。但是，如果您希望在导航端替换 XML 导出/导入（不仅仅是加强它），您提到的文章 (msdn.microsoft.com/en-us/library/ms952079.aspx) 展示了如何使用 MS 消息队列来替换您的 XML 导入/导出内容。实际上，当我刚刚开始我们的上一个项目时，他们打算使用 Nav 5，所以我也考虑实施 MSMQ 解决方案，但客户闻到 Nav 6 即将推出，并且等着买吧。
就像我说的，Nav 6 中的 Web 服务很容易暴露。我从来没有试图让它消耗任何东西——一切都从网站推送到导航，所以我们让 .Net 网站完成所有工作。干杯，兰斯
@Lance - 感谢您的广泛回答。您以某种方式确认了我的感觉，即遵循这种方法应该不难......但我的问题不是理解这项技术是如何工作的，而是说服负责它的团队实施相对简单。 :(

【解决方案2】：

在我工作的地方，我们能够使用 NAV 6 中的一种 Web 服务与 SharePoint 集成，因此您可以查找客户或记录并将其显示在 SharePoint 的 Web 部件中。我知道你的问题特别是关于 NAV 5，但我只看到这个在 NAV 6 上工作。而且我不是从事这个工作的开发人员，所以恐怕我没有更多细节。

您是否尝试在 mibuso.com 上提问？他们更专注于 Navision。

【讨论】：

确实 Nav5 和 6 有很大的不同，就 web 服务集成而言...无论如何感谢您提供的链接，我将在明天的某个时间查看。 :)

【解决方案3】：

当您说公开业务逻辑时，这是否包括执行 AL 代码（例如 CodeUnit）？如果您只需要对数据库执行查询，您可以使用 NODBC & System.Data.Odbc 或 CFront .NET API。其中任何一个都可以使用 .NET Web 服务轻松封装，并且都支持本机 NAV 数据库。如您提到的第一篇文章中所述，要传回消息，您仍然需要使用 COM。

以上任何一项都是完全可能的，并且相对容易，具体取决于您对 .NET、COM 和 NAV 的熟练程度。

您链接到的第二篇文章描述了使用 NAS。我不是这方面的专家，但我认为这可能需要一个特殊的许可证颗粒。在花时间实施任何事情之前，有必要检查一下您的许可证是否包括 NAS、CFront 或 NODBC。

【讨论】：

感谢您的回答，不幸的是，赏金刚结束时就来了！ :-O 要回答您的问题：是的，我需要使用 web 服务公开一些 CodeUnit。不过，在某些有限的情况下，您关于替代解决方案的 cmets 可能会有所帮助，因此，非常感谢！ (+1)

【解决方案4】：

您实际上可以将 NAV 5“技术升级”到 NAV 2009，然后使用本机 Web 服务。意味着替换 exe 文件和整个应用程序（但不是对象，仍然是版本 5），以及其他一些技巧。但它有效，因此您的 NAV 5 上有 2009-webservice-functionality :-)

【讨论】：

很有趣，但是我应该从哪里获得 exe 文件？在我看来，获得它们的唯一合法方法是购买 NAV 2009 的许可证......在这一点上升级整个系统是有意义的（或者是否有另一个合法的选择来做你所提议的没有为新许可证付费？）

【解决方案5】：

为了方便搜索此内容的任何人，如果您仍在使用 Navision 6 和本机数据库，连接它的好方法是通过 Windows 消息队列。

您可以编写自己的 Web 服务，将 XML 请求放入队列，然后等待回复弹出。在 Navision 方面，您有一个客户端拉队列并将答案放入回复队列。有一个特殊的非 GUI 客户端，称为 NAS。

15 年来，我一直在使用这种方法将预订引擎连接到 Navision 后端。它工作得非常好，并且优势在于您可以在请求到达 Navision 之前查看它们，因此您可以保护后端免受过多或错误请求的影响。

这种方法的唯一问题是 Navision 中的 COMMIT 命令非常昂贵。很难处理大量请求。一旦后端需要提交，您每秒只需要几个请求。这对于低音量可能没问题。

对于大容量，您需要实现缓存或取出一些业务逻辑。对我来说，它受到价格比较网站的打击，所以这里的解决方案是为那些用 Python 编写的 Web 服务提供服务，并且只有在有人买东西时才传递请求......

【讨论】：