我应该使用BizTalk Orchestration

Question

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

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

此解决方案根本不使用编排。我正在考虑将当前的解决方案实现为BizTalk编排。我已经阅读了一些关于编排的内容，并通过一些示例应用程序进行了操作。但是，如果可以在没有它的情况下开发解决方案，我仍然对使用编排的好处感到困惑。我相信我在这里遗漏了一些东西。还有什么额外的好处是当前的解决方案没有？

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

Answer 1

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

1. 处理交易
2. 消息的排序很重要
3. 您是否要使用业务规则处理邮件
4. 您是否必须致电外部装配

来自＆＃34; Microsoft BizTalk Server Pattern＆＃34;

的引用

  

业务流程费用相当高。其中许多成本表现为向消息框的往返，这意味着跨越进程边界并写入和读取数据库 - 消息框

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

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

VS

协调方法的步骤

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

明智地选择

Answer 2

听起来您可以在仅消息传递解决方案中重新实现解决方案，而不需要Orchestration。如果你能做到这一点很好，我们更喜欢消息传递，因为它们更易于维护并且通常更有效。如果您需要具有多个操作的工作流，或者使用仅消息传递解决方案无法轻松执行的特殊错误处理，则业务流程非常有用。