エラー処理機能を使用すると、デザイナーは、失敗したメッセージを中断キューに配置する従来の (既定の) 動作の代わりに、メッセージング エラーの自動処理を指定できます。 この自動処理により、送信ポートやオーケストレーションなど、サブスクライブしているルーティング先にエラー メッセージがルーティングされます。 エラー メッセージは、以前に昇格されたすべてのプロパティが降格され、メッセージ コンテキストに昇格された特定のメッセージングエラーに関連する選択されたプロパティを含む元のメッセージの複製です。
Warnung
失敗したメッセージには、元のメッセージのコピーが含まれています。 元のメッセージに機密情報が含まれている場合は、誤って漏えいしないように、手動および自動で失敗したメッセージ プロセスを設計します。
失敗したメッセージ ルーティングは何で構成されますか?
失敗したメッセージ ルーティングが有効になっている場合、BizTalk Server はメッセージを中断せず、代わりにメッセージをルーティングします。 失敗したメッセージ ルーティングは、受信ポートと送信ポートの両方で有効にでき、結果は次のようになります。
受信ポートで失敗したメッセージ ルーティングが有効になっていて、受信パイプラインまたはルーティングでメッセージが失敗した場合、失敗したメッセージが生成されます。 逆アセンブル フェーズの前後にエラーが発生した場合、エラー メッセージは元のインターチェンジの複製です。
送信ポートで失敗したメッセージ ルーティングが有効になっていて、送信パイプラインでメッセージが失敗した場合、失敗したメッセージが生成されます。
失敗したメッセージが生成されると、BizTalk Server はエラー レポート関連のメッセージ コンテキスト プロパティを昇格させ、失敗したメッセージを発行する前に通常のメッセージ コンテキスト プロパティを降格します。 失敗したメッセージ ルーティングが有効になっていない場合の既定の動作 (失敗したメッセージは中断されます) と比較します。
どのような種類のメッセージング エラーによってエラー メッセージがトリガーされますか?
アダプター処理、パイプライン処理、マッピング、またはメッセージ ルーティングで発生したエラーは、失敗したメッセージのルーティングが有効になっている場合にエラー メッセージになります。 オーケストレーションが受信ポートから受信中または送信ポートへの送信中にメッセージング エラーが発生した場合、結果のエラー メッセージは、オーケストレーションがバインドされているメッセージング ポートに関連付けられます。
エラーメッセージの購読
エラーメッセージは、それらを受信するようサブスクライブされたオーケストレーションや送信ポートに配信されます。 通常、サブスクリプションは、メッセージング エラーが発生したポートの名前 (送信ポートまたは受信ポート) に基づいてエラー メッセージを選択します。 サブスクリプションは、エラーのメッセージ コンテキストに展開された他のプロパティ ( InboundTransportLocation や FailureCode など) でフィルタリングすることができます。
エラー メッセージの仕様
エラー メッセージは、以前に昇格されたすべてのプロパティが降格され、一連のエラー固有のプロパティがメッセージ コンテキストに昇格された、失敗した元のメッセージの複製です。 以前に昇格したプロパティは、エラー メッセージを受信するように指定されていないサブスクライバーへの意図しない配信を回避するために降格されます。 エラー メッセージは、サブスクライバー (オーケストレーション、送信ポート、および送信ポート グループ) に配布するために発行されます。
エラー メッセージのコンテキストに昇格されるプロパティはすべて、BizTalk Server の ErrorReport 名前空間に該当します。 これらは次のとおりです。
| プロパティ名 | データの種類 | 昇格 | 説明 |
|---|---|---|---|
| エラーコード | xs:string | イエス | エラー コード。 BizTalk Server 管理コンソールで報告される 16 進数の値。 |
| 失敗カテゴリ | xs:int | イエス | このプロパティは使用されません。 その値は未定義です。 |
| 説明 | xs:string | いいえ | エラーの説明。 このメッセージング エラーに関してアプリケーション イベント ログに書き込まれるのと同じ診断テキスト。 |
| メッセージの種類 | xs:string | イエス | 失敗したメッセージのメッセージの種類。メッセージの種類が不確定の場合は空。 BizTalk Server では、メッセージの種類を使用して、メッセージを XML スキーマに関連付けます。 メッセージの種類は、スキーマ名前空間とスキーマ ルート ノードを連結することによって形成されます。 http://mynamespace#rootnode. 手記： メッセージの種類が特定される前に失敗したメッセージには、このプロパティが設定されていません。 |
| 受信ポート名 | xs:string | 受信処理中に (受信ポートで) エラーが発生した場合に昇格されます。 送信ポートでエラーが発生した場合は昇格されません。 |
エラーが発生した受信ポートの名前。 |
| InboundTransportLocation | xs:string | 受信処理中に (受信ポートで) エラーが発生した場合に昇格されます。 送信ポートでエラーが発生した場合は昇格されません。 |
エラーが発生した受信場所の URI。 |
| SendPortName | xs:string | 送信処理中に (送信ポートで) エラーが発生した場合に昇格されます。 受信ポートでエラーが発生した場合は昇格されません。 |
エラーが発生した送信ポートの名前。 |
| 出発輸送地 | xs:string | 送信処理中に (送信ポートで) エラーが発生した場合に昇格されます。 受信ポートでエラーが発生した場合は昇格されません。 |
エラーが発生した送信場所の URI。 |
| エラータイプ | xs:string | イエス | エラーに含まれるメッセージの種類を示します。 このプロパティには常に FailedMessage という値が含まれています。つまり、エラーには元の失敗したメッセージが含まれます。 |
| ルーティング失敗報告ID | xs:string | イエス | このプロパティは、ルーティングエラーが発生したときに BizTalk Server によって生成されるルーティング エラー レポートの ID を提供します。 ルーティング エラー レポートは、BizTalk Server によって生成および中断される特別なメッセージです。 このメッセージには本文はありませんが、失敗したメッセージのコンテキストが含まれています。 この ID を使用すると、エラー処理オーケストレーションまたは送信ポートで MessageBox データベースにクエリを実行し、ルーティング エラー レポートを処理できます。 たとえば、オーケストレーションでは、失敗したメッセージを取得した後にルーティングエラー レポートを終了できます。 |
| 故障時間 | xs:dateTime | 失敗の発生日時 | |
| エラーメッセージID | xs:string | ||
| フェイラーインスタンスID | xs:string | ||
| フェイリアアダプター | xs:string |
エラー メッセージの処理
エラー処理は、フィルターがエラー メッセージのメッセージ コンテキストに昇格されたプロパティと一致するオーケストレーションまたは送信ポート サブスクリプションによって指定されます。
セキュリティへの影響
元のメッセージに関連付けられた ID (受信パイプラインの解決パーティ ステージによって決定された最初の ID または最終的な ID) がエラー メッセージに割り当てられます。
承認されたサブスクライブ ポートとオーケストレーションへのメッセージの配信を制限するセキュリティ メカニズムは、エラー メッセージにも適用されます。
エラー メッセージをサブスクライブするが、適切な復号化証明書を使用して構成されていない送信ポートは、元のメッセージが BizTalk Server に入った受信パイプラインの復号化ステージの前または前に、メッセージングエラーの結果として発生するエラー メッセージを受信しません。 代わりに、失敗したメッセージは中断キューに配置されます。
アダプター メッセージングエラー
アダプターがメッセージを中断すると、エラー メッセージが発行されます。 メッセージが中断されていない場合、エラー メッセージは生成されません。
トランザクション受信パイプライン
トランザクション受信パイプラインが例外をスローした場合 (トランザクションが中止されることを指定している場合)、トランザクションは中止され、エラーメッセージが通知されます。
トランザクション受信パイプラインがメッセージを明示的に中断した場合 (MessageDestination = SuspendQueue を指定)、現在のトランザクションの続行が許可され (後続のステージで中止が指定されていない限りコミットされる可能性があります)、結果のエラー メッセージが発行されます。
Solicit-Response 送信ポート
要求メッセージがオーケストレーションから送信され、送信に失敗した場合、またはその応答が受信処理に失敗した場合、失敗したメッセージがルーティングされたかどうかに関係なく、オーケストレーションは例外を取得します。
solicit-response 送信ポートが要求応答受信ポートに接続されている場合、受信ポートは、失敗したメッセージがルーティングされたかどうかに関係なく、応答メッセージ (送信が成功した場合) または NACK (送信に失敗した場合) のいずれかを取得します。
One-Way 送信ポート
配信通知用に構成された送信ポートを介してオーケストレーションからメッセージが送信されると、オーケストレーションは、エラー メッセージがルーティングされたかどうかに関係なく、配信通知を受信します。 つまり、送信ポートは、処理中にメッセージングエラーが発生した場合でも、オーケストレーションの配信通知を生成します。 通知はポートへの配信を確認しますが、ポートを介した正常な処理には対処しません。
中断されたメッセージの再開
受信処理（受信アダプターによる処理からメッセージボックスへの配信直前まで）の過程で失敗し、そのエラーが処理されなかったほとんどのメッセージは、再開可能として保留されます。 ただし、双方向の受信ポートからの要求メッセージは、再開不可能として中断されます。
通常、メッセージは元の形式で中断されます (パイプライン処理の前と同様)。ただし、次の 2 つの例外があります。
パイプライン コンポーネントによって中断されたメッセージ。 BizTalk Server は、失敗したパイプライン コンポーネントに提供されたのと同じ形式で、この種類のメッセージを中断します。 メッセージが再開されると、同じパイプラインの先頭からパイプライン処理が行われます。 これは、元のエラーが発生したステージの前にあるパイプライン ステージのパイプライン コンポーネントが、そのメッセージを処理した元の形式とは異なる形式で "同じ" メッセージを処理するように準備する必要があることを意味します。
回復可能なインターチェンジの逆アセンブルからのメッセージ。その後、ルーティングが失敗します。 BizTalk Server は、この種類のメッセージを発行されたのと同じ形式で中断します。 これは、パイプラインの実行 後 のメッセージの形式です。 メッセージが再開されると、パイプライン処理がスキップされ、MessageBox データベースに直接発行されます。
中断（再開不可）のメッセージに至るシナリオ
再開可能としてメッセージを中断する方が一般的ですが、再開できないメッセージにつながるシナリオがいくつかあります。
パイプライン、マッピング、または転送で障害が発生した場合、失敗時に続行が有効になっている順序付き配信送信ポート。
順序付け配信受信ポートで、失敗した場合に再開できない場合にメッセージを中断するようにアダプターが構成されている場合。 たとえば、MSMQ アダプター設定 "On Failure" が "Suspend (non-resumable)" に設定されている場合、または MQSeries アダプターで "Suspend as Non Resumable" が有効になっている場合、失敗したメッセージは再開不可として中断されます。
双方向の受信ポートで、パイプライン、マッピング、または送信で応答メッセージが失敗した場合。
双方向の受信ポートでは、パイプラインでの受信メッセージがマッピングまたは送信で失敗した場合に発生します。 個々のアダプターの動作が異なる場合があります。 たとえば、HTTP アダプターは既定ではメッセージを中断しませんが、そのように構成できます。