私の受信ポートは sqlBinding と型付きポーリングです。SP を呼び出してレコードをフェッチし、フィルター条件に基づいて、対応するオーケストレーションを開始します。BizTalk グループは 2 台のサーバーで構成されています。したがって、2 つの ReceiveHostInstances です。両方のホスト インスタンスが実行されている場合 (ある時点で同じ要求が 2 回読み取られている場合)、受信側で重複が発生します。しかし、reive ポートが同じレコードを複数回読み取るのはなぜですか? レコードを読み取る proc は、レコードを更新し、再度感染しないように更新します。
10 件のリクエストを送信しているときに、このシナリオを観察しました。受信ポートが 11 回読み取られ、11 個のオーケストレーションが開始されました。
1 つのホスト (私の Dev のように) で同じ (10 リクエスト) を試しましたが、受信は 10 のみを示しています。手がかりはありますか？
簡単な答えは、この問題を解決するには 2 つのオプションがあるということです。
以下は何が起こっているかの説明であり、その下に問題を修正するための実装の詳細を示します。
これは、BizTalk の受信場所が複数のホスト インスタンスで実行されている場合 (つまり、受信場所で指定されたアダプターの受信ハンドラーが、複数のホスト インスタンスを持つホストで実行されている場合) に動作する方法によるものです。
この状況では、両方のホスト インスタンスが受信ハンドラーを実行します。
通常、これは問題ではありません。ほとんどの受信アダプターはこれを管理し、期待どおりの動作を提供します。たとえば、ファイル アダプタは、読み取り中のファイルをロックして、二重読み取りを防ぎます。
これが問題である主な場所は、まさにあなたが見ているものです - ポーリング SQL 受信場所がストアド プロシージャにヒットしている場合です。この場合、BizTalk には、正しい結果を得るために SQL プロシージャを信頼する以外に選択肢がありません。
手順を見ずに判断するのは難しいですが、レコードをクエリする方法は、一意の読み取りを保証していません.
おそらくあなたは次のようなものを持っています：
Select * From Record
Where Status = 'Unread'
Update Record
Set Status = 'Read'
Where Status = 'Unread'
上記の手順では、select と update の間に、select の別の呼び出しが侵入し、まだ更新されていないレコードを選択できるため、レコードが重複する可能性があります。
この手順の簡単な修正方法の 1 つは、最初に一意の ID で更新することです。
Update Record
Set UpdateId = @@SPID, Status = 'Reading'
Where Status = 'Unread'
Select * From Record
Where UpdateId = @@SPID
And Status = 'Reading'
Update Record
Set Status = 'Read'
Where UpdateId = @@SPID
And Status = 'Reading'
@@SPID は一意である必要がありますが、そうでない場合は newid() を使用できます
新しいホストを作成するときに、BizTalk サーバーの管理コンソール内で、そのホストがクラスター化されていることを指定できます。これについての詳細は、Kent Weare によるこの投稿にあります。
基本的に、各サーバーにホスト インスタンスを使用して通常どおりホストを作成し、ホストを右クリックしてクラスターを選択します。
次に、そのホストで機能するポーリング用の SQL 受信ハンドラーを作成し、このハンドラーを受信場所で使用します。
BizTalk クラスター化されたホストは、そのホストのメンバーであるすべてのアイテムが一度に 1 つのホスト インスタンスでのみ実行されることを保証します。これには SQL 受信場所が含まれるため、プロシージャを呼び出すときに競合状態が発生する可能性はありません。