各店舗が 1 日の終わりに毎日の取引をバックエンド システムに報告する小売シナリオ。現在、毎日の取引とその他のメタ情報で構成されるファイルが、FTP を使用してストアからバックエンドに転送されます。私は現在、FTPを別のものに置き換えることを調査しています。MSMQ は、代替トランスポート メカニズムとして提案されています。だから私の質問は、毎日のトランザクション ファイルをメッセージ オブジェクトに貼り付けて途中で送信するカスタム Windows サービスを作成する必要がありますか、それとも MSMQ にこれを処理するための既成のメカニズムがありますか?
また、転送したいファイルは大規模なストアでは 5 ～ 6 Mb に達する可能性があるため、MSMQ を除外する必要がありますか? その場合、私たちが調査すべき他の提案された技術はありますか?
乾杯！
IBM Sterling Managed File Transferおよび WebSphere MQ Managed File Transfer 製品を見ることができます。
メッセージング機能とファイル転送機能の両方が必要な場合は、WebSphere MQ MFT を検討できます。一方、要件がファイル転送だけの場合は、Sterling MFT を検討できます。
メッセージングトランスポートを介してファイルを送信することは簡単ではありません。ファイル全体を1つのメッセージにまとめると、必要なアトミック性を得ることができますが、メッセージサイズのばらつきが大きくなるようにメッセージングプロバイダーを調整するのは難しい場合があります。すべてのファイルのサイズがほぼ同じである場合、メッセージごとに1つが最も簡単な解決策です。
一方、ファイルを複数のメッセージに分割することはできますが、正しい順序で再構築する必要があります。欠落しているセグメントを検出して再送信するためのプロトコルを含め、受信したファイルと送信したファイルの整合性を確認します。 。また、送信中に両端のファイルが変更されていないことも確認する必要があります。
これらのシステムのいずれでも、通常および例外の条件下でファイルの送受信の処理を管理したり、転送をログに記録したりするのに十分なスマートなシステムが必要です。
したがって、メッセージングに移行するかどうかを検討する場合、2つの最良のオプションは、メッセージングにネイティブに移行してファイルを完全に放棄するか、選択したメッセージングプロバイダー上で実行されるエンタープライズマネージドファイル転送ソリューションを使用することです。既成のMFT製品はどれも、堅牢な例外処理とレポートを使用して正しく実行したい場合、自分で開発するほど長期的にはコストがかかりません。
店舗が別のネットワーク上にあり、インターネット経由で通信している場合、MSMQ は実際には選択肢になりません。NServiceBus はゲートウェイの概念を提供し、 HTTP または HTTPS を介して MSMQ メッセージを非同期に転送できるようにします。