我的公司即将进行一个大型项目，在该项目中，我们的客户想要一个带有 cms、crm 实施的大型客户门户。这将需要与来自我们客户业务的多个来源的数据进行交互，这些来源包括 XML 办公后端系统、sql 数据库、Web 服务等。
我们建议的解决方案是用 c# 编写一个 API，为所有这些系统提供一个通用接口。这对于公司内部的未来和并发项目是可扩展的。
我们的客户表示有兴趣使用 Biztalk 而不是自定义 API 来进行此集成，因为他们认为这是一种企业解决方案，他们的任何供应商都可以选择和使用，并且会得到更好的支持。
我们认为使用 Biztalk 的配置工作对于他们所需的所有自定义业务规则来说是相当繁重的，并且仍然需要编写新应用程序从 Biztalk 获取数据的接口。
我们是否更喜欢 Biztalk 之上的自定义 API 解决方案？ Biztalk 是否适合作为数据代理层为我们正在编写的新客户门户提供接口。我们之前没有使用 Biztalk 的经验，因此我们将不胜感激。
【问题讨论】：
阅读您的要求，我想说您希望专注于业务核心部分。 IE。如何同时使用上述服务。您希望尽可能少花费的主题是“管道”。
BizTalk 服务器将为您省去大部分管道。而不是处理“如果规范化出错，如何保证一致性”，您将处理“如何规范化数据”。
BizTalk 也是非常“面向未来”的，因为您可以随时在 BizTalk 环境中添加/删除/更改系统，而无需“将其删除以进行更改”。 （当然在限制范围内，如果实施得当）。
我建议重新评估“自己动手”的方法，看看如果您要采用“自己动手”的方式需要付出多少努力。仔细查看“管道代码”与“核心能力代码”的数量。请记住，在编写之后，您必须对其进行维护/错误修复。 BizTalk 是一种经过验证的技术，可满足此类要求。
从上面的描述我会说； “BizTalk 可能是更好的选择”。
希望对你有帮助，
【讨论】：
在查看 BizTalk 的界面时，需要意识到一个主要事实；
'没有接口'
BizTalk 没有指定特定的接口。它允许您设置“命名消息交换模式”（如 Request-Response、OneWay 等）。
传入的消息“发布”到 BizTalk 中（通过我们所说的“接收端口”+“接收位置”组合）。您可以让 Orchestration（业务逻辑）或 SendPort（连接到外部系统->out）“订阅”消息。这种订阅可以基于上下文信息或内容信息（尽管后者需要将信息从消息内容提升到消息上下文）。
因此，BizTalk 允许您通过成为消息的“发布者”或“订阅者”在任何给定时间点连接到任何系统。这甚至可以在系统完全启动并在生产中运行时完成。
任何 BizTalk 项目仍然可以在许多位置使用完整的 .Net API，让您可以在 BizTalk 中编写“任何可以用普通 .Net 编写的任何内容”。
不过，我想建议一件事； “请确保您的项目团队中至少有一两个人将获得 BizTalk 加速/课程”。 BizTalk 就像一把暗枪；非常强大，但在坏人手中很危险。
【讨论】：