去赏金!

这个问题为我赢得了一个滚珠徽章(7天内7次观看!),这是一个有力的确认,即 Navision 市场份额非常有限,我怀疑这应该是确认Navision既不是那么出色的软件。

但是,嘿...这就是我们作为后端所得到的,所以我准备与此战斗。 :-o

如果有一些大胆的Navision开发人员能够将其阐明……赏金适合您! :)


原始帖子

我最近实施了一个相当复杂的电子商务系统,该系统与基于Navision 5的旧式后端进行交互不幸。

我们的需求是:

  1. 揭示业务逻辑的某些元素 每个平台到另一个平台(例如:“该客户购买的总金额是多少?”,“当前提供的产品是什么?”,“网站上有多少新客户注册?”,等等。 ..)。
  2. 有饲料 /验证的机制 对于各种交易(例如:“这是客户x“ ...”的新订单,好的,现在开始处理订单。
  3. 如果可能的话, 避免玩文件, ,但是将所有这些都以呼叫/端口/服务来进行...

我能想到的最自然的方法是通过WebService整合两个系统,但是Navision 5并不能本地支持这一点。所以我做了我的“尽职调查”,并在MSDN上找到了一些事情 本文另一个.

根据这些文章 在Navision 5上创建Web服务不应该那么困难, ,但是当我向负责传统系统的团队提出这种解决方案时,他们告诉我们这是“纯粹的理论”,他们不知道任何实施它的人。

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

因此,我的问题是双重的:

  1. 有人有 在家尝试了 如果最终结果是可靠的,如果他们认为结果值得付出的努力等,可以分享最大的困难,如果他们的最终结果是可靠的,等等?
  2. 是否有人面临类似问题,但以不同的方法解决了问题,并且可以提出他们的解决方案(“我从来没有做过,但是如果我必须这样做,我会这样这样做...”答案也欢迎)?

预先感谢您的宝贵时间! :)

有帮助吗?

解决方案

我也会对NAV 6的不太有用的答案提出来::)

我刚刚使用NAV 6完成了一个项目。令人惊讶的是,网站服务非常容易曝光和消费。在网络服务界面中找到一个对象并勾选一个框以告诉它自己露出自己,这确实是一个琐碎的事情。

毫无疑问,网络服务无法按照您的期望工作,您必须经常使用一些反复试验才能使对象和属性持续存在,因为它对您用于保存和对象的事件的顺序真的很敏感。而且每个对象的工作方式似乎略有不同。例如:要创建客户,我最终发现您必须创建和保存一个空白的客户,用CodeUnit按摩此新记录,然后获取记录,然后编写客户的属性并再次保存。我 预期的 要创建一个新客户(),请设置属性,然后将其保存为快速。

我想您不太热衷于升级到NAV6,但是在我的头顶上,这就是您可以模拟Web服务的方式:

SharePoint已经可以消费并公开网站服务,因此层次不是问题。 NAV 5没有“自然”,但是您可以烹饪自己的程序,该程序充当网络服务“经纪人” - 您已经大多是通过XML将信息收到和从NAV中获取。您可以构建此经纪人以作为XML文件进行输入,并按摩它们在Web服务调用中使用。您甚至可以放弃XML并直接从数据库写和读取,因为无论如何所有导航信息都存储在那里。所以这就是我的想法:

NAV <-> SQL Server <->新的'Broker'WebService <-> SharePoint

或者,如果您已经将NAV API放下PAT,并且要重置您的XML:

nav <-> XML文件<->新的'Broker'WebService <-> SharePoint

如果您使用的是XML并使用文件观看者,则延迟不太糟糕,通常是文件观察者在滴剂上捡起或更改毫秒。

嗯,但我想你是 大概 应该将BizTalk用于此类内容:NAV <-> Biztalk <-> SharePoint

但是我不知道设置BizTalk与NAV通信会有多容易。我敢打赌,让Comms工作非常直截了当,但这是猜测。

无论如何,我不知道这篇文章有多帮助,但是也许它给您一些想法。

欢呼,长矛

其他提示

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

您是否尝试在mibuso.com上询问?他们更加注重海军。

当您说公开业务逻辑时,是否包括执行AL代码(例如代码unit)?如果您只需要针对数据库执行查询,则可以使用nodbc&system.data.odbc或cfront .NET API。这些都可以使用.NET Web服务轻松包装,并且两者都支持本机NAV数据库。要传递消息,您仍然需要使用COM,如您提到的第一篇文章所述。

以上任何一种都是完全可能的,并且相对容易取决于您在.NET,COM和NAV中的熟练程度。

您链接到的第二篇文章使用NAS进行了描述。我不是专家,但我认为这可能需要特殊的许可颗粒。在花费时间实施任何内容之前,值得检查您的许可证包括NAS,CFRONT还是NODBC。

您实际上可以对NAV 5进行“技术升级”到NAV 2009,然后使用本机Web服务。意思是替换EXE文件和整个应用程序(但不是对象,它仍然是版本5),以及其他几个技巧。但是它有效,因此您在NAV上有2009-Webservice-unctionality 5 :-)

为了使任何谷歌搜索的人受益,如果您仍在Navision 6中使用本机数据库,则通过Windows消息队列连接它的好方法。

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

我使用这种方法已有15年了,将预订引擎连接起来,以消除Navision后端。它运行良好,并且具有您可以在到达Navision之前先窥视请求的优势,因此您可以保护后端免受太多或错误的要求。

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

对于大批量,您需要实现缓存或获得一些业务逻辑。对我来说,它受到价格比较网站的打击,因此,在这里,解决方案是为python编写的Web服务提供的服务,只有在有人购买东西时才通过请求传递...

许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top