これが私のシナリオです。BizTalk は、共有/中央ドキュメント ライブラリからファイルを転送する必要があります。まず BizTalk は、ライブラリ内のこのドキュメントへの参照/パスを含む受信メッセージを受信します。次に、このライブラリからそれを読み取って送信する必要があります (場合によっては別のアダプターを介して)。これは本質的に、ClaimCheck EAI パターンからそれほど離れていないシナリオです。
クレーム チェックを実装するいくつかの方法が文書化されており、特にBizTalk ESB ツールキット クレーム チェックと BizTalk 2009: 非常に大きなメッセージの処理、パート I およびパート IIです。ただし、これらの実装では、送信パイプラインが「チェックイン」されたストリームをすぐに読み取ることができるという前提があります。</p>
これは私の場合ではありません。ドキュメントが共有ライブラリで利用可能になるまでには時間がかかるため、最初に受信したメッセージを遅らせることはできません。つまり、オーケストレーションを介して遅延を導入するか、ドキュメントがまだ存在しない場合に送信ポートが後で再試行されるようにするかの 2 つのオプションがあります。
(遅延はオーケストレーションによってのみ導入できます。BizTalk には時間ベースのサブスクリプションはありません。そうですか?)
これはメッセージのみのフローなので、オーケストレーションをスキップできると思います。「パイプラインを使用したメッセージのみのソリューションでカスタム再試行ロジック」を使用する方法を見てきましたが、必要なのは、(アダプターによって実行される) 再試行動作を制御する方法だけでなく、パイプライン内からそれを強制する方法でもあります。 …</p>
これまでに行ったすべての試みは、送信アダプターに再試行が構成されていても、自動的に再試行されない中断されたメッセージで終わりました...これが実際に可能である場合、どこで/何をすべきですか?
そうそう…そして待ち行列があります…残念ながらオンプレミスでもクラウドでもありません;)
OK、私は限界を押し広げているかもしれません…しかしただの好奇心から…</p>
あなたの助けと提案に感謝します!