我应该使用 BizTalk Orchestration答案

【问题标题】：Should I use BizTalk Orchestration我应该使用 BizTalk Orchestration
【发布时间】：2014-07-11 18:05:51
【问题描述】：

我目前正在将现有应用程序 (BizTalk 2004) 移植到更新版本的 BizTalk。当前的解决方案采用多种类型的 EDI 文档，在必要时对其进行修改，然后将其发送到我们的旧系统进行加载和处理。

此过程是使用接收端口、管道组件、发送端口和映射、模式和消息队列组件的组合开发的。该解决方案使用 10 个发送和接收端口来处理流程的各个方面，例如将 EDI 突发到单个消息中、转换消息、错误处理、EDI 验证和 EDI 消息批处理。 EDI的所有修改都是使用消息队列组件完成的。

此解决方案根本不使用编排。我正在考虑将当前解决方案实施为 BizTalk 业务流程。我已经阅读了一些有关编排的内容，并研究了一些示例应用程序。但是我仍然对使用编排有什么好处感到非常困惑，如果没有它就可以开发解决方案。我确定我在这里遗漏了一些东西。编排提供了哪些当前解决方案没有的额外好处？

编辑：...我应该澄清这个问题...我可以在不使用基于内容的路由和地图的编排的情况下执行此应用程序。我的问题是，如果我因为不使用 Orchestration 而遗漏了什么？

【问题讨论】：

您能否描述“使用消息队列组件完成 EDI 修改”的意思？消息队列通常只是一种传输机制。
Biztalk 将映射应用于 EDI 文档，它只是一个 XML 包装器。然后将转换后的 xml 发送到 Microsoft 消息队列。队列后面的组件（只是一个.net dll）会根据业务规则修改文档并发回biztalk进行批处理
所以您打算用本机 BizTalk 应用替换 .dll？
根本没有...DLL 将保留在原处

【解决方案1】：

如果您可以使用基于消息的路由来执行您手头的任务，那么编排就太过分了。
编排将帮助您调用规则或处理事务。以下几点可以帮助您决定是否使用编排：

引用“Microsoft BizTalk Server Pattern”

编排需要付出可观的成本。其中许多成本表现为消息框的往返，这意味着跨越进程边界并写入和读取数据库 - 消息框

对于同一流程，编排可能需要两倍的时间。例如：一个接收和发送消息的简单过程将使用消息传递方法进行 2 次消息跃点，而使用编排则需要 4 次。以下是仅消息传递解决方案的步骤

对比：

编排方法的步骤

明智地选择

【讨论】：

【解决方案2】：

听起来您可以在仅消息传递的解决方案中重新实现该解决方案，并且不需要编排。如果可以，那就太好了，我们更喜欢消息传递，因为它们更易于维护且通常更高效。如果您需要一个包含多个操作的工作流，或者需要使用仅消息传递解决方案无法轻松完成的特殊错误处理，则编排非常有用。

【讨论】：