錯誤處理功能允許設計者將自動化處理訊息失敗指定為傳統（現在預設）行為的替代方案，即將失敗訊息放入暫止佇列中。 此自動處理將錯誤訊息路由至任何訂閱的路由目標，例如發送埠或編排。 錯誤訊息是原始訊息的克隆，所有先前已提升的屬性現已被降級，而引起特定訊息傳遞失敗的相關選定屬性已提升至訊息內容。
警告
失敗的訊息包含原始訊息的複本。 如果原始訊息包含敏感性資訊，請設計您的手動和自動失敗訊息程式，以避免意外洩漏。
失敗的訊息路由包含什麼？
啟用失敗的訊息路由時，BizTalk Server 不會暫停訊息，而是將訊息重新路由傳送。 在接收和傳送埠上都啟用失敗的訊息路由，結果如下：
如果在接收埠上啟用失敗的訊息路由，且接收管線或路由中的訊息失敗，則會產生失敗的訊息。 在拆解階段或之前發生錯誤時，錯誤訊息是原始信息的副本。
如果在傳送埠上啟用失敗的訊息路由，且傳送管線中的訊息失敗，則會產生失敗的訊息。
產生失敗訊息時，BizTalk Server 會升級錯誤報告相關的訊息內容屬性，並在發佈失敗訊息之前降級一般訊息內容屬性。 當未啟用失敗的訊息路由時，將此與預設行為進行比較：失敗的訊息會暫停。
哪種傳訊失敗會觸發錯誤訊息？
如果啟用了失敗訊息的路由，則在轉接器處理、管線處理、對應或訊息路由中發生的任何失敗都會產生錯誤訊息。 當協調流程從接收埠或傳送至傳送埠時發生傳訊錯誤時，產生的錯誤訊息會與協調流程所系結的傳訊埠相關聯。
訂閱錯誤通知
錯誤訊息會傳遞至協調流程，或傳送已訂閱接收它們的埠。 訂用帳戶通常會根據發生傳訊錯誤的埠名稱來選取錯誤訊息（傳送或接收埠）。 訂閱也可以篩選包含在錯誤訊息上下文中的其他屬性（例如 InboundTransportLocation 或 FailureCode）。
錯誤訊息規格
錯誤訊息是原始失敗訊息的複本，其中所有先前被提升的屬性都會被降級，而一組針對錯誤的特定屬性則會被提升到訊息內容中。 先前升級的屬性會被降階，以避免非預期地傳送至未被指定接收錯誤訊息的訂閱者。 錯誤訊息會發佈給訂閱者（協調流程、傳送埠和傳送埠群組）。
升級為錯誤訊息環境的屬性全都歸屬於 BizTalk Server 的 ErrorReport 命名空間。 它們如下：
| 屬性名稱 | 數據類型 | 促進 | 說明 |
|---|---|---|---|
| 故障代碼 | xs：string | 是的 | 錯誤碼。 BizTalk Server 管理控制台中報告的十六進位值。 |
| 故障類別 | xs：int | 是的 | 不會使用這個屬性。 其值未定義。 |
| 說明 | xs：string | 否 | 錯誤描述。 與針對此傳訊失敗寫入應用程式事件記錄檔的診斷文字相同。 |
| 訊息類型 | xs：string | 是的 | 失敗訊息的訊息類型，如果訊息類型不確定，則為空白。 BizTalk Server 會使用訊息類型，將訊息與其 XML 架構產生關聯。 訊息類型是由串連架構命名空間與架構根節點所組成： http://mynamespace#rootnode. 注意： 判斷訊息類型之前失敗的訊息不會設定此屬性。 |
| 接收端口名稱 | xs：string | 如果輸入處理期間發生失敗，則升級 （在接收埠中） 不會升級如果失敗發生在傳送埠中。 |
發生失敗的接收埠名稱。 |
| 入境運輸地點 | xs：string | 如果輸入處理期間發生失敗，則升級 （在接收埠中） 如果失敗發生在傳送埠中，則不會升級。 |
發生失敗之接收位置的 URI。 |
| SendPortName | xs：string | 如果輸出處理期間發生失敗，則升級 （在傳送埠中） 如果失敗發生在接收埠中，則不會升級。 |
發生失敗的傳送埠名稱。 |
| 出境運輸地點 | xs：string | 如果輸出處理期間發生失敗，則升級 （在傳送埠中） 如果失敗發生在接收埠中，則不會升級。 |
發生失敗之傳送位置的 URI。 |
| 錯誤類型 | xs：string | 是的 | 指出錯誤所包含的訊息類型。 此屬性一律包含 FailedMessage 值，這表示錯誤包含原始失敗的訊息。 |
| RoutingFailureReportID (路由失敗報告識別碼) | xs：string | 是的 | 此屬性提供 BizTalk Server 在發生路由失敗時所產生的路由失敗報告標識碼。 路由失敗報告是 BizTalk Server 產生和暫停的特殊訊息。 此訊息沒有內容，但它含有失敗訊息的相關內容。 使用此標識碼，錯誤處理協調流程或傳送埠可以查詢 MessageBox 資料庫並處理路由失敗報告。 例如，協調流程可能會想要在收到失敗訊息後終止路由失敗報告。 |
| 故障時間 | xs：dateTime | 失敗發生的日期時間 | |
| 錯誤訊息ID | xs：string | ||
| 故障實例ID | xs：string | ||
| 故障適配器 | xs：string |
處理錯誤訊息
錯誤處理是由協調流程或傳送埠訂用帳戶所指定，其篩選符合已升階為錯誤訊息之訊息內容的屬性。
安全性影響
與原始訊息相關聯的身分識別，無論是初始身分識別，還是由接收管線解析方階段所決定的最終身分識別，會指派給錯誤訊息。
限制將訊息傳遞至授權訂閱埠和協調流程的安全性機制也適用於錯誤訊息。
訂閱錯誤訊息但未配置適當的解密憑證的傳送埠，將不接收由於在解密階段或解密階段之前的消息失敗所導致的錯誤訊息，而原始訊息是透過接收管線進入 BizTalk Server。 相反地，失敗的訊息會放在暫止佇列中。
配接器傳訊失敗
如果配接器暫停訊息，則會發佈錯誤訊息。 如果未暫停訊息，則不會產生任何錯誤訊息。
交易式接收管線
如果交易接收管線擲回例外狀況（指定交易應該中止），則會中止交易，併發佈錯誤訊息。
如果交易式接收管線明確暫停訊息（指定 MessageDestination = SuspendQueue），則允許目前的交易繼續執行（而且除非後續階段指定中止它），否則可能會認可該交易，併發佈產生的錯誤訊息。
Solicit-Response 傳送埠
當要求訊息從協調流程傳送，且傳輸失敗或其回應失敗的輸入處理時，協調流程會取得例外狀況，而不論失敗的訊息是否已路由傳送。
在請求回應傳送埠連線到要求-回應接收埠的情況下，接收埠會取得回應消息（如果傳輸成功）或 NACK（如果傳輸失敗），而不論失敗的訊息是否已路由傳送。
One-Way 傳送埠
當訊息透過針對傳遞通知設定的傳送埠從協調流程傳送時，協調流程就會接收傳遞通知，而不論錯誤訊息是否已路由傳送。 換句話說，即使通訊埠在處理期間遇到傳訊失敗，傳送埠仍會產生協調流程的傳遞通知。 通知確認已傳遞至港口，但不涉及確認是否已成功通過港口處理。
恢復已暫停的訊息
大部分在入站處理過程中（即從接收配接器處理，但不包括發佈至消息框前的階段）失敗且未被處理的訊息，會被暫停並可繼續處理。 例外狀況是，來自雙向接收埠的要求訊息會暫停為不可繼續。
訊息通常會以最初的形式暫停（即在進入管線處理之前的狀態），但有兩個例外：
管線元件暫停的訊息。 BizTalk Server 會以與提供給失敗的管線元件相同的形式暫停這種類型的訊息。 當訊息恢復時，它會從相同管線的開頭進行流程處理。 這表示在原始失敗發生的階段之前的某個管線階段中的管線元件，必須準備好以與原先處理該訊息的形式不同的方式來處理「同一」訊息。
來自可復原交換拆解過程中失敗路由的訊息。 BizTalk Server 會以與發行相同的形式暫停這種類型的訊息。 這是訊息在管線執行 之後 所擁有的格式。 當訊息繼續時，它會略過管線處理，並直接發佈至 MessageBox 資料庫。
導致暫停（不可繼續）訊息的情況
雖然訊息較常被暫停成為可恢復，但有一些案例可能導致無法恢復的訊息：
在已啟用失敗的已排序傳遞傳送埠中，如果管線發生失敗，則對應或傳輸失敗。
在已排序的傳遞接收埠中，如果配接器設定為在失敗時暫停因故障無法恢復的訊息。 例如，如果 MSMQ 配接器的「失敗時」設定為「暫停」（無法重新啟動），或 MQSeries 配接器已啟用「暫停為無法重新啟動」，則錯誤的訊息將會被暫停且無法重新啟動。
在雙向接收埠中，如果回應訊息在管線、對應或傳輸過程中失敗。
在雙向接收端口中，如果接收訊息在流程中失敗，則映射或傳輸可能會失敗。 個別配接器行為可能不同。 例如，HTTP 配接器預設不會暫停訊息，但可以設定為這樣做。