5

レガシーアプリケーションからポジショナルフラットファイルを受信するアプリケーションを構築しています。詳細行ごとに、3番目のアプリケーション内でデータを検索してからデータベースをいっぱいにする必要があります。また、ファイルに不正な形式の行がある場合は、処理の停止を停止し、不正な形式の文字列の行と位置をログに記録する必要があります。

少なくとも今のところ、ファイルには最大があります。50MB。

このシナリオに最適なのは誰なのか非常に混乱しています。BiztalkとSSISには同様の機能があり、私が見る限り、どちらもこのシナリオに適しています。これは、Biztalkをうまく利用できるタスクですか、それともETLソリューション（統合サービス）を使用する必要がありますか？

4

2 に答える 2

9

I am normally recommend BizTalk left, right and centre, however in this case I would go with SSIS for two reasons:

  1. On a file 50Mb plus you will get much better performance out of SSIS, no matter how many resources you throw at BizTalk given the way that BTS will process each record within the file. There are strategies here of course, but SSIS will win hands-down (Although I would imagine you web-service will probably be your bottleneck irrespective of which solution you choose); and

  2. Unless you write a custom flat-file disassembler (which is almost rocket-science, BizTalk God territory), the standard disassembler will simply stop when it reaches a malformed line, logging the error into the Event Log and no further message processing will take place.

As an aside, I have been dropped into far too many projects where customers have a solution written in BizTalk where batch operations are being performed. The original development and testing was completed on flat-files c. 1Mb - 10Mb. Customers are then confused when a 50Mb - 100Mb+ files take so long to process!

Its much better to choose the right solution to the problem (IMHO, SSIS) at the beginning of the project, rather than crowbar a solution onto a product that isn't suitable.

于 2012-11-01T11:42:27.073 に答える
8

私はおそらくSSISでこれを行うでしょう。ETLジョブのようです。BizTalkは、データのソースを長期的に考えると、より優れた柔軟性を提供する可能性がありますが、Webサービスである場合、これはSSISで実現できるものです。

一般的に言えば、SSIS=バッチプロセスと直接データ変換。BizTalk=同期する必要がある場合とない場合があるメッセージング/水平システム要求/応答。

しかし、私の言葉を信じないでください。労力、重要な場合はソフトウェアコスト、およびこのプロセスの寿命を含めます。

于 2012-10-31T17:45:08.297 に答える