0

ストリーミング逆アセンブル受信パイプラインで大きなメッセージをデバッチするときに生成されるオーケストレーション インスタンスの数を制限する必要があります。100 000 の個別の「注文」メッセージを含む大きな xml が入ってくるとしましょう。受信パイプラインはそれをデバッチし、100 000 の「ProcessOrder」オーケストレーションを作成します。これは多すぎるので、制限する必要があります。

要件

  1. メッセージボックスに送信する前に、一度に 1 つの「注文」メッセージのみをメモリにロードするように、デバッチをストリーミング方式で行う必要があります。
  2. デバッチは、現在実行中の「ProcessOrder」オーケストレーション インスタンスの数に基づいて調整する必要があります (たとえば、実行中のインスタンスが既に 100 個ある場合、デバッチは、別の「Order」メッセージをメッセージ ボックスに送信するために 1 つのインスタンスが終了するまで待機します)。

私がいるところ

  1. メッセージのデバッチ処理と機能変更を行う受信パイプラインがあります。本来あるべきことをストリーミング方式で実行し、個々のメッセージを VirtualStreams に入れます。

  2. 「ProcessOrder」オーケストレーション インスタンスの数を制限できるオーケストレーション メソッドとヘルパー メソッドがあります。

問題

オーケストレーション内で受信パイプラインを実行できることはわかっています (そして、パイプラインへのすべての "getnext" 呼び出しで、実行中のオーケストレーション インスタンスが多すぎる場合はそのままにしておくことができるため、問題は解決します) 、biztalk dll を掘り下げるMicrosoft.XLANGs.Pipeline.XLANGPipelineManager を使用すると、Microsoft.BizTalk.PipelineOM.PipelineManager のようにすべてのメッセージを列挙するのではなく、メモリ内のすべてのメッセージが読み込まれることに気付きました。彼らがすべてのメッセージを VirtualStream に入れていることは知っていますが、このような大きなメッセージ数に対しては、メモリに関してはまだ不十分です。

質問

私の次のステップは、「ProcessOrder」インスタンスの数を制限するオーケストレーションを使用せずに、受信パイプラインを受信ポートで直接実行することです (したがって、Microsoft.BizTalk.PipelineOM.PipelineManager を使用します)。パイプラインに遅延ロジックを追加する必要があります。これは実行可能なオプションですか？そうでない場合、なぜですか？他にどのような選択肢がありますか？

4

1 に答える 1

1

パイプラインからすべてのメッセージを 1 回デバッチし、オーケストレーションによって処理される前に、これらの個々のメッセージを MSMQ に格納する必要があります。標準のパイプラインを使用してメッセージをデバッチします。これは、大きなファイルのデバッチを効率的に処理できるためです。MSMQ は、Turn On Windows Features から無料で入手できます。MSMQ の使用は非常に簡単で、開発は必要ありません。MSMQ への送信は非常に高速です。100K メッセージはまったく問題になりません。

次に、MSMQ から読み取る受信場所を用意します。オーケストレーションのスループットに応じて、BizTalk 受信ホストのスロットリングを使用するか、MSMQ からメッセージを順番に受信するか、または両方を組み合わせて使用​​することにより、メッセージ フローを制御できます。受信 MSMQ と送信 MSMQ の両方、およびオーケストレーション処理用に別のホスト インスタンスがあることを確認してください。

これは、設計を簡素化する余分なコードなしで、すべての構成を通じて行われます。最小数の永続ポイントでオーケストレーションがあることを確認してください。

于 2015-04-06T15:49:39.213 に答える