BizTalk是正确的解决方案吗？

Question

我们需要在大约六个系统（它们都是内部系统）之间发送数据。目前我们没有一致的方法来做到这一点。我们使用SSIS，SQL Server链接服务器直接更新数据库，ODBC连接直接更新数据库，文本文件等。

我们的目标是：

  

1）有一致的方式连接应用程序      2）有一种集中监控和记录连接的方法   应用。
     3）对于提供Web服务的应用程序我们   我想开始使用它们而不是直接使用connectiong   数据库。

无论我们使用什么，都需要能够连接到Web服务，数据库，平面文件，并且还应该能够通过tcp连接接受数据。

Biztalk是一个很好的解决方案吗，还是有点矫枉过正？

Answer 1

这取决于。对于您所描述的架构，它看起来非常合适。但是，您需要验证是否可以与您尝试集成的系统进行通信。例如;当这些系统使用Web服务，消息队列或基于文件的通信时，这可能是一个很好的选择。

当你从biztalk开始时，你必须愿意投资硬件，软件，最重要的是学习使用它。

关于你的观点： 1）是的，如果您确保正确封装系统连接器 2）是的，biztalk支持BAM 3）是的，这将完全匹配

Answer 2

根据您所描述的（6个系统），现在绝对是研究更正式的集成方法的好时机，因为您毫无疑问地发现在点对点/直接集成方法中将导致每个新系统都添加了大量的排列/意大利面条。

BizTalk支持hub and spoke, and bus type topologies（使用ESB工具包），其中任何一个都将减少系统之间的互连数量。

添加到oɔɯǝɹ：

1. 是的 - 最终BizTalk会在内部将所有内容转换为XML，您将使用可视地图或xslt在消息类型之间进行转换。
2. 是。开箱即用可以使用很多WMI和Perfmon计数器，而BizTalk有一个SCOM管理包来监控BizTalk的健康状况。对于您的应用程序，BAM（TPE用于简单监控，但更高级的东西可以通过BAM API完成）。
3. 是 - BizTalk支持所有常见的WCF绑定类型和基本的SOAP Web服务。 BizTalk的消息框可以用作发布/订阅引擎，它可以让您在稍后阶段将其他进程“挂钩”到消息中。

一些警告：

。 BizTalk应该用于消息（例如整个组织的电子文档），但不能用于批量数据同步。对于真正大型的数据传输/数据迁移/数据同步模式，SSIS是更好的选择。

。正如David指出的那样，BizTalk有一个陡峭的学习曲线，而且工具本身并不是免费的（需要SQL和BizTalk许可证，通常你也会想要使用像SCOM这样的监控工具。）。要快速跟踪这一点，您需要发送开发人员进行BizTalk培训，或者引入BizTalk顾问。

。 Microsoft似乎专注于Azure Service Bus，并且有speculation BizTalk将来会在某个时候合并到Azure Service Bus中。如果您的企业战略不完全是Microsoft，您可能还需要考虑EServiceBus和FUSE等产品用于ESB。

Answer 3

您的问题是典型的企业问题。公司开始建立隔离的应用程序，如人力资源，网络，供应链，库存，客户管理等多年，一旦他们达到一定程度，这些应用程序不能独自生活，他们需要相互交谈，通常他们开始一些黑客解决方案比如数据库级别的数据迁移。

但很快他们意识到问题就像没有明确的可见性，管理不善，没有标准等等，他们创造了一个真正的意大利面。最大的威胁是应用程序将彼此依赖，您将失去改变任何东西的敏捷性。对系统的任何更改都需要大量测试和较长的发布周期。

这是BizTalk Server等中间件平台为您解决的问题。线程中的很多回复都集中在BizTalk服务器的成本上（提到的一些成本是不正确的BTW）。它不是一个便宜的产品，但是如果你看一下它在你的组织中扮演的角色，作为一个连接所有应用程序的中央中间件平台和许多非功能性的好处，你可以像大多数第三方产品的适配器一样开箱即用如SAP，Oracle，FTP，FILE，Web Services等，能够轻松扩展您的平台，性能，长时间运行的工作流程，持久性，长期运行工作流程的补偿逻辑，限制您的环境等，很快成本因素就会降低。

我的建议是看看BizTalk，如果你是新手，那么请与当地的Microsoft办公室联系。他们可以帮助或推荐可以来分析您的情况的伙伴。