BizTalk Serverでのメッセージの順序指定された配信
メッセージの順次配送とは、特定の順序でメッセージ ボックス データベースに公開されたメッセージを、それぞれ対応するサブスクライバーに (メッセージ ボックスに公開されたときと同じ順序で) 配送することです。
メッセージの順次配送の構成
メッセージの順次配送は、次の場所で構成できます。
- オーケストレーションで図形を受信する
- 送信ポート
既存のトランスポートでの順次配送
トランスポートに使用されるプロトコルによっては、特に順次配送が必要ないものもあります (FILE や HTTP など)。 ただし、このようなトランスポートの場合でも、トランスポートにバインドされたポートが順序指定された配信用にマークされている場合、BizTalk Serverは、現在の送信メッセージが正常に送信されるまでトランスポートが次の送信メッセージを取得しないようにすることで、順序指定された配信を強制します。 この機能を実現するために、BizTalk Server は、各メッセージを 1 つのバッチとしてトランスポートのアダプターに渡し、アダプターがそのメッセージをメッセージ ボックスから削除するまで待機してから、次のメッセージを別のバッチとしてアダプターに配送します。
カスタム アダプターでの順次配送
カスタムの受信アダプターでは、特別に考慮しなければならない事柄があります。 順次配送をサポートするカスタム アダプターは、次のことを実行する必要があります。
メッセージのバッチを送信した後、カスタム受信アダプターは、次のバッチを送信する前に、BizTalk Serverからの BatchComplete コールバックを待機する必要があります。 詳細については、「 Batch-Supported 受信アダプターのインターフェイス」を参照してください。
メッセージの処理がパイプラインで失敗した場合、そのメッセージを保留 (できれば再開不可に) する必要があります。 BTS を使用します。メッセージに適切なフラグを設定するためのBizTalk Serverの SuspendAsNonResumable メッセージ コンテキスト プロパティ。
Note
保留したメッセージが後で再開されると、メッセージの順序が破綻してしまいます。 このような事態を避けるためには、失敗したメッセージを再開不可として保留します。
カスタム アダプターの構築の詳細については、「カスタム アダプターの 開発」を参照してください。
エンド ツー エンドの順次メッセージ処理を実現するための条件
エンド ツー エンドの順次配送を実現するには、次の条件を満たす必要があります。
メッセージは、BizTalk Server に送信するメッセージの順序を保持できるアダプターで受信されなければなりません。 BizTalk Serverでは、このようなアダプターの例として、MSMQ と MQSeries があります。 HTTP アダプターまたは SOAP アダプターを使用して、メッセージを順次配送することもできますが、その場合は、HTTP クライアントまたは SOAP クライアント側で、正しい順序が維持されるよう配慮する必要があります (メッセージを 1 つずつ送信する)。
[ Ordered Delivery]\(順序付き配信 \) オプションが に設定されている送信ポートを使用して、これらのメッセージをサブスクライブする
True必要があります。オーケストレーションを使用してメッセージを処理する場合は、オーケストレーションの 1 つのインスタンスのみを使用し、オーケストレーションをシーケンシャルコンボイを使用するように構成し、オーケストレーションの受信ポートの Ordered Delivery プロパティを に設定する
True必要があります。
制限
次の場合、メッセージの順序指定された配信はサポートされていません。
BizTalk Server 2013 R2 以前のバージョンの動的送信ポート
静的送信ポートでの順序指定された配信をサポートしていないアダプターの種類に対して、BizTalk Server 2016 (および新しいバージョン) の動的送信ポート
バックアップ トランスポート
操作
送信ポートに対して順次配送を構成する場合、他の設定との関係に注意する必要があります。
同じ送信ポートの "現在のメッセージが失敗したときに、後続のメッセージの送信を停止する" 設定
不正解です。 失敗したメッセージだけが (再開不可として) 保留にされ、以降のすべてのメッセージは引き続き処理されます。 これにより、失敗しなかったメッセージの順序は維持されますが、元の順序に抜けが生じることになります。 たとえば、101、102、103 という順序で受信され、102 が保留状態になった場合、101 と 103 については正しい順番で処理されます。
正解です。 いずれかのメッセージで処理が失敗した場合、送信ポートのインスタンスが保留状態になります。 これにより、順次配送の設定された、後続のすべてのメッセージが保留されます。 後続のメッセージが、失敗したメッセージよりも前に配送されることはないため、メッセージの順序は完全に維持されます。
送信請求応答送信ポートの "現在のメッセージエラー時に後続のメッセージの送信を停止する" プロパティが に
true設定されている場合、回復可能なインターチェンジ処理が応答の受信パイプラインの逆アセンブル ステージ用に構成されている場合、応答を逆アセンブルする際に回復可能なエラーがある場合、送信ポートはメッセージの送信を停止しません (つまり、インスタンスは中断されません)。順次配送の設定された送信ポートを削除する場合は、関連付けられたインスタンスが存在しないことを確認しておく必要があります。 関連付けられたインスタンスが存在する場合は、それを終了させてから、送信ポートを削除します。
ファイル トランスポートへの順次配送
ファイル アダプターには、メッセージが順に到着します。 ファイル アダプターでは、メッセージを単一のファイルに追加していくか、個別のファイルとして書き出します。
メッセージ データが単一のファイルに追加される場合、各メッセージは順番に追加されていきます。 ファイル アダプターを使用する送信ポートの順次配送オプションは、送信トランスポートが追加モードで動作している場合にのみ機能します。
メッセージが個別のファイルに出力される場合、その順番がファイル名に反映されます。つまり、到着した順番に基づいてファイル名が付けられます。 このとき、アダプターによって書き込まれたファイルでは、時系列 (ファイルの作成日時や更新時刻など) に関するファイル システムのプロパティには、メッセージが到着した順序は反映されません。
順次配送がパフォーマンスに与える影響
Note
BizTalk Server 2020 以降では、異なる送信場所で注文を維持する必要がない順序付き配信を使用する動的送信ポートでは、複数の送信ポート インスタンスを使用して異なる送信場所に送信されたメッセージを並列で処理することで、スループットを向上させることができます。
BizTalk Server は、順次配送を実現するために、メッセージ経路のさまざまな地点において、メッセージを順番どおりに処理する必要があります。 そのため、複数のホスト インスタンスを使用して、メッセージを並列処理するなどのスケール アウト手段が通用しなくなります。 順次配送を行う場合、複数のホスト インスタンスで動作するように構成されたポートであっても、複数のホスト インスタンスで実行させることはできません。順次配送を行うには、単一のホスト インスタンスで動作させる必要があるためです。 ただし、複数のホスト インスタンスの場合でも、高い可用性のメリットは享受できます。メッセージの順次配送を処理するホスト インスタンスで障害が発生した場合、処理に失敗したメッセージは利用可能な別のホスト インスタンスで再処理されます。
Ordered Delivery が有効になっている場合、既定の 再試行間隔 は 5 分です。 パフォーマンスを向上させるには、[再試行の間隔] を最小値 (1 分) に設定します。 Retry Interval プロパティは、0 (0) の値を受け取る場合がありますが、0 (0) は無効です。 再試行回数は、必要な再試行回数に合わせて調整することもできます。 たとえば、要求を 1 分で <処理する必要があり、送信ポートの宛先に常にアクセスできることがわかっている場合は、両方の値を 1 に設定します。
[再試行] の値を変更するには、 送信ポートのトランスポートの詳細オプションを構成する方法に関するページを参照してください。
順次配送の詳細については、次の情報を参照してください。
BizTalk: エンドツーエンドの順序付きメッセージ処理オプション