導讀：
一、 發送端口返回NACK後的處理方法
1、掛起的Orchestration是否可恢復？
不管是一般發送端口或是web類型的發送端口，一旦接收到NACK消息，Orchestration拋出異常後，如果沒有設置scope捕獲異常並處理，將導致Orchestration服務實例被掛起。
這樣掛起的Orchestration服務實例是否可恢復呢？
如果Orchestration沒有設置Exception Handler，發送端口的失敗會導致兩個掛起的服務實例：一個是發送端口的服務實例，一個是Orchestration的服務實例。
下面分別測試一下兩種發送端口在未設置scope掛起後是否能被恢復。
1.1. 一般發送端口錯誤導致掛起的Orchestration
一般的發送端口，發送一條數據插入到SQL Server，如果是因為插入了重復鍵導致了發送消息失敗，將產生兩個掛起的服務實例。
Figure 3. 物理發送端口出錯後產生的兩個掛起的服務實例
圖中上面一個Messaging類型的服務就是sql的發送端口服務實例。
下面那個是Orchestration服務實例。
在SQL Server把重復鍵的那條記錄刪除後，測試是否可以恢復這兩個服務實例。分別在兩個服務實例上點擊右鍵，選“Resume Instance”。
測試發現：
sql的發送端口服務實例可以被恢復，恢復後數據被寫入數據庫，掛起的sql的發送端口服務實例完成，不再掛起。
Orchestration服務實例進行恢復後，依然拋出同樣的錯誤，服務實例再次被掛起。不管恢復多少次Orchestration，總是會拋出同樣的異常。
1.2. Web類型發送端口錯誤導致的Orchestration
經過測試，web類型的發送端口錯誤導致刮起的Orchestration，跟一般端口錯誤導致掛起的Orchestration一樣，也是發送端口在外部條件恢復後可以resume，Orchestration卻不再能resume。
測試結果： 似乎有這樣的規律，orchestration收到了NACK的消息導致掛起，這樣掛起的orchestration都不能恢復。
分析原因可能是因為第一個NACK消息已經被Orchestration接收，再次resume運行Orchestration，這個NACK消息再次導致Orchestration拋出異常，所以，不管恢復多少次Orchestration，總是會拋出同樣的異常。
不知道是否有什麼方法能把這個NACK消息從掛起的Orchestration實例中去掉？
2、如何處理發送端口出錯的情況
從上面的測試可以看到，一旦發送端口返回了NACK後，即使導致發送端口出錯的外部條件恢復後，發送端口可以resume，但是掛起的Orchestration再也不能恢復了。
下面設計一個處理這種情況的方法。
設計一個簡單場景，Orchestration從A系統接收消息，做必要的轉換後，把消息通過Port_ConsumeWS web端口發送到Web services，Orchestration接收到WS返回的消息。
