Biztalk 和 SSIS 之间的界限越来越模糊答案

【问题标题】：The blurring line between Biztalk and SSISBiztalk 和 SSIS 之间的界限越来越模糊
【发布时间】：2012-10-21 05:19:08
【问题描述】：

我正在构建一个从旧应用程序接收位置平面文件的应用程序，对于每个详细信息行，我需要在第三个应用程序中搜索一些数据，然后填写我的数据库。如果文件中有任何格式错误的行，我需要停止处理并记录格式错误的字符串的行和位置。

至少目前，这些文件最多。 50MB。

我很困惑谁最适合这种情况，Biztalk 和 SSIS 具有相似的功能，据我所知，两者都适合这种情况。这是一项我可以充分利用 Biztalk 的任务，或者我应该使用 ETL 解决方案（集成服务）？

【问题讨论】：

【解决方案1】：

我通常推荐 BizTalk 左、右和中，但在这种情况下，我会选择 SSIS，原因有两个：

在超过 50Mb 的文件上，无论您在 BizTalk 上投入多少资源（考虑到 BTS 处理文件中每条记录的方式），您都将从 SSIS 获得更好的性能。当然这里有一些策略，但是 SSIS 会胜出（尽管我想你的网络服务可能会成为你的瓶颈，不管你选择哪种解决方案）；和
除非您编写自定义的平面文件反汇编程序（这几乎是火箭科学，BizTalk 上帝的领域），否则标准反汇编程序将在到达格式错误的行时简单地停止，将错误记录到事件日志中并且没有将进行进一步的消息处理。

顺便说一句，我参与了太多项目，其中客户使用 BizTalk 编写的解决方案正在执行批处理操作。最初的开发和测试是在平面文件上完成的 c. 1Mb - 10Mb。当 50Mb - 100Mb+ 的文件需要这么长时间来处理时，客户就会感到困惑！

在项目开始时为问题选择正确的解决方案（恕我直言，SSIS）要好得多，而不是将解决方案强加到不合适的产品上。

【讨论】：

【解决方案2】：

我可能会在 SSIS 中这样做。它似乎是一个 ETL 工作。考虑到长期数据源，BizTalk 可能会为您提供更好的灵活性，但如果您说它是一个 Web 服务，那么这可以在 SSIS 中完成。

一般而言，SSIS = 批处理和直接数据翻译。 BizTalk = 可能需要同步也可能不需要同步的消息传递/横向系统请求/响应。

但不要相信我的话。包括工作量、软件成本（如果重要）以及此过程的寿命。

【讨论】：

是的，软件成本是一个问题，但公司愿意为 Biztalk 付费，因为他可以在比使用 .NET 从头开始做所有事情的时间更短的时间内解决问题。我将使用 SSIS 进行一些测试，看看是否可以解决问题。