1

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

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

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

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

4

2 回答 2

3

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

  1. 是处理事务性的
  2. 消息排序重要吗
  3. 您是否要使用业务规则处理消息
  4. 是否必须调用外部程序集

来自“Microsoft BizTalk Server Pattern”的引述

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

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

  1. 通过适配器接收消息保存到消息框
  2. 检索发送端口的消息

与：

编排方法的步骤

  1. 通过适配器接收消息并保存到消息框
  2. 检索消息以启动编排
  3. 如果需要，请进行映射
  4. 再次检索发送端口的项目。

做出明智的选择

于 2014-05-22T20:50:42.927 回答
1

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

于 2014-05-22T20:49:34.567 回答