反組譯階段 (可復原交換處理)
在解譯階段可以使用兩種模式處理交換：
標準模式。 當接收管線的解譯器元件設定為執行標準解譯時，包含在交換中的訊息會被擷取、由接收管線處理、對應並發佈為交易式工作單位。 也就是說，會完整地處理整個交換及其包含的訊息並發佈到 MessageBox 資料庫，或是將交換放置在已擱置佇列中。
可復原模式。 當接收管線的反組譯程式元件設定為執行 可復原的交換處理時，交換中包含的訊息會彼此獨立擷取。 成功擷取的訊息會進一步傳播到接收管線。 在交換中已識別但未成功擷取的訊息，會放置在已擱置佇列中。
範例
下列範例說明交換處理實例。
範例 1
在此範例中，下列虛擬交換在標準交換接收位置上提交。 也就是說，接收管線中的解譯器元件為標準交換處理所設定。
<Interchange>
<Document1>...</Document1>
<Document2 failure=”routing”>...</Document2>
<Document3>...</Document3>
<Document4 failure=”pipeline” recoverableError=”true”>...</Document4>
<Document5>...</Document5>
</Interchange>
此交換包含五個訊息，解譯器可成功地從交換擷取所有這些訊息。 處理方式如下所示：
第一個、第二個以及第三個訊息透過管線傳播並準備發佈。
第四個訊息在管線的解譯階段處理失敗。 這造成所有已經處理的訊息回復，而且原始交換訊息被擱置為可繼續。
提交的結果為：
沒有發佈任何訊息。 原始交換已擱置，因為在標準交換處理中，在交換處理期間或之後的任一點失敗的任何已擷取訊息，將導致所有已擷取訊息被捨棄，且原始交換以可繼續狀態放置在已擱置佇列中。
範例 2
本範例使用與上一個範例相同的交換處理與傳播實例，除了解譯階段設定為執行可復原交換處理之外。
提交的結果是個別擷取的訊息已全部處理，並捨棄原始交換。 個別訊息的處理方式如下所示：
第一個、第二個以及第三個訊息透過管線傳播並準備發佈。
第四個訊息解譯處理失敗 (也就是說，在擷取此訊息之後發生錯誤)，並已準備將它擱置。
第五個訊息透過管線傳播並準備發佈。
從交換擷取所有訊息之後，就會將訊息 1、2、3 及 5 發佈到 MessageBox 資料庫，並將訊息 4 放置在已擱置佇列中。 訊息 2 由於沒有符合的訂閱者而造成路由失敗，也會重新導向至已擱置佇列。
設定可復原交換處理
可復原交換處理是接收管線解譯器元件的屬性。 並非所有解譯器元件都可讓您指定可復原交換處理，例如，原生 BizTalk Framework 解譯器就不允許。 如果反組譯程式支援可復原的交換處理，當您將反組譯程式元件新增至所設計管線的反組譯階段時，請在 Visual Studio 內Designer指定此行為。 將選取的反組譯程式拖曳到管線的反組譯階段之後，您可以將該反組譯程式元件的可復原交換處理屬性設定為 true 。
合作對象解析
在可復原交換處理中成功擷取的訊息，則根據為父交換已到達之接收埠所設定的合作對象，來識別傳送合作對象。 若有任何從指定交換擷取的訊息之合作對象解析失敗，則整個交換的合作對象解析會被視為已失敗。
限制
當交換在解譯器中失敗時，交換會被擱置為可繼續。 不過，若系統管理繼續此交換，它會再次失敗，因為造成解譯失敗的這些類型錯誤只是交換內容的結果，當交換繼續時，仍會維持相同結果。 必須修改這類失敗的交換並透過接收位置重新提交。
若訊息已從交換成功擷取，之後在透過傳訊傳播時由於不相符的訂閱者而失敗，則會將訊息擱置為可繼續。 若已修正路由失敗的原因，則此訊息可由系統管理繼續。
儘管在解譯器元件中發生下列錯誤，解譯器元件仍會繼續從交換擷取訊息：
找不到結構描述
結構描述模擬兩可未解析 (也就是說，相同訊息類型有一個以上的結構描述)
XML 驗證失敗
一般檔案剖析失敗
如果反組譯程式元件發生下列錯誤，反組譯程式元件 不會 繼續從交換擷取訊息：
- 文件資料不是格式正確的 XML—任何會造成 System.Xml.XmlReader 失敗的文件屬性