BizTalk实时消息传递

Question

我的公司正在探索使用BizTalk作为我们的消息传递基础设施,我很好奇它是否是一个很好的候选人.

首先,我们是.NET商店,并处理医疗事务处理.目前我们所有的产品都是为了达到目的而编写的,并没有通用的代码.大多数这些事务都来自标准TCP套接字(认为HL7使用MLLP作为模型).然后我们处理这些并且可以将它们发送给一个或多个第三方以便通过套接字进行处理.最后,我们将交易响应发送回客户.我们有很多应用程序都是这样运行的,我们希望建立一个统一的平台.

我们需要这个操作非常快(在某些事情上<6秒)以及在缩放时非常容错.我被告知这是BizTalk擅长的地方.

我的问题是BizTalk专家,这听起来像BizTalk可以做得好吗？您可以为此类迁移提供任何其他建议吗？

Answer 1

FWIW,我的看法:

Biztalk优势符合您的要求

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

弱点

• 保证延迟/最长处理时间会有一些挑战.例如,当BizTalk处于极端负载时需要给出重要的思考,以避免限制状态,这可能导致消息积压排队.
• 动态路由在某些协议/适配器上有点不完整 - 如果你到达使用过滤器管理大量静态发送端口变得难以处理的程度,你通常需要混合一些自己的代码.例如,如果你有100个第三方目的地[说资金] - 和10 000个顾客 - [说医生/医院],那么将来自资金的消息流路由到医生并不会很有趣.如果您可以保持消息流源自"多方",并使用同步协议,则可以避免路由问题.

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