我应该使用BizTalk直接连接到第三方数据库还是在它们之间构建一个单独的层？

Question

我在一家零售公司工作，我们希望建立一个统一的订单输入系统，该系统与仓库的订单管理应用程序集成。在非常高的层次上，我建议我们有一个BizTalk服务器，它向订单输入应用程序（或其他应用程序）公开统一的Web服务，并在传递请求之前使用规范的消息格式。规范消息将允许重用业务流程。

你能帮我理解这两个选项中哪一个最好：

1. 我们是否应该使用BizTalk SQL适配器连接到托管订单应用程序的数据库（它们根本不提供任何API，因为它们是第三方）从总部到仓库？

2. 我们应该在BizTalk可以使用的软件仓库中构建简单的Web服务吗？

我认为＃2是冗余工作，因为我们仍然需要在数据库记录和传入的SOAP消息之间进行转换（反之亦然）。然而，我的直觉中的一些事情告诉我们这不是一个坏主意。

Answer 1

当您直接写入第三方数据库时 - 尤其是您无法控制的数据库 - 您tightly couple您的外部系统集成解决方案。第三方合作伙伴或供应商在设计数据库时并不会考虑您，并且在更改数据库并破坏集成时无需关心。

如果您完全没有办法在第三方应用程序中存储/检索数据，除了直接与其数据库进行交互之外，您必须考虑如何以最大限度地减少数据的方式执行此操作。耦合。当然，让您自己的订单输入系统直接与第三方应用程序的数据库对话将是最糟糕的选择。

BizTalk使得在各种消息格式之间进行翻译变得相当容易。如果您只在您自己的订单输入系统和单个订单管理系统之间进行映射，那么BizTalk可能对您来说太过沉重。只需将您自己的接收应用程序写入第三方应用程序数据库顶部的站点。

但是，如果您需要从订单输入系统转换为无数的订单管理系统，每个系统都有自己独特的架构，那么BizTalk可能会很适合您，因为它已成熟mapping tool用于数据转换。

在BizTalk之上公开Web服务，只是为了让您的订单输入系统与BizTalk进行通信，也可能不是最佳选择。 BizTalk支持许多通信协议及其adapters，SOAP或WCF Web服务可以是chatty，并且要求接收系统在发送方尝试发送消息时处于联机状态。对于同一网络上的系统，MSMQ通常更有意义，因为它支持异步，事务性消息传递，并且免费提供给Windows。

正如this white paper所说：

  

从客户管理订单到订单的关键要求   管理是为了保证交付，所以我们可能会使用一些排队   技术（例如IBM MQSeries或MSMQ）在哪里传递消息   性能的交易具有更高的可靠性。

掌握how MSMQ works及其中的一些陷阱非常重要：

• storage considerations
• never read from remote message queues
• cluster MSMQ to make it truly fault tolerant

...所以请花点时间了解解决方案中的所有内容如何协同工作，即使您发现它是公平的trivial to make a .NET application send a message via MSMQ。

如果您仍然希望从BizTalk公开Web服务，请注意不要通过将发送和接收系统硬编码到单个业务流程中而无意中将所有内容耦合在一起。这是一些重要的

• 尽量只使用MessageBox Direct Bound Ports。他们"yield orchestrations that are more self-contained, and therefore more reusable and easier to redeploy independently."
• 按照您自己的建议使用规范模式。 It's a good idea.
• 抵制直接将业务流程作为Web服务公开的诱惑。当你这样做时，you tightly couple external callers of your web service to your internal business logic。
• 使您的业务逻辑（业务流程）与您的数据（架构）分开。在业务流程中嵌入BizTalk映射可将逻辑和数据结合在一起。改为在send / receive端口上配置地图。
• 考虑一下您是否真的需要使用编排。如果您所做的只是接收消息，转换它并将其发送出去，那么您可能不需要编排。 The first rule of optimizing orchestration performance is to eliminate orchestrations.

如果您遵循上述建议，那么使用WCF SQL adapter写入第三方SQL数据库也不错，因为您将从入站SQL操作中解除对入站消息及其处理的解耦。当合作伙伴/供应商确实更新其数据库架构以破坏您的集成时，只需部署新架构，更新BizTalk映射并重新部署。隔离这种更改的影响意味着您只需要重新测试从规范模式到外部数据库模式的转换（可能需要将数据保存到数据库中的集成测试）。

执行CRUD operations with the WCF SQL adapter非常简单。如果供应商提供了一个API，那么换掉一个不同的BizTalk适配器来处理通信协议，更新你的模式/地图，你的订单发起系统永远不需要知道差异。

Answer 2

Schellack关于可靠和异步耦合系统（例如通过队列）的观点将永远是IMO的第一名。

但是，如果您真的无法在公司内部销售排队解耦策略，并且他们仍然倾向于通过SQL直接耦合到第三方系统，那么您应该考虑以下因素：

• 使用WCF SQL Adapter
• 确保您不会通过直接访问数据库而取消供应商产品的任何保修或支持协议（尽管即使您编写了Web或Windows服务，如果没有API，最终也需要访问供应商数据库）
• 通过SQL存储过程和视图封装您对供应商数据库所做的任何访问，并确保您对数据库所做的任何更改都在您自己的database schema中 - 这样可以更轻松地识别对第三方的自定义修改系统，例如在升级第三方系统期间。
• 请注意，在高容量期间，BizTalk可能会对下游系统造成极大负荷。您将需要用于限制下游系统上的负载的机制，例如：通过调整适配器设置或在BizTalk中实现singleton / multitons。

从数据库中提取数据时也是如此：

• 封装proc中的pull，限制一次记录的数量（例如SELECT TOP *）并调整轮询频率。
• 在提取数据时，您还需要一种透明机制，将记录标记为read，而不会干扰第三方数据库。
• 为了提取数据，请记住将并发问题考虑在您的设计中，可以同时触发多个SQL Adapter实例（例如Poll While Data Found）

写一个好的'拉数据'过程有一个很好的写here。