0

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

我们的目标是：

1) 有一致的方式连接应用程序。
2) 有一个集中的方式来监控和记录应用程序之间的连接。
3) 对于提供 Web 服务的应用程序，我们希望开始使用它们，而不是直接与数据库连接。

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

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

4

3 回答 3

2

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

当您开始使用 biztalk 时，您必须愿意投资硬件、软件，尤其是学习使用它。

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

于 2012-08-23T21:15:28.460 回答
1

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

BizTalk 支持中心辐射型和总线型拓扑（使用 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 顾问。

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

于 2012-08-24T05:07:14.433 回答
1

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

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

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

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

于 2012-08-26T15:03:00.813 回答