アダプターによるサイズの大きなメッセージの処理方法

BizTalk メッセージング エンジンでは、サイズが非常に大きいメッセージを処理でき、メッセージの最大サイズに制限はありません。 ただし、最適なパフォーマンスとリソース管理を維持するにはメッセージ サイズの制限を考慮する必要があります。 メッセージ サイズが大きくなると、1 秒あたりの処理メッセージ数は減少します。 シナリオを設計し、容量を計画するときに、BizTalk Serverによって処理されるメッセージの平均サイズ、メッセージの種類、メッセージ数を考慮してください。

ストリーム ベースの処理

アダプターの開発時にサイズの大きなメッセージの処理を考慮することは重要です。 サイズに関係なくデータ ストリーム全体をメモリに読み込むことは、BizTalk Server の処理が停止する可能性があるのでお勧めできません。 BizTalk メッセージング エンジンで処理されるメッセージのサイズと数によっては、仮想メモリが不足し問題が発生します。 メッセージは全体をメモリに読み込むのではなく、次のようにストリーム方式で処理してください。

• 受信メッセージ : 受信メッセージの場合、受信アダプターではネットワーク ストリームを BizTalk メッセージに関連付け、ストリームの "抽出" は BizTalk メッセージング エンジンで行います。

• 送信メッセージ : 送信メッセージの場合、ストリームの抽出はアダプターで行います。 この方法により、メッセージ ボックス データベースから送信パイプラインを介して効率的にストリームが抽出されます。 さらに、アダプターから外部にストリーム方式でデータを送信します。

  次の図に、メッセージング エンジンの受信側におけるストリーム ベースの処理を示します。

  

  アダプターでは、メッセージング エンジンにメッセージを送信するときに、データ ストリームを BizTalk メッセージに関連付けます。 一部のアダプターでは、これはネットワーク ストリームの実装となります。 アダプターからメッセージが送信されると、メッセージング エンジンでは受信パイプラインを実行します。 パイプラインの実行中、データの変更を必要とするパイプライン コンポーネントによってメッセージが複製され、新しいメッセージのストリームが前のメッセージのストリームに結合されます。 パイプラインの実行後、メッセージング エンジンでパイプラインからメッセージを取り出し、そのメッセージのストリームを繰り返し読み込みます。 つまり、前のストリームの読み込みを呼び出し、その読み込みによってさらに前のストリームの読み込みを呼び出すという方法で、ネットワーク ストリームまでさかのぼります。 メッセージング エンジンでは読み込んだデータを定期的にメッセージ ボックスにフラッシュし、フラット メモリ モデルを維持します。

  トラブルシューティングのヒント: 送信側では、アダプターはストリームの読み取りを担当します。 送信パイプラインによって昇格または書き込みが行われるメッセージ コンテキスト プロパティを、送信アダプターが読み込む場合、これらのプロパティはストリーム全体が読み込まれるまで書き込まれません。 ストリームが完全に読み込まれて初めて、アダプターではすべてのパイプライン コンポーネントの実行が完了したことを確認できます。

ストリーム内の特定バイトの指定

シナリオによっては、エラーによって中断されるメッセージを処理するために、アダプターが、ストリームを先頭方向に向かって検索する必要があります。 この例として、チャンク エンコードを使用してデータを受信し、送信請求 - 応答の組み合わせで応答メッセージを送信する HTTP アダプターがあります。

ただし、多くのシナリオではデータ ストリームを追跡できません。 たとえば、チャンク エンコードを使用してデータを受信する HTTP アダプターの場合、 エラーが発生したメッセージを検出できるようデータ ストリームを設計するには、アダプターでデータを読み込むたびにメモリまたはディスクにキャッシュする必要があります。 これは明らかに最適な処理でなく、余分なリソースを必要とします。 また、追加設定なしで使用できるパイプライン コンポーネントの多くは順方向専用のストリーミング方式で動作します。 これらのシナリオでは、SDK の BaseAdapter は VirtualStream というヘルパー クラスを使用します。 この機能を含むファイルは VirtualStream.cs という名前で用意されています。

仮想ストリームは、ストリーム内のデータをしきい値までメモリ ストリームにキャッシュし、しきい値を超えた分を安全なディスク上の場所にオーバーフローさせるという概念に基づいています。 ストリームが閉じられると、ディスク上のオーバーフロー ファイルは自動的に削除されます。 順方向専用のストリームはこの方法で設計できます。