2

我的公司正在探索将 BizTalk 用于我们的消息传递基础架构，我只是好奇它是否会是一个好的候选者。

首先，我们是一家 .NET 商店，负责处理医疗事务处理。目前，我们所有的产品都是为了实现它们的目的而编写的，实际上没有通用代码。这些事务中的大多数来自标准 TCP 套接字（想想使用 MLLP 作为模型的 HL7）。然后我们处理这些并可能将它们发送给一个或多个第 3 方以通过套接字进行处理。最后，我们将交易响应发送回客户。我们有很多像这样运行的应用程序，我们希望将其放在一个统一的平台上。

我们需要它以非常快的速度运行（在某些情况下小于 6 秒），并且在扩展时具有非常高的容错能力。有人告诉我，这是 BizTalk 擅长的地方。

我的问题是给你们 BizTalk 专家，这听起来像是 BizTalk 可以做得很好吗？对于这样的迁移，您还有什么其他建议吗？

4

1 回答 1

6

FWIW，我的看法：

Biztalk 优势 wrt 您的要求

  • 消息映射很简单，您可以选择可视映射或 xslt。
  • 开发的统一性——一旦你的开发团队克服了学习曲线，它就可以为大多数类型的 EAI 工作提供一个集中的平台（即你可以不断地向你的 Biztalk 服务器添加新的应用程序，这可以利用现有的消息和流程）。
  • 事务可靠性 - 您几乎可以拔掉 BizTalk 的插头，它在恢复状态方面做得很好，而不会丢失数据。
  • 协议不可知论 - 内部一切都是 XML 到 Biztalk。您可以使用开箱即用的各种适配器来处理“特殊需求”客户，而无需重写您的应用程序。
  • 低维护操作——一旦您部署和调试了您的应用程序，调整了您的生产环境，并设置了 SQL 和监控（例如 SCOM）维护任务，BizTalk 就可以像一个设备一样运行。
  • 可扩展性（有代价）- BizTalk 有很多用于扩展的旋钮，并且可以添加多个服务器以进行扩展。但是，在大多数情况下，我们通常发现瓶颈是底层 SQL Server。

弱点

  • 保证延迟/最大处理时间将面临一些挑战。例如，当 BizTalk 处于极端负载下时，需要认真考虑以避免可能导致消息积压排队的节流状态。
  • 动态路由在某些协议/适配器上有点不完整 - 如果您使用过滤器管理大量静态发送端口变得笨拙，您通常需要混合一些自己的代码。例如，如果您有 100 个第三方目的地 [比如资金] - 和 10 000 个客户 - [比如医生/医院]，那么将源自资金的消息流路由到医生不会很有趣。如果您可以保持消息流源自“多”端，并使用同步协议，则可以避免路由问题。

FWIW 我在医疗环境中使用过 BizTalk（但在基金方面，不是交换机），没有太多挑战（也就是说，我们只需要路由到 3 个不同的交换机）。我猜您的 <6 秒要求是实时药房身份验证等。我要做的一件事是将实时处理和批处理（例如索赔批次）拆分到不同的进程主机，甚至完全不同的服务器上。这应该避免由于可能不具有相同的低延迟要求的大批量（例如索赔）的到达而导致同步处理（例如药品身份验证）延迟的可能性。

于 2012-07-17T04:15:49.347 回答