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

Question

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

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

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

2. 我们是否应该在 BizTalk 可以使用的库中构建简单的 Web 服务？

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

Answer 1

当您直接写入第三方数据库（尤其是您无法控制的数据库）时，您将集成解决方案与该外部系统紧密耦合。第三方合作伙伴或供应商不会在设计数据库时考虑到您，并且不会在意何时更改其数据库并破坏您的集成。

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

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

但是，如果您需要从订单输入系统转换到无数订单管理系统，每个系统都有自己独特的架构，那么 BizTalk 可能适合您，因为它具有成熟的数据转换映射 工具。

在 BizTalk 之上公开 Web 服务，只是为了给您的订单输入系统提供一种与 BizTalk 通信的方式，也可能不是最佳选择。BizTalk 使用它的适配器支持许多通信协议，并且 SOAP 或 WCF Web 服务可能相当健谈，并且在发送者尝试发送消息时要求接收系统在线。对于同一网络上的系统，MSMQ通常更有意义，因为它支持异步、事务性消息传递并且随 Windows 免费提供。

正如本白皮书所说：

从客户管理到订单管理下订单的关键要求是保证交付，因此我们可能会使用一些排队技术（例如 IBM MQSeries 或 MSMQ）来交付消息，其中以性能换取更高级别的可靠性。

掌握MSMQ 的工作原理以及其中的一些陷阱非常重要：

• 存储注意事项
• 从不从远程消息队列中读取
• 集群 MSMQ 使其真正具有容错性

...因此请花时间了解解决方案中的所有内容如何协同工作，即使您发现让 .NET 应用程序通过 MSMQ 发送消息相当简单。

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

• 尝试仅使用MessageBox Direct Bound Ports。它们“产生更独立的编排，因此更可重用且更容易独立重新部署。”
• 按照您自己的建议使用规范模式。是个好主意。
• 抵制将您的编排直接公开为 Web 服务的诱惑。当您这样做时，您将 Web 服务的外部调用者与内部业务逻辑紧密耦合。
• 将您的业务逻辑（编排）与数据（模式）分开。在业务流程中嵌入 BizTalk 地图可以将您的逻辑和数据结合在一起。而是在发送/接收端口上配​​置您的地图。
• 想想你是否真的需要使用编排。如果您所做的只是接收消息、对其进行转换并将其发送出去，那么您可能不需要编排。优化编排性能的第一条规则是消除编排。

如果您遵循上述建议，那么使用WCF SQL 适配器写入第三方 SQL 数据库并不算太糟糕，因为您将入站消息及其处理与出站 SQL 操作分离。当合作伙伴/供应商确实更新其数据库架构以破坏您的集成时，只需部署一个新架构、更新您的 BizTalk 映射并重新部署。隔离此类更改的影响意味着您只需重新测试从规范模式到外部数据库模式的转换（可能需要进行将数据保存到数据库中的集成测试）。

使用 WCF SQL 适配器执行CRUD 操作非常简单。如果供应商确实提供了 API，那么换出不同的 BizTalk 适配器来处理通信协议，更新您的架构/映射，并且您的订单发起系统永远不需要知道其中的区别。

Answer 2

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

但是，如果您真的无法在公司内部销售排队解耦策略，并且他们仍然一心想要通过 SQL 直接耦合到 3rd 方系统，那么您应该考虑以下几点：

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

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

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

这里有一篇关于编写一个好的“拉数据”过程的好文章。