实时消息传递的BizTalk

Question

我的公司正在探索使用BizTalk作为我们的消息基础设施，我只是好奇它是否是一个好的候选人。

首先，我们是一家.NET专卖店，进行医疗事务处理。目前，我们所有的产品都是为了实现自己的目的而编写的，实际上并没有通用代码。大多数事务都是通过标准的these (假设HL7使用MLLP作为模型)进行的。然后我们处理这些，并可能将它们发送到一个或多个第三方，以便通过套接字进行处理。最后，我们将事务响应发送回客户。我们有相当多的应用程序是这样运作的，我们正在寻找一个统一的平台。

我们需要这个操作非常快(在某些事情上小于6秒)，并且在缩放时非常容错。有人告诉我，这是BizTalk擅长的地方。

我的问题是，对于你们BizTalk专家来说，这听起来像是BizTalk能做得很好的事情吗？对于这样的迁移，你还有其他的建议吗？

Answer 1

我的看法是：

Biztalk优势w.r.t.您的需求

• 消息的映射非常简单，您可以选择可视化映射或xslt。
• 开发的一致性--一旦开发团队克服了学习曲线，它就为大多数类型的EAI工作提供了一个集中的平台(也就是说，您可以继续向Biztalk服务器添加新的应用程序，这可以利用现有的消息和进程)。
• 事务可靠性--您几乎可以拔掉BizTalk上的插头，这样就可以很好地恢复状态，而不会丢失数据。
• 协议不可知论-内部一切都是XML到Biztalk。你可以在不用重写应用程序的情况下，与“特殊需要”的客户打交道，有各种各样的适配器可用。
• 低维护操作--一旦您部署和调试了您的应用程序，调整了您的生产环境，并设置了SQL和监视(例如SCOM)维护任务，BizTalk就可以像设备一样滴答作响。
• 可伸缩性(按价格计算)-- BizTalk有大量用于扩展的旋钮，并且可以添加多个服务器以进行扩展。但是，在大多数情况下，我们通常发现瓶颈是底层Server。

弱点

• 在保证延迟/最大处理时间方面将面临一些挑战。例如，当BizTalk处于极端负载状态时，需要进行重要的考虑，以避免可能导致消息积压的节流状态排队。
• 动态路由在某些协议/适配器上有点零碎--如果您已经到了管理大量带有过滤器的静态发送端口变得难以处理的地步，通常需要将一些自己的代码混合在一起。例如，如果你有100个第三方目的地，比如基金--以及10000名客户，比如医生/医院，那么将资金来源于医生的信息流传递给医生并不是件有趣的事情。如果您可以将消息流保持在“多”端，并使用同步协议，则可以避免路由问题。

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